Yeah I agree I hate this kind of obstructive customer service
I work as a software engineer on automated customer service systems like these, and boy let me tell you, obstruction is the name of the game. For example: don’t make the phone number too easy to find on the website because it will lead to too many calls. We nudge people toward the FAQ and such first so they can hopefully find their answer there. Then, we have chatbots like this which contain exactly the same information as the FAQ again. And only then might we offer you contact with a human.
The essential problem is that support is a cost center, so cost savings is the name of the game. We optimize for metrics like:
- “deflection” (number of calls averted because we pushed the user into automated tools instead)
- “first call resolution” (percentage of issues resolved in one contact. How do we know if your issue is resolved? Simple, if you don’t contact us again we assume the issue is fixed)
- “Average contact time” (pretty obvious, get the customer off the phone ASAP)
If you manage to get on text chat with a human, typically they are handling two other conversations at the same time, that’s why they seem so absent all the time (and why companies love chat. Much cheaper than calling).
I’m not saying we’re all diabolical here. There is a general agreement among everyone in the industry that we should help the customer as well as we possibly can. Indeed every CS manager will tell you how important we are to our brand image and NPS, how we strive to be the most customer-friendly company etc. etc.
But the numbers don’t lie. If you look at the metrics that everyone actually optimizes for, it’s cost cost cost.
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes “at once.”
You can improve the situation with git rerere