Day Zero: What You Need Before the First Ticket

It is 09:12 on day zero, and the queue is empty. Not quiet. Empty. There is a login page, a dashboard with zeros on it, and a settings menu that goes on for some time. You have been told to set up a help desk for an organization that has never had one, or to replace the shared mailbox that has been the help desk all along. Nobody is waiting on you yet. This is the only day that will ever be true.

The temptation is to fill the morning with configuration. Forty categories, three priority schemes, a workflow with swimlanes, a dashboard with eleven gauges. All of it feels like progress, and none of it has met a ticket. This article is the first in our Helpdesk From Scratch series, and it is about the smallest setup that works. The aim is for day zero to end with a desk and not with a settings menu you now have to maintain.

It covers the six things a desk needs before the first ticket, why six and not sixty, and what can wait a month. Then come the four decisions you cannot easily undo, and the many you can. We cover one afternoon at Kestrel Payroll, with times, and a war story from Acme about six weeks of configuration. We finish with a day-zero checklist to copy.

The Minimum That Works

A help desk needs six things before its first ticket: one queue, one intake address and one form, three categories, one owner, one reply template, and a page that says how to reach the desk. Everything else is either a refinement of one of those six or a feature waiting for evidence. If you have the six by the end of the afternoon, you have a desk.

One queue is a single list that holds every request the desk is working on, whatever route it came in by. That includes e-mail, the form, and a phone call written up by the technician. It includes a walk-up written up while the person is still standing there. All of it lands in the same list, as the same kind of ticket. The queue is the desk's memory and its only honest count. If work exists outside it, the count is wrong, and every decision made from the count is wrong too.

One intake address and one form are the two doors into the queue, and two is the right number on day zero. The address is something like support@example.com. It is the one you will print on the page and say in the announcement. You will defend it from well-meaning people who want a second one for their department. The form is the shortest one your tool allows: name, e-mail, a one-line summary, a description box. Every field you add is a field a user has to think about before asking for help. Nobody fills in the "Impact" box honestly, and that includes us.

Three categories are enough to sort the first month, and you will not know the right name for the fourth until the first month has happened. A category is the label that says what kind of thing a ticket is, so that the desk can count and route by it. Start with something like Access (accounts, passwords, permissions), Equipment (laptops, printers, phones, screens) and Software (anything that runs and is not running). A ticket that fits none of them goes in the closest one, with a note. After sixty tickets the notes tell you what category four is. Forty categories on day zero tell you what someone imagined in a meeting.

One owner is a named person who looks at the queue at fixed times and makes sure every ticket has an owner, even if that owner is them. On a one-person desk the owner is you. On a three-person desk the owner is still one person, by name, on a rota. The failure this prevents is the ticket everyone saw and nobody took, which is the most common ticket on a desk with no owner.

One reply template is the acknowledgment the desk sends when a human first looks at a ticket. It says that someone has seen it, who, and when the next update will come. "Thanks, I have this. I'll update you by 15:00 either way" is the whole template. It is the sentence that separates a desk from a mailbox, because a mailbox receives and a desk promises.

A page that says how to reach the desk is one screen of text: the address, the form, what to include, what happens next, and what the desk does not cover. It lives wherever people already look, which is the intranet, the wiki, or a pinned message. It is what you point to when someone asks "how do I ask you for things now?" Without it the intake address is a rumor, and rumors do not route well.

Why Six and Not Sixty

Each thing you add after the six needs a ticket to teach you where it belongs. A category needs ten tickets before you know it is a category and not a one-off. A priority scheme needs a week of real tickets to show which "urgent" requests were urgent. A service level agreement is a written promise about how fast the desk responds and resolves. It needs a month of actual times before it is a promise you can keep. Day zero has no tickets, so day-zero configuration is guessing with a nicer interface.

Configuration is not free after you make it, either. Every category must be chosen from, every field filled in, every workflow state explained to the person who gets stuck in it. A desk with forty categories spends part of every triage choosing among thirty-six wrong ones. Configuration you cannot yet justify is a tax on every future ticket, paid by the person least able to argue about it.

There is also a quieter reason. The empty queue is the one moment the desk has no evidence, and evidence is the only good reason to configure anything. Set up the six, open the doors, and let the first fifty tickets tell you what the desk is for. They will. Tickets are not shy.

