The Call-First Conundrum: Rethinking Tech Support Efficiency

You hit a problem. You write it up properly: what you did, what happened, what you expected, the logs, the screenshots. You send it.

The reply asks when you are free for a call.

Now the thing takes a week. Not because the problem is hard, but because two calendars have to meet. And when the call finally happens you say out loud, slowly, the things you already typed. If the person who owns the ticket is out that week, it simply sits there, because it is theirs, and nobody else will touch it.

What the call is usually for

I have spent a long time on the other side of this, so let me be fair about it first.

Roughly 85% of the tickets in my queue close with a couple of emails. That number holds because of what happens before I reply. I read the whole thing, including the attachments. I go and look at the system. Where I can, I reproduce the problem myself, so that when I do answer I am telling you what is wrong rather than asking you to go and find out for me.

That work is invisible, and it is the whole job. A call is often what happens instead of it. If I have not read your ticket, the fastest way to look responsive is to get you on the phone and have you explain it again, live, while I catch up. The call is not for your benefit. It is the support side externalising the reading onto the customer.

Except when it genuinely is not

Here is the part that complicates my own argument.

At a well known cybersecurity company, I was pushed onto calls constantly for things that looked trivial on paper. Stand up a virtual machine. Deploy the agent across the network. The sort of task you would expect a written answer to cover.

The calls were necessary. Not because the product was hard, but because a startling number of customers did not know how their own infrastructure was put together. These were not small shops. These were large enterprises, with real IT departments, and we were walking them through fundamentals on a screen share.

That changed how I think about this. The difficulty of a problem has almost nothing to do with the size of the company having it. Someone running a thirty person firm may know their estate completely, and someone at a multinational may have inherited a network nobody has mapped in a decade. A blanket “just put it in writing” policy would have failed those customers badly.

So the call is not the enemy. The reflex is.

The vendor side of the same desk

Then I became the one submitting the tickets, on behalf of clients, to Okta, Microsoft, Salesforce and the rest. The pattern is almost funny in how reliable it is.

You submit. You get an acknowledgement within minutes, which ticks the service level box. Then nothing. The written detail goes unread. You get a voicemail, usually from someone who has not opened the attachment. You get asked to schedule, by people who have scheduling tools sitting right there.

The sharpest version of this was an Okta engineer who went on holiday with our open issues assigned to him. No handover, no reassignment. The work simply stopped for the length of his leave. What makes that absurd is that we never asked for a named engineer. We would have been delighted with anyone at all. The bottleneck was not a resource constraint, it was that a ticket had become one person’s property.

Acknowledgement time is the measure, so acknowledgement time is what you get. Nobody is being lazy. The thing being counted is being delivered, enthusiastically. It is just not the thing you needed.

The human information gatherer

The deeper problem with call first is what it says about the support process underneath it.

When the call is the primary tool, the first responder’s job becomes gathering information by talking, which means the quality of the ticket depends entirely on how good that person is at asking questions in real time, with you waiting. It often feels like they are navigating the product alongside you for the first time.

Almost all of that is a solved problem. Clarifying questions can be asked in a form. Diagnostic data can be captured by a tool rather than read aloud off a screen. Decision trees exist. A good intake process gets more out of a customer in two minutes of structured questions than an hour of unstructured conversation, and it leaves a written record that the next person can pick up when the first one is on leave.

What premier actually buys

There is an open secret about premium support tiers: a good share of what you are paying for is a faster greeting.

You pay for priority and get routed to the same teams, sometimes the same outsourced teams, as everyone else. The acknowledgement comes quicker. The resolution does not. When I have paid for premier with vendors, what changed most reliably was the speed of the first reply, not the number of days until the problem went away.

If you are buying a support tier, the question to ask is not how fast they respond. It is who, specifically, you reach, what they are allowed to do without escalating, and what happens to your ticket when that person is out.

What I would build instead

Less of this is about people than it looks. Most of it is about what the system does before a human gets involved.

Collect the diagnostic data automatically when the error happens, and attach it to the ticket, so nobody has to ask for it and nobody has to read it out.

Let users resolve the frequent things themselves. On demand access to trusted software and the routine maintenance tools removes a whole category of ticket that never needed a technician.

Guide people through the common faults interactively, so the system asks the questions a technician would ask, and the person learns something on the way through.

Automate onboarding and offboarding properly. Creating accounts and preparing machines is repetitive digital labour, and every hour of it spent by a person is an hour not spent actually welcoming the new starter.

None of that is about replacing people. It is about making sure the person enters the conversation already knowing what happened, so the first exchange can be about the fix.

The measure

The thing I would change, if I could change one thing, is what gets counted.

Response time is easy to measure and almost meaningless on its own. The numbers worth watching are how long until it was actually fixed, how many exchanges that took, and whether it stayed fixed. We run at about two hours to first response and close most things in under three replies, and the second number is the one I care about.

A call is a tool. Sometimes it is exactly the right one, and the enterprise customers who did not know their own network taught me that properly. But it should be chosen because the problem needs it, not because it is the only way the process knows how to move.