Choosing the Support Model for Your Size

The document is called the Target Operating Model, and it is sixty-two pages long. Dana, Marcus and Priya are the whole of IT at Northgate Retail's head office. They have been reading it in the small meeting room since ten past nine. Page fourteen has an org chart with nine boxes on it. "Which one of us is the Service Delivery Manager?" asks Marcus. "All of us," says Dana. "We are also the Problem Manager, the Change Advisory Board and, I think, the Major Incident Commander." Priya has found the page that says the service desk should be staffed in three shifts. She does not say anything. She is the service desk.

The model is not wrong. It was written for an organization of three hundred people with a dozen in IT, and for that organization it is fair. Nobody wrote one for three people, so the three people are reading the one for twelve and trying to work out which pages apply to them. The answer is about four pages, and you already know what is on them.

This article is part of our Helpdesk vs Service Desk series, which sorts out what the three names mean and which shape of desk fits which organization. It covers the five variables that decide the shape. Then come three models for three sizes, and which fits a team of two, five and fifteen. Next come a decision table and a self-placement worksheet to steal, then how to grow from one model to the next without a reorganization. Finally, there is the trap of buying the model for the company you hope to become.

The Variables That Decide the Shape

Five variables decide which support model fits, and headcount is only the first of them. Headcount supported is the number of people who can open a ticket. That is usually larger than the number of employees once contractors and shared mailboxes are counted. Sites is the number of places a technician might have to physically go. Ticket volume is tickets per month, measured rather than guessed, because the guess is always low. Hours is the span of the day and week during which someone expects an answer. Request mix is the share of tickets that are requests (I need something) rather than incidents (something broke).

Sites and hours matter more than people expect, because they multiply the work rather than adding to it. One site with two hundred users is a desk and a walk. Four sites with fifty users each is a desk, a car, and three places where the printer is wrong and nobody can see it. A warehouse running until 22:00 is a shift roster, a handover, and a rule about what the evening person may touch.

Request mix decides whether you need a service desk at all. A desk where nine tickets in ten are incidents is a help desk whatever it is called. A desk where four in ten are requests (new starters, access, equipment, software) needs a form that captures the request on the first pass. It also needs a way to track work that other teams do. Here it is a number: sort your last hundred tickets into the two piles.

Measure all five before reading further, because an honest count beats a flattering one. I once sized a desk on the headcount in the HR system and discovered a hundred and forty contractors who were not in it but did have laptops. The laptops knew where the desk was.

Up to About Seventy-Five Users: The Generalist Desk

Up to about seventy-five users, the right model is a generalist desk: one or two people, one queue, and everyone does everything. There are no tiers, because there is nobody to escalate to who is not already looking at the queue. There is no deskside role, because the person who answers the e-mail is the person who walks over. The whole model fits on an index card: every request becomes a ticket, one person triages twice a day, and the oldest urgent ticket is worked first.

The generalist desk works because the overhead of structure would cost more than the structure saves. Splitting ninety tickets a month into two queues gives you two queues of forty-five and one more thing to forget to check. The one piece of structure it does need is a single queue, by every route in. In QuerySolv's case the web form, e-mail, live chat, social messages and the API all land in the same queue as the same kind of ticket. That is the shape to aim for whatever you run.

What goes wrong at this size is not structure but capture. The generalist desk is close enough to its users that requests arrive by shoulder tap, and shoulder taps do not make tickets. The desk becomes a person, and the one-person IT department pillar is about surviving that. The signal that you have outgrown this model is not a headcount. It is the first week in which the two of you cannot tell each other what is open.

Seventy-Five to Three Hundred Users: Desk, Deskside and an Escalation Path

Between about seventy-five and three hundred users, the model grows to three parts. These are a desk that owns the queue, a deskside role that owns the physical work, and a written escalation path to whoever runs the servers and the network. The desk is still generalist in what it answers. What has changed is that there is now enough physical work (moves, swaps, imaging, the printer on the second floor) to keep one person walking. There is also enough server work to keep another away from the queue.

Deskside splits from the desk first, because walking is the work that stops the queue. One technician doing both loses the queue every time they go under a desk. The fix is a second queue, or at least a second column, for visits, batched into blocks. The signals for the split and the handoff between desk and deskside are in Desktop Support as Its Own Function. For sizing, the rule of thumb is one deskside technician per site with more than about eighty people on it.

The escalation path is a written rule, not a tier, and at this size it needs one page. It says which kinds of ticket go to which specialist, what the ticket must contain before it goes, and how long the specialist has to come back. The desk keeps the ticket while the specialist works on it. Tiers as a formal design belong to the support tiers pillar. What matters here is that the path exists on paper rather than in the corridor, because corridors do not keep records.

