What a service desk changes when support runs on email

Tata Sons incorporated Tata Realty and Infrastructure Limited to grow the group's real estate and infrastructure business. When we arrived, internal support ran on email and phone calls. That is a normal state of affairs in an organisation that has grown quickly, and nobody involved was doing their job badly. They had a working process that kept no record of itself.

Email support is a process. It has routing, which is whoever you happen to know. It has prioritisation, which is how senior the sender is. It has escalation, which is forwarding the thread with the word urgent added. It has closure, which is the thread going quiet. Every one of those steps happens reliably. None of them is recorded anywhere anyone can query.

The questions nobody could answer

Before the service desk went in, four fairly basic questions had no answer. How many requests came in last month. How many are still open. Which team is the bottleneck. Which request type recurs often enough to be worth fixing at the source rather than handling again.

Those look like reporting questions. They are budget questions, and they were being settled by whoever had the strongest recollection in the room. One department believes one thing about its own load, another department believes the opposite, and both are arguing from memory.

Map the informal paths before replacing them

The first piece of work involved building nothing. We spent time documenting how escalation actually happened: who people rang when a lift in a particular building stopped, who they rang when that person was on leave, and which requests bypassed the process entirely because someone knew the facilities manager personally and it was faster.

That map matters because a workflow tool contradicting the real organisation gets abandoned in about six weeks. People route around it, go back to email, and now there are two systems of record, which is a worse position than the one you started from. The routing model in the finished system, by area of concern and priority with an SLA clock attached, is mostly a formalisation of what people were already doing. The clock was the genuinely new part.

What the clock changes

An SLA clock makes ageing visible without anyone having to complain. A request that has been open for eleven days announces itself on a screen. Nobody has to be the person who chases a colleague, which in internal support is a real social cost and quietly suppresses both reporting and follow-up. The clock also gives the support team a defence: when a department claims nothing gets done, there is a number.

The knowledge base did the other half of the work. Recurring requests stop reaching an agent at all, and the ones that keep arriving despite an article tell you the article is wrong or unfindable. We instrumented resolution time and backlog per department, which is where the argument about headcount eventually gets settled.

There is a cost, and it is worth naming. Email is fast for the person raising the request. Two lines to a colleague takes fifteen seconds; a form with a category, a priority and a location takes longer, and people resent it for the first month. Our mitigation was keeping the form short enough that the extra effort stays under a minute, and accepting that a proportion of tickets arrive miscategorised and get corrected by the agent. A form that guarantees clean data at the point of entry is a form nobody fills in.

None of this is interesting technology. A ticket table, a routing rule, a clock and a search index. The value is that a year later somebody could ask what the five most common internal issues were, and receive an answer with a number attached instead of an opinion.