Org Design and Reporting Lines for Support

The org chart on the wall at Bluewater Bank has the help desk reporting to the Head of Technology, who last touched a ticket about a decade ago and remembers it fondly. Two desks along sits Tomas, the systems administrator. He is not on the chart as an escalation point but receives every escalation anyway. That is because he is seven steps away and the ticket system is a login. By ten most mornings Tomas has been asked four questions, none of them in a ticket, and the queue says he has nothing assigned. The chart is accurate. It is also useless.

Where the desk reports, and who it hands work to, decides more about how support behaves than any process document. A reporting line sets who defends the desk's time, who reads its numbers and who can tell a specialist to answer. A handoff rule sets whether an escalation is a ticket or a conversation. Most small organizations draw the first and never write the second, which is why the chart is right and the mornings are wrong.

This article is part of our Helpdesk vs Service Desk series. The series sorts out what the three names mean and how the desk fits into the rest of IT. This article covers where the desk can report and what each line implies and the desk's relationship with the sysadmins and the network team. Then come dual-hat roles and how to make the hats visible, and the handoff contract between desk and specialist, with a template to steal. We finish with the two ways the relationship fails and a fifteen-minute weekly review that keeps the peace.

Where the Desk Can Report

The desk can report to four places, and each one buys something and costs something. The usual line is to the IT manager. This keeps the desk inside the team that fixes things and gives it a boss who can tell a specialist to answer. The second is to an operations or business services manager, which puts the desk beside facilities and reception and treats it as a front-of-house function. The third is to a service delivery lead, a role that exists only in larger departments and owns the user-facing side of everything. The fourth, occasionally, is HR or facilities, which happens when the desk started as a shared mailbox in that department and nobody moved it.

Choose the line that gives the desk authority over the people it escalates to, which almost always means the IT manager. The desk is the one part of IT that makes promises to users on behalf of everyone else in IT. It can only keep those promises if the people doing the work answer to the same person. A desk that reports outside IT can be excellent at empathy and useless at getting a server fixed, because its boss cannot ask the server's boss for anything.

When the desk reports to the wrong place, the symptom is a queue that nobody above the desk ever looks at. The IT manager reads the project plan. The operations manager reads the facilities list. And the desk's weekly numbers go to an inbox that was set up for them and has not been opened since. A desk whose numbers are not read is a desk whose staffing case is never made. And the case depends on the shape described in Choosing the Support Model for Your Size. The desk will be asked to do more with the same people, in a tone of mild surprise, every year.

The Desk Is the Specialists' Customer, and Their Early Warning

The desk and the sysadmins are not peers doing the same job at different levels. The desk is the specialists' customer, and their early-warning system. As a customer, the desk brings the specialist work that has already been identified, reproduced and described. That way, the specialist's time is spent on the part that needs them. As early warning, the desk sees the first three tickets about the slow file share before the monitoring system has decided anything is wrong. The specialist who listens to the desk finds out about problems while they are still small.

Both halves depend on the desk doing its half well. A desk that escalates a ticket saying "user says it's slow" has not been a customer; it has been a relay. A desk that notices three tickets about the same share and raises one escalation that says so has been the early warning. In that case, the specialist will start answering its messages faster. The specialist's half is to treat the escalation as a contract rather than an interruption, and to send back what was found rather than "fixed". That is because the desk has to explain the fix to the user and write it down for next time.

The network team is the same relationship with longer lead times. Network problems look like everything else from the user's chair (the application is slow, the call dropped, the printer is gone). So the desk's job is to collect the facts that distinguish them: which site, which floor, since when, who else. A network specialist who gets those four facts in the ticket can start work; one who gets "network is down?" starts by asking for them. Networks hold grudges, and after the fourth such ticket, so do network specialists.

Dual-Hat Roles: The Administrator Who Is Also the Desk

In most organizations under about a hundred and fifty users, at least one person wears two hats. They are the desk in the morning and the systems administrator in the afternoon, or both at once, all day. The dual hat is not a design flaw. It is the design, and it works as long as everyone, including the person wearing it, can see which hat is on. When the hats are invisible, the desk work wins every time, because it is the work with a human waiting on it. In that situation, the server work (patching, backups, the certificate that expires on the twentieth) slips until it becomes desk work of a louder kind.

Make the hats visible with three things: hours, a queue column, and a rule for which hat wins. Hours means a published block (09:00 to 12:00 on the desk, 13:00 to 17:00 on systems, or whatever the volume supports) that users and colleagues can see. The queue column means that systems work goes into the same ticket system as desk work, under its own category or queue. That way, it is counted and can be pointed at when someone asks what you did all week. The rule is one sentence: during desk hours the desk hat wins unless a system is down for more than one person; during systems hours the systems hat wins unless a ticket is priority one. The solo form of this problem is the subject of the one-person IT department pillar.