What Can Wait a Month

Most of what the settings menu offers can wait a month. And the month is the point: by then you have the evidence to do it properly in an hour instead of guessing at it for a week. The table lists what to leave alone on day zero, why it can wait, and the signal that tells you the wait is over.

Ten articles is the right size for a day-zero knowledge base, and you already know what they are. Open the shared mailbox, sort by subject, and write down the ten questions that come up most. These include the password reset, the printer that needs the old driver, and how a new starter gets an account. Write each in under a hundred and fifty words. Everything after that is written from tickets, on the day they are solved.

Automation deserves its own warning. A rule that assigns every "printer" ticket to Marcus is a good rule in month three, when you know that Marcus wants them and that "printer" tickets are printer tickets. On day zero it is a rule that sends things to Marcus. Automate a process you have run by hand for a month. Before that you are automating a guess, and automated guesses are fast.

The Decisions You Cannot Easily Undo

Four day-zero decisions are hard to reverse. They deserve the hour you were going to spend on categories: the database, the ticket number format, the intake address, and the tool itself. None of them is dramatic. Each one gets more expensive to change with every ticket that arrives.

The database is the first. Most tools either create a built-in file database on first start or let you point them at a database server you already run. Both are fine. What is rarely fine is moving between them later, because many tools have no migration path between the two. The ones that do turn the move into a project with a weekend in it. Decide by asking one question: who will back this up, and do they already back up a database server? If yes, use that server. If the honest answer is "me, with a scheduled copy of a folder", the built-in database is the right choice, and a better one than a server nobody maintains.

The ticket number format is the second. Users quote ticket numbers in corridors and in e-mail subjects, and the tool uses them to thread replies to the right conversation. Pick the plain sequence your tool offers and leave it alone. Prefixes per department are tempting and you do not have departments yet. Whatever you choose will be in subject lines for as long as the desk exists, which is longer than the meeting where you chose it.

The intake address is the third. It will be printed, bookmarked, saved in contacts, pasted into runbooks and typed from memory for years. Make it short, generic, and owned by the desk rather than a person: support@example.com, not it-dana@example.com. Mailboxes named after people retire when people do. If a shared mailbox already exists and everyone knows it, keep the address and point it at the desk. The habit is worth more than a tidier name.

The tool itself is the fourth, and the cost of changing it is the subject of Choosing the First Helpdesk Tool. On day zero the point is only this: each change of tool loses history, search and habits, so the first tool is a decision for the next few years. Not forever, and not for a month.

The Decisions You Can

Everything else can be changed with a ticket's worth of effort, which is why each one should be decided in five minutes and revisited with evidence. Category names, priority labels, the fields on the form, the wording of the template, business hours, the name of the desk, who sits on it and when: all reversible. Decide, write down why, and put a date a month out to look again.

Naming is where the five minutes usually goes to twenty. You will be tempted to give the desk a name, a logo, and a mission statement. Give it an address. "IT Support" is a fine name, and a name that needs explaining is not.

One habit makes reversible decisions cheap: write the reason next to the decision. "Three categories because we have no data yet; revisit at sixty tickets" is a note that lets someone who was not in the room change the decision when the data arrives. A decision without a reason attached gets argued about by the people who were in the room, from memory. That is how organizations end up with a category called Other that holds a third of everything.

One Afternoon at Kestrel Payroll

Dana was the second administrator at Kestrel Payroll. The help desk until that afternoon had been a shared mailbox called helpdesk@example.com that Tomas read when he could. Dana had a half day and a list. Here is how it went, with times, because the times are the argument.

At 13:00 she installed the ticket tool on a server that already existed, and it started. At 13:25 she made the database decision. The finance team's SQL Server was backed up nightly by Tomas, so she pointed the tool at it and wrote down why. At 13:40 the mail administrator created support@example.com and set the old helpdesk address to forward into it. So nobody had to learn a new one. By 14:05 the form had four fields, and by 14:20 the categories were Access, Equipment and Software, with the reason noted.

At 14:35 she wrote the acknowledgment template, one sentence, and set herself as the owner who looks at the queue at 09:00 and 14:00. At 14:50 she put a page on the intranet: the address, the form, what to include, and what happens next. The page also said that the desk does not cover the payroll application itself, which Kestrel's vendor supports. At 15:10 she sent a test ticket from a non-IT account and the receipt came back at 15:11.

