How we tamed the GovPress support queue

How we made a long queue of support tickets shorter to make sure our clients have a positive experience

With 100 client requests a month, support is the busiest area of GovPress operations. We can see all kinds of requests coming in over a single day – from design changes and questions about WordPress, to detailed changes to our systems and infrastructure. Dealing with these requests promptly is crucial to our clients meeting their communications goals.

This time last year, the GovPress support desk faced a dilemma. Our Account Manager was going on paternity leave, the queue of support tickets was high, and the number of software developers with availability to help on support was low. Without someone permanently on first-line support, how could we service that long queue of tickets and ensure our clients had a good experience?

Support desks are just a big queue

If you were considering this problem, I wonder whether your first thought would have been about supermarkets?

Before supermarket checkouts became automated and the pandemic boosted the home delivery market, you’ll most likely have experienced standing in a long queue for a supermarket till, alongside lots of other tills with equally long queues. You probably wanted the supermarket managers to do something to speed up how quickly people were being served. And, intuitively, you’d know that changing queues wouldn’t help but one thing might – opening another till.

If all the tills have long queues, it means that the average number of customers in the system is high. We want to reduce the average time a customer spends queuing, and one way to do that is to change the rate at which customers are served at the checkout. Opening a new checkout increases the service rate (λ), as more customers can be served simultaneously. In turn, the average number of customers in the system should decrease, and on average, customers will spend less time waiting in the a queue.

Beyond the supermarket checkout

The line of reasoning that leads to opening a new checkout at the supermarket is known as Little’s Law. It states that the number of customers at checkouts is equal to the rate at which they join the queues, multiplied by the average amount of time each customer spends in the checkout system (Customers=λ.Wait).

This relationship was originally discovered by Philip M. Morse, a Professor at the Massachusetts Institute of Technology, in the late 1950’s. And was proved correct by John Little, also Professor at the Massachusetts Institute of Technology, whilst he was on a summer holiday with his family at Nantucket. (Work-life balance has never really been a thing in academia.)

Surprisingly, the type of work that’s done at the checkout isn’t a factor in determining how fast people can be served at the supermarket. And the same reasoning works if there’s one large queue and many tills, like you might find at a Post Office. Because Little’s Law is abstract enough that it doesn’t depend on the work done for each customer, it can be applied to any system with queues, from running supermarkets and factories, to the internals of computer systems. Or the GovPress support desk.

Putting Little’s Law to work

So we knew the theory behind how we could reduce the time our clients spent waiting for their support requests to be resolved. But we needed to do a little more work to put that into practice. When we looked carefully at our queue of tickets, we found that requests which could be resolved quickly sometimes got overlooked. We also found that tickets which would need a longer response time, sometimes got rescheduled in favour of tickets with a more medium-sized workload.

This suggested that we should restructure our single queue of tickets into several separate lists, depending on the size of the workload. Now we had different queues for:

We added another queue for tickets we couldn’t easily estimate a workload for without getting more details from the client.

The results

Whilst our Account Manager was away, we were helped by dxw Friends Luna and Sophie, who job-shared the role of triaging tickets and answering most requests with smaller workloads. We also added a second-line support rota to manage the most complex requests that had previously blocked the progress of shorter pieces of work.

This new structure meant that everyone working on support now had a much clearer view of what they were working on and how long they should expect each piece of work to take. It made scheduling easier for the whole team and improved the service rate for the support desk overall.

The bar chart above shows the number of open tickets over the last 2 years and how they have reduced over time. You might notice that there’s an unusual increase in tickets around the middle of this year. This was the result of some infrastructure work that required us to contact a large number of clients.

Overall, we’ve ended up with about half the number of open tickets in the queue at any given time. If all other things were equal (spoiler alert: they never are) Little’s Law would tell us that the average wait time for a client to have a ticket resolved is now half of its value a year ago. That’s a huge achievement from the support team who have worked immensely hard for our clients, and the wider team who have taken on the second-line developer role, which is certainly not an easy one!