Three people can run this model, and five run it comfortably. Take Acme, which has two hundred and ten users on two sites and five people in IT. Two share the desk queue, which runs at about three hundred and forty tickets a month. One is deskside, with visits batched into 09:30 to 11:00 and 14:00 to 15:30, pre-triaged remotely so the technician arrives knowing the fault. Two are specialists, one for servers and one for the network, each with a named queue that the desk escalates into. On a typical Monday the desk takes nineteen new tickets, escalates two, sends four to deskside, and closes fourteen itself before 17:00. Nobody on that team has a title longer than their job.

Three Hundred to a Thousand Users: A Service Desk With Specialists Behind It

From about three hundred users up to about a thousand, the model is a service desk. That is a team that takes incidents and requests through one door, owns every ticket to the end, and has a deskside team and specialist groups behind it. A service desk here means a desk that handles requests as a class of work with its own forms and tracking, not a help desk with a better name. At this size requests are routinely a third or more of the volume. They involve other teams (HR for starters, finance for approvals, facilities for the desk and the chair). So somebody has to own the whole chain or it stalls at the handoffs.

The desk is now large enough to have an internal shape. Four to eight people on the queue, one of them a lead who reads the numbers instead of taking tickets in the morning. A form for each common request. A "waiting on another team" status that the desk still owns and chases. And a weekly look at requests as a category: which take longest, which bounce, which could be an article instead of a ticket.

Specialists at this size are groups rather than individuals, and the escalation path becomes a handoff contract between teams. The desk sends a ticket with a stated set of facts. The specialist group returns it within a stated time with a stated set of findings. The desk closes with the user. The contract and the org chart around it are in Org Design and Reporting Lines for Support. Specialists stop being people the desk knows and become queues the desk feeds, and queues need rules that people did not.

What goes wrong at this size is over-building. The service desk model attracts process the way a shared drive attracts folders called "old". Fifteen request forms where five would do, a change board that meets to approve font changes, a priority matrix nobody can apply at 09:02 with the phone ringing. The defense is to add a form, a status or a meeting only when a counted problem demands it. Write the problem down so the thing can be removed when the problem goes.

The Three Models Side by Side

Laid side by side, the three models are one desk growing new parts rather than three different designs. First comes one queue that everybody works. Then come a desk queue, a deskside queue and an escalation path to named specialist queues. Then come incident and request queues, a deskside team, and specialist groups for servers, network and applications. They come with the rule that the desk owns every ticket to the end. The first step adds a request form and a deskside queue. The second adds a request queue and the ownership rule.

The decision table puts the five variables, plus staff count, against the three models. The column that collects most of your rows is your model. If the columns split evenly, take the smaller model. In that case, add the one part of the larger one that your biggest variable demands: a deskside queue for sites, a request form for request mix.

What Fits Two, Five and Fifteen People

The staff count maps onto the models cleanly. Most readers know how many people they have before they know how many users they serve. Two people in IT run the generalist desk, and that is the whole design. Both work the queue. One triages in the morning and the other in the afternoon. The server work is done in the gaps and on Fridays. The one structural decision is a written note of who is on the queue when. That way, a walk-up is pointed at the right person instead of the nearest one.

Five people run the middle model, as Acme does above. There are two on the desk, one deskside, and two specialists who take escalations into named queues and otherwise stay off the help desk. The temptation at five is to have everyone take tickets from the general queue, which feels fair and produces five people half-watching one queue. Give the desk to two, and make the other three reachable only through it.

Fifteen people run the service desk model, and at fifteen the shape starts to need a chart. There are five or six on the desk including a lead, and three or four on deskside across sites. The rest are in specialist groups of two or three (servers and identity, network, applications). The lead owns the numbers and the handoff contracts, and it is the first role that does not touch a ticket every day. It is also the first role to get a title with the word "delivery" in it, which is harmless so long as the person still knows where the queue is.

The sizes in between run the smaller model with one borrowed part. Three people run the generalist desk with a named deskside block, and eight run the middle model with a request form.

Growing From One Model to the Next Without a Reorganization

Moving from one model to the next does not need a reorganization. The three things that change first (the form, the queue split and the ownership rule) are all inside the ticket system. Change those, in that order, and the org chart can catch up a year later, or never.

The form changes first. A generalist desk has one form that asks what is wrong. The moment requests are a quarter of the volume, add a second path on the same front door that asks what is needed. Give that path the fields that let the request be fulfilled (who for, by when, who approves). The form is the cheapest change in the system and it reshapes everything downstream.