At 15:30 she asked Priya in payroll to send something real. Priya's e-mail about an undetected second screen arrived at 15:34 and became ticket 1. The acknowledgment went at 15:36 ("I'll update you by 16:30 either way"), the cable was reseated at 15:58, and Priya confirmed at 16:02. Day zero was done at 16:05, three hours after it started. Dana had not touched tiers, SLAs or the dashboard. The dashboard showed one ticket, resolved, which is the most honest a dashboard will ever be.

A Short War Story: Six Weeks at Acme

Acme's desk project started with a workshop. Marcus and two colleagues spent the six weeks before launch configuring forty categories, three SLA tiers with separate response targets, a priority matrix, and an assignment rule for every category. The launch itself went fine. In the first month two hundred and twelve tickets arrived. When Marcus pulled the numbers at the review, ninety-four percent of them fit in four categories, two of which were not among the forty. The SLA tiers had never been breached, because nobody had set a priority above Normal, because nobody had understood the matrix. They cut the categories to five that afternoon, kept one SLA, and the next month's triage took half the time. Nothing had been lost but six weeks, and the forty categories, which nobody missed.

I have done a smaller version of this myself. My first queue had a Miscellaneous category by week two. By month three it was the biggest one. That is what happens when the categories are invented before the tickets. The tickets were right. The categories were a guess.

The Day-Zero Checklist

Below is the checklist for the afternoon: the six things, the four decisions that are hard to undo, and the list of what is not today. Print it, fill it in, and keep it with the desk's other pages. In a month you will want to know what you decided and why.

DAY ZERO CHECKLIST
Desk: ______________   Owner: ____________   Date done: ________

THE SIX THINGS (done before the first ticket)
[ ] One queue        Every route lands in one list. Nothing is worked
                     on outside it.
[ ] One address      Address: ______________ (owned by the desk)
    and one form     Form fields: name, e-mail, summary, description.
[ ] Three            1. ____________  2. ____________  3. ____________
    categories       A ticket that fits none goes in the closest, with a note.
[ ] One owner        Name: ______________  Looks at the queue at ____ and ____.
[ ] One reply        "Thanks, I have this. I'll update you by ____ either way."
    template
[ ] The page         Lives at: ______________
                     Says: the address, the form, what to include,
                     what happens next, what the desk does not cover.

THE FOUR DECISIONS THAT ARE HARD TO UNDO (decided, with the reason)
[ ] Database         Built-in / server: ____________  Backed up by: ________
[ ] Ticket numbers   Format: ____________  (plain sequence unless there is a reason)
[ ] Intake address   ______________  Owned by the desk, not a person.
[ ] The tool         ______________  Chosen for the next few years, not forever.

NOT TODAY (revisit at sixty tickets or one month, whichever comes first)
    tiers, SLAs, categories four and up, dashboards, automation rules,
    knowledge base beyond ten articles
Revisit date: ________   Reasons written next to each decision: [ ] yes

The Afternoon You Saved

Day zero done in three hours leaves you with the rest of the day, and there are better uses for it than the settings menu. Send one more test ticket from a non-IT account and read the receipt as a user would. Write the first three of the ten knowledge articles, from the top three subjects in the shared mailbox. Draft the announcement, which has its own article in Announcing the Helpdesk to the Organization. If there is still time, write the first of the five one-page processes from The First Five Helpdesk Processes. That process is intake, and you have already done it without writing it down.

What makes day zero an afternoon rather than a week is mostly the tool's setup cost, and that is worth knowing when you choose one. Consider a tool that creates its own database on first start and needs no web server, runtime or container platform to set up. You can install it, point it at an address and test it before lunch is over. QuerySolv runs as one Windows service and creates an SQLite database on first start, so day zero is mostly deciding rather than installing. The database choice (SQLite, MySQL/MariaDB or SQL Server) is one of the decisions to make before real tickets arrive. That is because there is no migration tool between them. Whatever tool you have, find out which of its decisions are permanent before the first ticket makes them for you.

I have built three desks from nothing. And the one I configured least ran best, because every setting it had was there to answer a ticket that had already happened. The settings menu will still be there in a month. The empty queue will not. Tomorrow it will have tickets in it, and it will never be empty again, which is the whole point of what you built this afternoon.

Frequently Asked Questions