No more bottlenecks!

Having spent many years creating and improving support processes, I’m always struck by how many reviews, approvals, and other validations I find. For instance:

  • A manager must approve case transfers to other queues (or worse, both the manager of the outgoing queue and the manager of the incoming queue must approve).
  • A team lead must review cases before escalating to level 2.
  • A manager must approve handing over cases to the next shift, for instance in a Follow-the-Sun (FTS) process.
  • A team lead must approve all refunds.
  • A specialist must review knowledge base articles before they are published.
  • A subject-matter expert (SME) must validate request for assistance by the engineering team.
  • A SME must review bugs before they are submitted to the engineering team.

We can see why the reviews and approvals came into existence: we don’t want level 2 to work on “easy” cases; we don’t want to publish incorrect information; we don’t want to deluge the engineering team with inappropriate requests. But still: each extra steps causes delays and can create bottlenecks.

What are the alternatives?

There are three alternatives to mandatory reviews or approvals:

  • Templates, and job aids. Provide a checklist or template, with required elements. For instance, build a FTS checklist to fill out before the case can be moved to the next geography.
  • Certification. Create a testing mechanism or require a number of successful requests to qualify as a certified requestor. For instance, support engineers who have placed 10 successful engineering assistance requests are certified and can place requests unimpeded. Others must obtain a validation from a certified colleague.
  • Trust and verify. Allow requests to go through but track who makes requests and whether they are legitimate. For instance, allow agents to offer refunds but review the refunds after the fact to make sure they are doled out in a consistent manner across the team.

Of course you can use multiple techniques at once. For instance, provide templates to log bugs and also certify bug submitters and also check that the bug rejection rates are low.

Good Reasons to Require Approvals

I’m a big fan of getting rid of approvals, but there are situations that warrant them. Here are a few:

  • Rare events. If you approve one refund a month, the delays and aggravations caused by that one approval are small and you can choose to retain it.
  • Requests with high rejection rates. If Engineering rejects over 50% of your requests for assistance, there’s a problem either with the quality of the requests or the soundness of the rejections. Either way, inspecting each request is a good start.
  • Requests for expensive goods or services. You could mandate approvals for refunds over $1000, for instance, but allow others to go through unimpeded. In the same vein, you probably want to know when a support contact asks to speak to the CEO.
  • Requests that have extensive waits. If it takes weeks to get any action on bugs, reviewing them before submission allows you to prioritize them and to make sure each one is pristine.

How do you handle approvals and validations? Tell us in the comments.

Leave a Reply

Your email address will not be published. Required fields are marked *


seven + 3 =