The failure of the invisible dual hat is the afternoon that never comes. I wore both hats for two years at a site of a hundred and twenty users. For the first six months my patching window was "when it goes quiet", which it did not. The published block fixed it in a week. Users adjusted to the afternoon being for systems faster than I adjusted to the idea that I was allowed one.

The Handoff Contract

A handoff contract is a one-page agreement between the desk and each specialist that says what the desk must send with an escalation. It also says what the specialist must return, and in what time. It replaces the corridor conversation with a ticket both sides can read. It is the single document that most improves the relationship between a desk and its sysadmins. It is short because it has to be followed at 09:02 with the phone ringing.

What the desk must send is the set of facts that lets the specialist start work without a question. Include who is affected and how many, and what they see, in their words and in the desk's. Include when it started, and what changed around then. Include what the desk already tried and what happened, how urgent it is and why, and how to reproduce it, if the desk could. A ticket with those six things is a gift. A ticket that says "see user's e-mail" is a transfer of effort.

What the specialist must return is the finding, not just the fix. The finding covers what was wrong, what was changed, whether it will recur and what the desk should tell the user. It is written as an internal note on the same ticket. That way, the desk can close with the user and the knowledge base gets an entry. The ticket stays with the desk throughout: the specialist works on it, the desk owns it, chases it and closes it. The same contract, with a walk in the middle, governs the handoff to deskside, which Desktop Support as Its Own Function covers. Consider internal notes that are never mailed to the requester, which QuerySolv has. In a tool with those notes, the specialist's finding sits on the ticket where the next technician will find it and the user will not see the working.

The time is the part people argue about and the part that matters most. A return time is a promise from the specialist to the desk. It promises an acknowledgment within an hour during business hours, and a finding or an honest status within one business day. The promise includes an update at a fixed interval after that. It is not a fix time, because fix times depend on the fault. The point is that the desk knows when to chase and the user can be told when to expect news. Without a return time an escalation is a ticket thrown over a wall, and walls are not known for their replies.

Failure Mode One: The Desk as a Filter to Be Bypassed

The first way the relationship fails is that specialists come to see the desk as a filter in their way, and users learn to go around it. It starts reasonably: a user with a real problem walks over to the sysadmin, who fixes it in four minutes. And both conclude that this was efficient. It was, once. By the fiftieth time the sysadmin is doing a desk job without a queue. The desk's numbers undercount the real demand. The knowledge base has nothing about the fixes done at a desk. The next technician inherits a department that knows which person to interrupt.

The fix has to come from the specialist's side, because the desk cannot stop a user walking past it. The rule is that the specialist takes the walk-up kindly and logs it as a ticket before touching anything. Or the specialist sends the user back to the desk with the specific instruction "put it in and I'll have it within the hour". The second is better, because it teaches the route. The first is acceptable, because it keeps the record. What is not acceptable is the four-minute fix that leaves no trace, however good it felt.

The manager's part is to read the escalation numbers and notice when they fall while the sysadmin's day gets busier, because that pattern has one cause. A specialist who is always slammed with nothing assigned is not lazy and not a hero. They are a help desk that nobody counts.

Failure Mode Two: The Desk That Escalates Everything

The second failure is the mirror image: a desk that forwards anything unfamiliar to a specialist within minutes. As a result, the specialists become the desk and the desk becomes a routing table. This failure happens when the desk is junior and nobody has written down what it is allowed to touch. It also happens when an early mistake was punished and the desk learned that escalation is safe. Either way the specialist's queue fills with password resets wearing a server's name, and the desk stops learning anything.

The fix is a written line of what the desk may do without asking, and the handoff contract's first clause is that line. Password resets, account unlocks, printer queues, the standard application installs, the known fixes in the knowledge base: the desk's territory, no permission needed. Anything on a server, the network, or a system of record: escalate, with the six facts. The line moves outward as the desk gains confidence. And the specialist should want it to move, because every item that crosses it is an item they stop seeing. What sits at each level in a formal design is the subject of the support tiers pillar; here it is enough to have the line at all.

The number to watch is the escalation rate, which is escalated tickets divided by all tickets. For a desk of generalists with a knowledge base it should sit somewhere between one in ten and one in four. Above that the desk is routing. Below one in twenty, the desk may be sitting on things it should have sent, which is quieter and worse.

The Weekly Fifteen-Minute Review

