I’ve been reading (listening to, actually) the book ‘The Phoenix Project’ over the last couple of days. This is a novel about turning around a dysfunctional IT/DevOps group. I highly recommend it – it’s in the same format as the much older, now classic ‘The Goal’ which is a novel about turning around a struggling manufacturing plant before its shut down. Both books are surprising thrilling and inspirational.
Anyway, while listening this morning I was struck by something about resource allocation — that the average wait time for a resource is proportional to the % time the resource is utilized divided by the % time the resource is idle. Aka U/(1-U). If a resource is allocated %50 of the time, the average wait time for that resource is 50/50 = ~ 1 unit of time; A resource allocated 95% of the time will have a wait time of 95/5 = 19 units of time. As the resource approaches its capacity, on average you’ll be waiting longer and longer for it.
Anyway I was thinking about how this applies to customer support. If we had one person, virtually doing nothing but support (100% utilized), the average wait time would be very large, several days on average most likely.
However, if we had two people, splitting the support equally, the average amount of time a customer would wait for a reply would be many times smaller. This is despite the fact that the same number of actual support tickets is coming into the system, and the same total time (and therefore the cost) is being spent on those tickets. Furthermore, it’s not like the additional support resources would actually be idle the rest of the time – as long as support was prioritized, they could do other work the rest of the time. The only downside is the context switching penalty, which isn’t trivial. Still, seems like it would be worth it. Done, right, spreading support work out to a great number of technical staff would have large customer benefits.
The next problem is that the support tickets have high variability in terms of the expertise required of the individual. This creates constraints in the system, where a particular engineer becomes the choke point for all questions of a given category. In our case these are also the most time consuming questions, and ones for which training at least superficially seems impossible.
The solution for this is a knowledge base, but now we’re talking about taking those key engineers, and making they write some massive knowledge base instead of getting anything else done. And also maintaining it all the time. Furthermore, it always takes less time to bang out a ticket reply than to create a new knowledge base article — and I think most firms never build up a good knowledge base for this reason. This is something we’ve actually thought a lot about, and already have a system in place for. If you’ve written into support over the past couple of months, you already have an idea of what we’re doing. It’s very rough and not yet public facing. A rough but functional public-facing implementation is gong live in our first sprint in January.
