Service Request Conversion and How Long You Take to Answer

Why this matters

A customer-raised service request is the warmest work a shop ever gets. Somebody who already knows you, already has your details, and already has a problem has come back and asked. You did not pay to find them and you do not have to sell to them. So when a third or more of those requests never turn into a job, the instinct is to ask what was wrong with the requests. Usually nothing was wrong with the requests. The shop was slow, the customer called somebody else, and the conversion number recorded a verdict about the shop's queue while everybody read it as a verdict about demand. These two figures have to be read as one thing, which is what this card does.

What the two numbers are made of

Conversion. Numerator: requests raised in the window that became a job. Denominator: requests raised in the window. Note that the anchor is the RAISE date, not the conversion date, which is what makes the figure comparable period to period and also what creates the truncation problem below.

Mean days to answer. Numerator: the sum of days from raise to first reply, across requests that got a reply. Denominator: the count of requests that got a reply. The silent exclusion is right there in both halves: a request nobody ever answered has no answer date, so it sits in neither. The figure therefore improves the worse you get at the thing it measures, and the worst cases are the ones it cannot see. That is a general shape with a fuller treatment elsewhere. See related: Time to Invoice Only Counts the Invoices You Sent.

One definitional point decides whether either number means anything: "answered" is a human reply that reaches the customer. Not an internal status change, not an assignment, not somebody opening the record. The clock the customer feels runs until they hear from a person, and a shop measuring the internal event will report a queue that is running an order of magnitude faster than the one the customer is standing in.

The pairing, worked

One shop, one quarter, 86 customer-raised requests. 52 became a job, a conversion of 60.5 percent of requests raised. Mean days to answer, over the requests that got an answer, 1.8 days. Two ordinary-looking numbers.

Now split the same 86 requests by how fast that first human reply went out.

Monotonic across all four bands, and the drop is not gentle. But only the top band has 32 requests behind it, and a rate wants about 30 cases before it is worth quoting. That floor is borrowed deliberately from the one a survey figure carries, for the same arithmetic reason, applied here to requests rather than to survey responses. So read the four-band table as a direction, quote 81.3 percent if you quote anything, and roll two more quarters before you put a number on the bottom band.

The sized claim comes from a two-band cut where both sides clear the floor:

• Answered inside one working day. 40 of 54 requests became a job, 74.1 percent of that band.
• Answered later than one working day, or never. 12 of 32 requests became a job, 37.5 percent of that band.

A separation of 36.6 points, on the same 86 requests, with the same conversion definition on both sides. Fewer than two in five requests in the slow half turned into work, against nearly three in four in the fast half.

What each average was hiding

The conversion figure was too low. Eleven of the 86 requests were raised in the final two weeks of the quarter and only 4 of those have converted so far, because the rest have not had time to. Strike those 11 and the mature figure is 48 of 75, 64.0 percent of requests raised, against the headline 60.5 percent. The headline understates by 3.5 points, and it understates by more the shorter your window and the longer your customers take to decide. That is cohort truncation and it has its own card. See related: Estimate Conversion Rate and the Cohort Problem.

The mean days figure was far too good. The 1.8 days was computed over the 81 requests that got an answer. Five never did. Age those five at their position on the last day of the quarter (41, 33, 26, 19 and 12 days old, 131 days between them) and add them to the 143 days the answered ones carried, and the mean over all 86 requests becomes 274 days over 86, which is 3.2 days. That 3.2 is a floor rather than a latency, because those five were still unanswered when the clock stopped and their real wait only grows, and every one of them belongs to a customer who asked for work and heard nothing.

Both corrections run the same way, and it is worth noticing why: the two headline figures were flattering because the cases missing from them were the bad ones. That is the general shape of an excluded denominator, and it has its own card.

Not every non-job is a loss

Thirty-four of the 86 requests did not become a job. Some of those were never available to you. Go through them and 9 of the 34 turn out to be a request for a trade you do not do, an address outside the area you serve, or a duplicate of a job already open for that customer. Nothing in your queue was ever going to convert those, and leaving them in the denominator charges you for work you could not have taken.