The queue split changes second. Give deskside its own queue or column the week the walking starts to stall the desk. Give each specialist a named queue the week the corridor escalation loses its first ticket. A tool with departments that are really separate makes this configuration rather than a project. QuerySolv's departments each carry their own form, mailbox, custom fields and per-agent permissions. So a second queue is an afternoon's work. On a shared mailbox it is a folder and a rule, which also works and costs more typing.

The ownership rule changes last and matters most. In the generalist desk, whoever picked the ticket up owns it. In the middle model the desk owns it until the specialist returns it. In the service desk the desk owns it to the end, through every team. In that model, a ticket waiting on facilities is still the desk's ticket and still gets chased. Write the rule in one sentence and put it where the desk can see it. The rename that usually accompanies these changes is covered in Renaming the Desk Without Reorganizing It. The name is the least important of the four changes and the one people argue about longest.

The Trap of Buying the Model for the Company You Hope to Be

The most common sizing mistake is to adopt the model for the organization you plan to be in three years rather than the one you are in now. It is an easy mistake, because the larger model is the one that gets written about, the one on the consultant's slide, and the one the bigger tools are designed around. A three-person team that installs a service catalog, a change board and a priority matrix gets all the overhead of the model and none of the volume that justifies it.

The overhead is not abstract. Every form field nobody needs is filled in wrongly by everyone, and every status that does not match a real state becomes a place to hide tickets. I once inherited a desk of four that ran a weekly change advisory board, whose main output was agreeing that nothing had changed.

The honest way to plan for growth is to choose the smaller model and know which part you will add first. Write that on the worksheet below as the next change, with the signal that triggers it (requests pass a quarter; a second site opens; the deskside technician loses two hours a day walking). Then stop. We sell help desk software, and vendors like it when you buy the bigger thing, so discount our enthusiasm and check the reasoning against your own count.

A Short War Story: Kestrel Payroll, Sixty to Two Hundred

Kestrel Payroll grew from sixty people to two hundred in a little under three years. The help desk was Lena and Sam throughout, with Marcus joining in the last year. At sixty they ran the generalist desk: one queue, one form, both on everything. At about a hundred and ten, new-starter requests began arriving by e-mail with half the information missing. Lena added a request form with the six fields the starter process needed. At about a hundred and sixty, Sam was spending his mornings walking the second floor. So they split a deskside column out of the queue and batched his visits into one block a day. That was the whole change: a form and a second queue. Nobody was retitled, no chart was drawn, and the model held for two years. Then Marcus took the deskside column full time. The desk found it had become the middle model without anyone announcing it.

I like that story because the desk changed the two things it could measure and left everything else alone. The org chart at Kestrel still said "IT" in one box. Nobody minded.

The Self-Placement Worksheet

The worksheet takes ten minutes with last month's ticket count and the HR headcount in front of you. Fill in the six rows with counts rather than impressions, circle the model each one points to, and let the majority decide. Then write the next change and its signal, so the decision is already made on the day the signal arrives.

SUPPORT MODEL SELF-PLACEMENT
Organization: ______________   Date: __________   Filled in by: ___________

Variable                         Your count         Points to (circle one)
-------------------------------  -----------------  ----------------------------
Headcount supported (including
  contractors, shared accounts)  ______ people      G (to 75)   M (75-300)   S (300+)
Sites a technician must visit    ______ sites       G (1)       M (2-4)      S (5+)
Tickets per month (measured)     ______ tickets     G (to 150)  M (150-600)  S (600+)
Hours someone expects an answer  ______ to ______   G (bus.)    M (+shift)   S (roster)
Requests as a share of tickets   ______ percent     G (to 25)   M (25-33)    S (33+)
IT staff who take tickets        ______ people      G (1-2)     M (3-6)      S (8+)

Majority model:   [ ] G  generalist desk, one queue
                  [ ] M  desk, deskside, escalation path
                  [ ] S  service desk, deskside team, specialist groups

Borrowed part, if the columns split: _____________________________________
Next change (form / queue split / ownership rule): _______________________
Signal that triggers it: _________________________________________________
Review again on: __________ (or when a site opens or headcount jumps)

Back at Northgate Retail, the three of them reach page fifty-one, the operating model's own self-assessment. They discover that they are at maturity level one. They decide this is fine. They write the generalist desk on an index card and add a request form the following week. They put the sixty-two pages in a drawer for the day they have three hundred people. That is not a criticism of the document. It is a size.

Frequently Asked Questions