Support and managed-services teams are forever being told to change: adopt a new ticketing platform, restructure shifts, add a chatbot in front of the queue, outsource the night rota. Each proposal arrives with confident predictions and no yardstick. Before any of it begins, the team that owns the queue should write down how it works today. Here are eight observations worth recording first, each paired with the reason it earns a place on the list.

1. How requests arrive

Note the channels people use, such as email, a portal, chat or a phone line, and roughly what share of requests comes through each. A change in tooling that quietly favours one channel can reshape the whole queue, and you will only notice if you recorded the original mix.

2. Time to first human reply

Measure the gap between a request landing and a person acknowledging it, on ordinary days and on the slowest ones. Automated receipts do not count. This single interval is what customers feel most, and it is also the figure most often reported in flattering averages that hide the bad afternoons.

3. Time to resolution, split by type

Overall averages blur everything. Separate simple requests such as access resets from complicated ones such as intermittent faults, and record how long each category takes from open to close. After a change, you will want to know which category moved, not merely whether a blended number did.

4. Number of handovers per ticket

Count how many times a request changes hands before it is closed. Every handover is a delay and a chance for context to leak away. Teams frequently discover that a modest share of tickets bounce three or four times, and that recorded fact becomes the most persuasive argument for restructuring.

5. Reopened and repeat requests

Tally how often a closed ticket returns, and how often the same issue is raised by the same customer within a short window. A queue can look efficient while quietly closing things that are not fixed. The principle discussed in the piece on core principles behind dependable software delivery applies here too: quality means the work stays done.

6. Where the waiting happens

Trace a sample of tickets and mark how much of their life was spent waiting: for a customer response, for another team, for an approval, for a maintenance window. The fraction of waiting time versus working time often surprises people, and it tells you which kind of change is even capable of helping.

7. What the humans say

Collect themes from short conversations with the support engineers and a few customers. What do they dislike about the current arrangement? Record the sentences, not a rating. This captures the part of the experience that numbers miss, and it gives you something to revisit when assessing the new setup. Engineers who have moved between operations and automation, as described in the article on how operations engineers grow into infrastructure-as-code and reliability roles, tend to have sharp views about which manual steps drain the most energy.

8. The running cost of the current set-up

Write down what the existing arrangement costs in tooling, contracts and staff effort in a typical month. Keep it to a description of what is paid for today; no need to calculate anything fancy. When a vendor proposes a replacement, you can place their promised savings against a recorded starting position instead of an estimate.

A word on ordering. If time is short, take items two, four and six first. They are the quickest to gather from existing ticket history, and together they describe how fast the queue answers, how often work is passed around and where requests sit idle. The remaining items can follow over the next couple of weeks. A partial snapshot taken before the change is always worth more than a perfect one assembled afterwards from recollection.

A bonus entry from a different industry

Planning anything that spans countries calls for the same discipline. BestEyeHospitals, a directory and planning aid for international patients, structures its pages around countries and a four-step consultation process, and it tells visitors that its content is general information which should be verified with providers. A support lead who has just written down eight observations will recognise the approach: start from facts you hold, then check every new claim against them.

How to run the exercise without disrupting the queue

• Sample, do not census. A few weeks of ordinary tickets is enough. You are after the shape, not every row.
• Flag unusual periods. Outages and holidays distort everything. Mark them so they are not mistaken for normal.
• Use one stopwatch. If a new platform reports times differently, re-calculate the old ones the same way before comparing.
• Date and share it. A visible snapshot prevents the quiet redefinition of “how it used to be.”

Reading the results after the change

Return to the same eight items once the new arrangement has settled, and use the same method. Expect a mixed picture. First reply might shorten while reopen rates climb; handovers might fall while customers say the experience feels colder. That is what honest evidence looks like, and it points you at the next adjustment instead of a victory lap.

The list is short on purpose. Eight notes, taken before the project starts, cost a few days of effort. They protect the team from vendor promises, from its own optimism and from the slow erosion of memory. Write them down while the queue is still the way it is.