notes-institutionalDesign-customerServiceAntiPatterns

I'm thinking about times when i have been frustrated by customer service, tech support, etc, and wondering how the organizations could have designed things better to avoid frustrating me. I've seen these antipatterns in both low-end consumer tech support and high-end professional services.

Below, i use the language of tech support, but advisory professional services such as accounting fit under the same scheme.

Failing to escalate

Styling non-experts as experts

When a front-line support person who is not a domain expert claims to be an expert, is given a title which implies that they are one, or seems to think they are one as evidenced by their unwarrented faith in their own understanding of the domain.

This is tricky because it's natural for front-line support to want to position themselves as experts. And indeed, it may be comforting for some end-customers to be told that they are being helped by someone who knows.

Suggestion: transparency

Make it clear, both on the organization's support website and in the titles of the various tiers of support, what the tiers of support are and how many there are. Have a page on the website that explains the escalation procedure, and encourage front-line support to explain the procedure when escalating. Don't call Tier 2 support 'Advanced Technical Support' if the support providers are not trained engineers. Call them 'Tier 2 Technical support' or somesuch.

Failing to escalate

When a front-line support person delays escalating the issue even after it becomes clear that they cannot solve your problem.

Suggestion: escalate quickly

I don't really know how to solve this except by simply instructing front-line support to escalate when they are out of options or confused, rather than attempting to solve the problem themselves. Especially when their attempts to solve it may mess things up for the end-customer.

Of course, for learning, it's important that each time this happens, (a) that front-line support person is told what the problem turned out to be and how to solve it in the future, (b) the situation is analyzed for possible inclusion onto the support website and/or front-line support scripts.

This is tricky because it's natural for front-line support to acquire confidence in their own abilities, and to attempt to do it themselves rather than 'asking for help'.

Front-tier support hoping the problem will go away

When a front-line support person attempts to get the end-customer to give up when they cannot solve a problem, instead of escalating.

Avoiding this is tricky because indeed one of the functions of front-line support is to shield upper-tier support from end-customers who are demanding something that it is more than they are due, according to the organization's policy.

Suggestion: in the absence of PUBLIC policy, default to escalate, not no

Personally, when i have been frustrated is when the organization clearly advertised one thing but then attempted to deliver something less, and when i tried to get what was advertised, lower tier support tried to blow me off saying that was their policy, even though they agreed that their organization's marketing was misleading.

This could be avoided by instructing front-line support never to deny escalation based on INTERNAL policy, but only based upon PUBLICLY stated policy. So, if they can't find a basis to deny escalation somewhere in the organization's publicly-viewable support website, then they must allow it. In other words, in situations where a denial is based on internal policy or is case-specific, the case must be escalated to the actual experts first.

Or, in simpler language, instruct front-line support that their job is either to solve the problem or to escalate it, not to say no; except in the special case where the publicly-viewable, written support materials clearly say no.

Suggestion: when front-line support thinks a resolution is impossible, instruct them to escalate rather than deny

Personally, i've encountered a situation where a company's marketing promises something, but their systems are misconfigured to not deliver it; when i contacted support, they agreed that it should work but said that their system interface did not allow them to edit this part of the configuration therefore i am out of luck. This is not satisfactory because the end-customer is left with the suspicion that there is someone else in the company who could easily change the configuration, if they would only be permitted to speak with that person.

The problem is that front-line support confused 'i can't think of any way to do this' with 'this is impossible'. Maybe it is impossible, but in these cases, front-line support should escalate to an expert.

Suggestion: Gatekeepers must be experts

At some point in the process, there must be a gatekeeper, that is, someone with the authority to say 'Even though our publicly viewable materials don't say whether or not we support this, i have determined that we do not, and we will not spend further time trying to', or, 'in a sane world we would be able to do this but we can't, at least not feasibly, so we're going to give up', or in the realm of professional services, 'I am the one who is going to explain this to you, and i will not permit you to escalate this question past me to waste the time of other people here'.

Front-tier support is not qualified to make this determination, and it is frustrating to end-customers when they are authorized to do so.

The gatekeepers must themselves be experts; it is not a good idea to have the non-expert front-line support be gatekeepers for the experts.

This suggests the following tiers:

Tier 1 support: Junior front-line support Tier 2 support: Senior front-line support (at this level, (only) requests that are clearly again publicly written policy are denied) Tier 3 support: Junior experts (gatekeeper level) Tier 4 support: Senior experts

For example, at a software company, tiers 3 and 4 would be programmers, and tier 4 would be project leads and perhaps other senior devs. At a hardware company, tiers 3 and 4 would be trained engineers, and tier 4 would be engineers actively involved in product development. At a partnership-structured professional service, tiers 3 and 4 would be credentialed domain professionals, and tier 4 would be partners.

Failing to escalate quickly

When the end-customer is an expert and the front-line support person is not, yet the front-line support person insists on walking the end-customer through a lengthly script before escalation.

Suggestion: parts of the script should be optional

If the front-line support person determines that the end-customer is themselves an expert then they should be able to skip the optional parts of the script.

The lengthly parts should be the optional ones. E.g. never skip asking quick questions like 'Is the device plugged in?'. But perhaps skip lengthly reinitialization procedures.

Note that this requires the support system to have the technical infrastructure to record which parts of the script were skipped, so that upper-tier support can go back to it if they feel it was actually needed.

Failing to transmit basic customer account information

When, after each escalation step, the customer is required to repeatedly give their name, their account number, to authenticate themself, etc.

Suggestion: transmit it

Indirection through a non-expert

When, even after escalation, the end-customer being supported is not permitted to talk to the experts directly, but only as filtered by a non-expert support person.

This is not only annoying to the end-customer but also a waste of time. I have seen multiple instances of the experts' time wasted troubleshooting the wrong problem, because front-line support miscommunicated my highly technical problem to upper-tier support.

Suggestion: after escalation, offer to connect the end-customer with the expert(s) directly

Suggestion: if communication must be indirect, then have the point of indirection be an expert, not front-line support

No alternative to front-tier support

Suggestion: Paid support offering to bypass front-tier support

If i really care, i should be able to speak to the experts immediately, without going thru the cheaper-but-more-lengthly procedure of escalation through front-tier support. The only reason not to do this is cost, so if i want to pay for it, i should be able to do it.

Insufficient organizational learning

It is frustrating when there is a problem that a lot of people have (as evinced by forum posts, for example), that a lot of people call support about, and yet which front-tier support does not know about or which is not on the website or which the product development team doesn't seem to know about.

Suggestion: a support wiki for customers to post on

Suggestion: front-tier support is told what the solution was for problems they escalate

or maybe even stays on the line after escalation, to learn

Suggestion: review and update front-tier support scripts and web support KB after each call that was escalated

Suggestion: review and update web support KB based on surveys of front-tier support

Front-tier support should report which problems they hear over and over and this should be used to update the web support KB.

Suggestion: appraise development team of failings that need to be fixed based on surveys of front-tier support