A fifteen-minute weekly review between the desk and the specialists keeps both failure modes from settling in. Fifteen minutes is enough if it has an agenda. The agenda is four items. The first is the escalations open longer than the contract's return time, by name. The second is the walk-ups and corridor fixes the specialists took this week, so they can become tickets and articles. The third is the tickets the desk sent that the specialist thinks the desk could have handled, so the line moves. The last is one thing the desk is seeing a lot of, for the early warning. Then stop. If it needs an hour, the contract is not being followed, and that is the item.

Take the review at Northgate Retail on a Tuesday at 09:15. Priya runs the desk; Tomas owns servers and identity; Dana owns the network. Two escalations are over the one-day return time: ticket 7312, a shared mailbox that stopped syncing for the buying team, and ticket 7340, a wireless dropout on the mezzanine. Tomas commits to an update on 7312 by noon. Dana has 7340 reproduced and asks the desk to add the floor and access-point name to every wireless ticket from now on. Priya adds that to the form that afternoon. Tomas took three walk-ups last week and logs them. Priya sent him a printer-queue ticket he thinks the desk could own, and the line moves. Priya reports eleven tickets about the ordering application timing out, and Tomas, who had seen none of them, goes to look. Fourteen minutes.

The review works because it is boring, and I mean that as the highest praise available to a meeting. It does not need slides. It needs the queue on a screen, the contract on the wall, and the same four questions every week until nobody needs to ask them.

A Short War Story: Bluewater Bank and the Nearest Chair

At Bluewater Bank's head office, escalations from the help desk went to whoever was nearest. For two years that meant Tomas, because his desk was seven steps away and the network specialist's was on another floor. Tomas answered everything, by walking over, and the ticket system recorded none of it. So his manager's view was that the network team was busy and the systems team was quiet. The desk's new lead, Lena, wrote a one-page handoff contract. It specified six facts the desk would send, a finding the specialist would return, and an acknowledgment within an hour and a status within a day. The contract also specified a named queue for each specialist. The corridor escalations fell to almost none within a month, because a ticket in a named queue was easier than a walk. Tomas turned out to have been carrying about forty percent of the desk's escalations alone. The network team got their share for the first time. Nobody was blamed. The chart did not change at all.

A Handoff Contract to Steal

The contract below is one page on purpose. Fill in the specialist's name and queue, the return times you can keep, and the desk's territory line. Then pin it where both sides can see it. Review it in the weekly meeting when the line moves, and date the change. A tool whose departments carry their own permissions helps here. In QuerySolv each department has its own form, mailbox and per-agent permissions. So a specialist's named queue is a department they can see and the desk can escalate into.

HANDOFF CONTRACT: help desk and ____________________ (specialist or group)
Queue the desk escalates into: __________________   Agreed on: __________

1. THE DESK'S TERRITORY (no escalation needed)
   Password resets, unlocks, printer queues, standard installs,
   any fix in the knowledge base, and: ______________________________

2. WHAT THE DESK SENDS WITH EVERY ESCALATION
   [ ] Who is affected, and how many
   [ ] What they see (their words) and what we see (ours)
   [ ] Since when, and what changed around then
   [ ] What the desk tried, and what happened
   [ ] Priority, and the reason for it
   [ ] How to reproduce it, if we could
   The ticket stays with the desk. The desk chases it and closes it.

3. WHAT THE SPECIALIST RETURNS, AS AN INTERNAL NOTE ON THE TICKET
   [ ] What was wrong
   [ ] What was changed
   [ ] Whether it will come back, and what to watch for
   [ ] What to tell the user, in one or two sentences
   [ ] Whether it belongs in the knowledge base (yes / no / already there)

4. RETURN TIMES (business hours)
   Acknowledged:                within ____  (suggest one hour)
   Finding or honest status:    within ____  (suggest one business day)
   Updates while open:          every ____   (suggest one business day)
   If a return time will be missed, the specialist says so on the
   ticket before it passes, not after.

5. WALK-UPS AND CORRIDOR REQUESTS TO THE SPECIALIST
   Log it as a ticket before touching it, or send the user to the desk
   with "put it in and I'll have it within the hour". One or the other, every time.

6. REVIEWED weekly, fifteen minutes, desk lead and specialist.
   Last change to this page: __________   What moved: __________________

The Chart Is Not the Desk

An org chart answers one question, which is who signs the leave form. Support needs the answers to three others: who defends the desk's time, who takes its escalations, and who returns them. The reporting line answers the first if you choose it well. The handoff contract answers the other two. And it does not appear on any chart. That is why organizations with beautiful charts and no contract are surprised every morning by the same corridor.

Back at Bluewater Bank the chart still has the help desk under the Head of Technology, who still remembers his ticket fondly. Nothing about that needed to change. Tomas is still seven steps away. He now has a queue with his name on it. And the walk takes a little longer than the ticket, which is exactly as it should be.

Frequently Asked Questions