The Greenfield Playbook: Ninety Days on One Page

It is day ninety, a Monday, and you have been away for a week. The first thing you notice is that nobody notices. The queue has fourteen open tickets, every one with an owner. The oldest is five days old and says in its status what it is waiting for. There is a note on your desk from Sam: "Three things I had to guess. Added them to the runbook. Printer on two is haunted again." Nobody asks where you were. Nobody has been saving things up for you. That, not the dashboard or the launch e-mail, is the finish line.

Ninety days is enough to build a help desk from nothing to the point where it runs without the person who built it, provided they are spent in the right order. This article is the last in our Helpdesk From Scratch series. It puts the other five on one page. A greenfield desk is one built where there was none before, or where there was only a shared mailbox and a person everyone knew to ask. That is the same thing with worse records.

It covers the shape of the ninety days, then the plan week by week, with the one thing added each week and the number watched. Next come each month in detail, including the handover test, and what comes next and which pillar owns it. Then come the things that will go wrong and roughly when, a worked example of handover week, and a war story from Acme. Finally, there is the playbook on one page.

The Shape of Ninety Days

The ninety days have three jobs in order: month one, run; month two, tune; month three, hand over. Month one gets tickets flowing through one queue with five small processes and a launch the organization heard. Month two changes things based on what month one's tickets said. Month three proves the desk is a system rather than a person, by taking the person out for a week.

The order matters more than the dates. Tuning before running means tuning to a guess, which is how a desk ends up with forty categories before its first ticket. Handing over before tuning means handing over the rough edges with the desk. Running without ever tuning or handing over is how the shared mailbox happened the first time.

Each week adds one thing and watches one number. One thing, because a desk that is also being built can absorb about one change a week without the people using it feeling the ground move. One number, because the change should show up somewhere, and if it does not, next week's should be a different one.

The Plan Week by Week

The table is the plan. The rest of the article is the reasoning, which you will need when a week goes sideways and you have to decide what to drop. Twelve weeks cover eighty-four days; the last six are slack, and you will use them.

If a week slips, slip the whole plan a week rather than doubling up. Two things added in one week is how you find out which one broke the other, and the answer is usually both. The spare days exist for this.

Month One: Run

Month one gets real tickets through one queue, with the smallest set of habits that keeps them from being lost. It tells the organization in a way it hears. Four things happen: day zero, the five processes, the launch, and the first review. Each has its own article; this section is the order and the joins.

Day zero is one afternoon in week one. Six things before the first ticket: one queue, one address and one form, three categories, one owner, one reply template, and a page that says how to reach the desk. Four decisions that are hard to undo, each with its reason written beside it: the database, the ticket number format, the intake address, and the tool. Everything else waits, and the urge not to let it wait is the first entry in the table of things that go wrong, below.

The five processes are written in week two, one page each, while a friendly department pilots the desk and finds the rough edges. The processes are intake, triage, escalation, close and the weekly review. Each comes with what it is, the one-page version and the failure it prevents. Five pages is an afternoon's writing and the whole operating manual for six weeks.

The launch is a Tuesday in week three. It has three touches: the managers' briefing in week one, the announcement on the day, and the follow-up two weeks later with numbers in it. The walk-up card goes on the desk the same morning. For the rest of month one every walk-up becomes a ticket opened on the user's behalf. The old mailbox gets its autoreply and keeps forwarding.

The first review is the week-four weekly review with a full week of real tickets behind it. Then comes the first monthly note on day thirty: volume by category, the oldest open ticket, the reopen rate, and what changed because of them. Month one ends with that note sent. If it ends with a dashboard instead, month two is spent explaining the dashboard.

Month Two: Tune

Month two changes four things, each because month one's tickets asked for it. They are the categories, the first ten knowledge articles, the known-error list, and the request form if requests are many. None is written from imagination, which is the only reason month two can be short.