So record a disposition on every request, in six buckets: became a job, not our trade, out of area, duplicate of an open job, customer withdrew, lost to somebody else. The last two are the only ones that are losses, and separating them is the difference between a number you can act on and a number you can only feel bad about.

With those 9 struck, conversion is 52 of 77 requests, 67.5 percent, against the 60.5 percent headline. And here is the part to be careful with: the two corrections do not add. One of the 11 late-in-quarter requests was also out of area, so it sits in both exclusions and cannot be removed twice. Recompute from the rows rather than stacking the percentages: 11 plus 9 minus the 1 overlap leaves 67 requests, of which 48 became a job, which is 71.6 percent. That is 11.1 points above the headline, where adding the two separate corrections would have said 10.5. Small here, and the habit is what matters, because on a bigger overlap the stacked version is simply wrong.

Is the speed causing it, or just sitting next to it

The honest objection: perhaps the easy requests get answered quickly and also convert easily, so speed is a symptom of triage rather than a cause. It is a real alternative and the table above cannot rule it out. Two cheap tests can.

Split inside one request type. Take one kind of request only, the one you get most of, and run the same latency split on it. If the pattern survives on requests that are alike in content, triage is not the explanation, because there is nothing left to triage on.

Use the delays you did not choose. Every shop has a week where somebody was out, a holiday weekend, a stretch where the phone system broke. The requests that sat during those are delayed for reasons completely unrelated to their content, which makes their conversion rate the cleanest read available. Pull one of those weeks and compare it against the weeks either side.

In shops that run these tests, the pattern usually survives both, and the mechanism is not mysterious. A customer with a problem is not waiting patiently for you to be free, they are working down a short list, and every hour the request sits is an hour somebody else can answer it. Speed does not beat a better shop; it beats a slower one, and most of the time that is who you are actually competing with on a service request.

What moves the number

Four things, none of them expensive, all of them about the queue rather than about selling:

• One named person owns the inbound queue every working day, and a named backup for the days that person is out. Requests do not sit because nobody wanted to answer them, they sit because the queue belonged to everybody.
• Answer before you can schedule. Most of the delay in a slow queue is a person waiting until they have a date to offer. "We have it, Marie is looking at it, you will have a date from us by tomorrow afternoon" is a complete answer and it takes the customer off the market. Holding the request until the schedule is sorted is how a two-hour job becomes a four-day silence.
• A fixed daily check time, early enough that a same-day answer is still possible. A queue checked whenever somebody remembers is checked worst on the days you are busiest, which are the days the most requests arrive.
• A stated standard: every customer-raised request gets a human reply the same working day, and the next working day at the absolute outside. Tune it to your shop, but commit to the number. A standard nobody can state is a standard nobody can miss.

Read them in this order, and the conversion rate comes last

Order the four by whether the number still names a customer you can do something about today, because that is what decides whether looking at it changes anything. The conversion rate sorts to the bottom on that measure, which is the opposite of where most shops start.

1. The oldest unanswered request, right now. This names one specific person who asked you for work and is still waiting. It is fixable in the next ten minutes, and it is the only number on this list that is. Look at it daily. If the oldest unanswered request is more than one working day old, stop reading the rest and go answer it.
2. The count of requests currently unanswered past one working day. This names a set of people and describes this week's habit rather than one slip. Fixable this week, usually by the ownership rule above. Look at it weekly.
3. The latency distribution for the period, as the four-band table rather than the mean, because the mean hides both the never-answered and the shape. This names no individual, it names the process. Fixable this quarter. Look at it monthly.
4. The conversion rate. This names nobody and describes a quarter already spent. It is the scoreboard, not the game, and by the time it moves the customers it is about have already decided. Look at it quarterly, with its truncation and disposition corrections applied together rather than stacked, and use it to check that items 1 through 3 worked.

A shop that reads this list top to bottom fixes something every day. A shop that reads it bottom to top holds a meeting about demand.

References

• See related: Time to Invoice Only Counts the Invoices You Sent
• See related: SLA Compliance Only Counts Jobs That Carry a Deadline, which owns the excluded-denominator pattern
• See related: Estimate Conversion Rate and the Cohort Problem
• See related: The Effort Score and What It Predicts That Satisfaction Does Not
• See related: The Satisfaction Score and Who Actually Answers a Survey