Categories grow from evidence in week five. Read every ticket in "Other", which by now is between a fifth and a third of the queue, and sort them into piles on paper. A pile of ten or more is a category. Stop at ten in total. A category list is a form the requester fills in, and every entry past ten is a guess they will get wrong. The three day-zero categories were never going to be right. They were there so the right ones could be found.

The first ten knowledge articles come in week six, from the tickets the desk has solved most often. Each is a symptom, a cause, and the steps, in under a hundred and fifty words. It is agents-only first and published to requesters once the desk has used it twice without wincing. A knowledge base with a state between draft and published lets the desk be honest about which articles it trusts. QuerySolv's has three (published, agents only, draft) and an outdated flag instead of a delete. That is the minimum a month-two knowledge base needs. The sign the articles are working is the repeat count on the top three issues falling in week seven.

The known-error list is written in week seven. It lists the problems the desk knows about, has not fixed, and has a workaround for, each with the ticket that first reported it. The list is a page, not a system. It stops the desk re-diagnosing the second-floor printer every time it jams. Watch how many tickets match an entry: a known error with twelve tickets attached is a fix that has become cheaper than its workaround.

The request form is week eight's addition, if the count justifies it. A request is something not broken but wanted: access, equipment, a new starter. If requests are a third or more of volume, they deserve a short form with the three questions the desk always has to ask back, and their own path through triage. If they are a tenth of volume, a form is a wall with a door nobody uses. Day sixty closes the month with the second note.

Month Three: Hand Over

Month three proves the desk is a system by removing its builder for a week, then decides on evidence what the desk becomes next.

Week nine switches off the old mailbox. By now its forwarded traffic should be a handful of messages a week, mostly from outside the organization and from automated senders nobody updated. The autoreply stays on for months; the forwarding stops. The same week, the runbook is assembled. It brings together the five pages, the category list, the known-error list, the escalation contacts, and every change the weekly reviews made. All are in one place that is not your head. The shape each of those pages should take, and a copyable one, is in The Help Desk SOP.

Week ten is the handover test. A colleague who has never run the desk runs it for a week from the runbook. You do not help. Not "do not help much". You sit somewhere else and answer no questions about the desk. Write down every question asked, because each is a sentence missing from the runbook. If the week is too busy to run the test, that is the reason to run it.

Week eleven writes the gaps in. Week twelve is the first quarterly review. It covers the three numbers across ninety days, against month one, with the handover findings beside them. Take a tool whose reports run over seven, thirty or ninety days. Suppose they show backlog by age and resolution time at the median and ninetieth percentile. That tool gives the review most of its material for free. QuerySolv's reports offer that, with a CSV export for the page that goes to whoever asked for the desk. The review ends with one decision, and the next section is about making it.

What Comes Next, and Who Owns It

Day ninety's decision is which of four things the desk needs next: tiers, SLAs, more channels, or a written scope. Possibly none yet. Each has a sign in ninety days of tickets that says it is time. Each has its own pillar, because each is a bigger job than a week.

• Tiers (a first line that resolves the common things and a second that takes the rest) may be next. The sign is one person on most hard tickets and a queue that slows when they are away. See designing support tiers.
• SLAs (written, measured targets for response and resolution by priority) may be next. The sign is a manager asking "how fast do you promise?" and the honest answer being a shrug. See SLA design.
• Channels (chat, a phone line, a second form) may be next. The sign is a department that will not use e-mail, or a walk-up count that has not fallen. Add a channel only into the same queue. See channel strategy.
• Scope (a written list of what the desk supports and what it does not) may be next. The sign is tickets about personal phones and home printers, each decided differently depending on who triaged. See defining what IT supports.

Choose one. The desk has just absorbed twelve weekly changes and a week without its builder. It can take one more project next quarter and do it well. It can take two badly. The playbook's last line is not "add everything". It is "decide one thing, from the numbers, on purpose".

The Things That Will Go Wrong, and When

Every greenfield desk hits the same eight problems at about the same points. Knowing the week takes most of the sting out. None is a failure of the plan. They are the plan meeting an organization, which is what plans are for.

One of the eight deserves a sentence more. The handover test is the one most often skipped, always for the best reason, which is that the desk is busy. A desk that cannot be handed over in a busy week has not been handed over. It has been lent.

A Worked Example: Handover Week at Bluewater Bank

Tomas built the Bluewater Bank branch support desk from nothing. In week ten he handed it to Dana, who had been at the bank six months and had never triaged a ticket. The runbook was eleven pages: the five processes, nine categories, seven known errors, the escalation contacts, and the changes from eight weekly reviews. On the Monday morning Tomas moved to another floor with a notebook and an agreement with himself to answer nothing.

The first question came at 09:10 on Monday: where is the vendor contact list? It was in a folder the runbook did not name. By Wednesday there had been five questions, four of them the same question in different clothes: who approves an access request for the lending team? The runbook said "the department head"; the lending team had two, and they disagreed. Dana picked one, wrote down that she had, and carried on. The seventh and last came on Friday at 15:40, about whether the Friday payroll freeze applied to printer drivers. The runbook should have answered that and now does.

The week's numbers were forty-eight tickets opened, forty-four closed, and two reopens. The oldest open ticket at 16:00 on Friday was three days old and waiting on a vendor, with a date. Seven questions meant seven lines added to the runbook. The lending-team approval question became the first line of the request form in week eleven. Tomas took the next week as leave, which was the real test. The desk was quiet.

I ran a handover week on my own desk once without planning to, with a bad cold and a colleague five weeks into the job. The desk held. What broke was the one thing I had been meaning to write down. That is always the thing that breaks, and the reason to run the test before the cold arrives.

A Short War Story: Ninety Days at Acme

Priya built Acme's help desk from a shared mailbox and a spreadsheet in ninety days. The plan held everywhere except for two days in week nine. The old mailbox was due to be switched off that week. By week six it was down to three messages a week, mostly from a supplier's invoicing system that nobody had updated. She switched it off on a Wednesday at 10:00. For two days nothing at all happened. She had not expected that and did not trust it. On the Friday, finance asked where their invoice confirmations had gone. The autoreply, which was still running, had already told the supplier the new address. The confirmations arrived in the queue the following Monday as tickets with a category of their own. Nothing was lost, nobody was blamed, and the known-error list gained an entry about automated senders. The desk's ninetieth day was the first day the spreadsheet was not opened by anyone. Priya only noticed on day ninety-two.

The Playbook on One Page

This is the whole plan in the form you will pin above the desk. Fill in the dates on day zero and cross off each week as it goes. When a week slips, move every date below it rather than squeezing. The finish line is at the bottom so it is the thing you look at when the middle weeks are hard.

THE GREENFIELD PLAYBOOK: NINETY DAYS
Desk: ____________   Builder: ____________   Day zero: ________

RUN        Wk 1  day zero; managers briefed      Wk 2  five processes; pilot dept
           Wk 3  launch, Tuesday                 Wk 4  first review; day-30 note
TUNE       Wk 5  categories from evidence        Wk 6  first ten articles
           Wk 7  known-error list                Wk 8  request form?; day-60 note
HAND OVER  Wk 9  old mailbox off; runbook        Wk 10 handover week
           Wk 11 runbook gaps fixed              Wk 12 quarterly review

Next quarter, ONE of:  [ ] tiers  [ ] SLAs  [ ] channels  [ ] scope  [ ] none yet
Finish line: the desk ran a week without the builder, and nobody noticed.
Date it happened: ________

When the date at the bottom is filled in, the desk is no longer a project. It is a thing the organization has, like the payroll run or the front door. It is maintained by whoever is on it that week from a runbook tested by someone who did not write it. You will get a week off. Someone will leave a note. The printer on two will be haunted again, the note will say so, and nobody will need you back early for it.

Frequently Asked Questions