Ticketing system in Excel: a help desk tracker that works, where it breaks, and what replaces it
Most support teams start with a ticketing system in Excel, or its cousin in Google Sheets. One row per issue, a status column, a name in the "assigned to" column. For a small team handling a few requests a day, that is a reasonable place to be, and it is better than the alternative most teams start with: a shared inbox and good intentions.
Then volume grows, a second and third person starts answering, and customers start writing in to ask whether anyone has seen their first email. The spreadsheet breaks, and it breaks in the same five places every time.
This is the honest version: a help desk tracker structure that is worth copying, exactly where each part of it fails, and what your options are when it does.
The help desk spreadsheet worth copying
Most free help desk Excel templates are one sheet with a Notes column where the whole history of the ticket gets typed, overwritten and typed again. You lose the conversation the moment someone tidies the cell. Start with four sheets instead.
Sheet 1 — Tickets. One row per issue. The current state only; the history lives elsewhere.
| ID | Opened | Requester | Subject | Category | Priority | Status | Assignee |
|---|---|---|---|---|---|---|---|
| T-1203 | 2026-09-15 09:12 | dana@client.example | Can't log in after reset | Access | High | Open | Farah |
| T-1204 | 2026-09-15 10:40 | ops@client.example | Invoice total wrong | Billing | Normal | Waiting on customer | Omar |
Keep Status to a short, fixed list — New, Open, Waiting on customer, Resolved, Closed — with
data validation so nobody invents a seventh.
Sheet 2 — Activity. One row per thing that happened to a ticket. You never edit a past row; you add one.
| Ticket | Time | Who | Type | Text |
|---|---|---|---|---|
| T-1203 | 2026-09-15 09:12 | dana@client.example | Customer message | Reset link says expired |
| T-1203 | 2026-09-15 09:40 | Farah | Reply | Sent a fresh link, valid for 1 hour |
| T-1203 | 2026-09-15 09:41 | Farah | Internal note | Second report this week — check token expiry |
| T-1203 | 2026-09-15 11:02 | Farah | Status | Open → Resolved |
Keep replies to the customer and internal notes as separate types. That one distinction matters more than it looks: it is the difference between a note your team can read and a message the customer can.
Sheet 3 — Routing. Who picks up what, written down once instead of remembered.
| Category | Default assignee | Backup |
|---|---|---|
| Access | Farah | Omar |
| Billing | Omar | Farah |
Sheet 4 — SLA targets. What "on time" means per priority.
| Priority | First response within (hours) | Resolve within (hours) |
|---|---|---|
| High | 1 | 8 |
| Normal | 4 | 48 |
First response time is then derived from the activity log, not typed:
=MINIFS(Activity[Time], Activity[Ticket], [@ID], Activity[Type], "Reply") - [@Opened]
and a breach flag compares it with the target for that ticket's priority. Now "are we answering in time?" is a column, not a feeling.
The principle underneath is the one every real help desk is built on: the ticket holds its current state, and the activity log holds its history. Nobody edits history; they add to it.
Where it breaks
1. Tickets don't arrive in the spreadsheet
Requests come in by email, phone, chat and hallway conversation. None of them land in the sheet on their own. Somebody has to copy each one in, and on a busy day they don't. The ticket that was never entered is the one the customer escalates, and there is no record that it ever existed.
This is also why "any update?" follow-ups get worse, not better. The conversation lives in email; the spreadsheet holds a summary of it. The customer cannot see the status column, so the only way they have to check is to write in again — which creates another email somebody has to connect to the right row.
2. Two people answer the same ticket
Two agents see a new ticket at the same moment and both reply. The customer gets two different answers, or one agent undoes the other. Real help desks detect this collision and warn the second person before they send. A spreadsheet cannot: shared editing does not lock rows, and nothing tells you somebody else is already typing a reply in their mail client.
3. The SLA clock doesn't know about weekends
A four-hour response target means four business hours, and a ticket waiting on the customer should stop
the clock. The formula above does neither. You can make it count business hours with NETWORKDAYS and a
lot of patience, but pausing the clock while the ticket is Waiting on customer, and restarting it when
they reply, needs the full status history for every ticket. At that point your SLA report is the most
complicated formula in the building and nobody trusts it.
4. Nothing routes, reminds or escalates
The routing sheet tells you who should pick up a billing ticket. It does not assign it, remind them when it has sat for three hours, or escalate it to the backup when they are on leave. Every rule in a spreadsheet help desk relies on someone checking the spreadsheet. The tickets that fall through are the ones that arrive when nobody is looking.
5. The history can be rewritten
An activity log is only evidence if nobody can edit it. In a spreadsheet, anyone with access can change a past reply's timestamp, delete an internal note or quietly move a breached ticket's opened time. When a customer disputes what was said and when, you cannot show them a record you know is untouched.
What a real one has that a spreadsheet doesn't
We keep a hand-counted inventory of what help desk software actually ships, built from 18 help desks ranging from large SaaS products to open-source tools and low-cost scripts:
| Capability | Help desks (of 18) |
|---|---|
| Ticket lifecycle and statuses | 18 |
| Auto-assignment and routing | 17 |
| Custom fields | 17 |
| Automation — trigger, condition, action | 16 |
| REST API | 14 |
| SLA targets with breach views | 13 |
| Live chat | 13 |
| Collision detection | 10 |
| Knowledge-base suggestions on the request form | 10 |
Read it against the five failures. Routing and automation are almost universal — 17 and 16 of 18 — and they are exactly what failure 4 is about: rules that act on their own instead of waiting for someone to read a sheet. SLA views appear in 13, and they are the only fix for failure 3, because they need the full status history a spreadsheet does not keep.
Collision detection sits lower, at 10 of 18, and in several commercial products it is locked behind a paid plan. If two people answering the same ticket is already happening to you, check for it by name before you buy.
Your three options, honestly
Keep the ticketing spreadsheet
Correct for a small team — two or three people, a manageable daily volume, one channel. Use the four sheets above, keep replies and internal notes separate, and review the breach column weekly.
Stop when a ticket goes unanswered because nobody entered it, when two people answer the same customer, or when you cannot say whether you met your response target last month.
Buy software
Correct for most teams, and it can cost nothing. The free ticketing system guide covers where the free tiers stop and how to test one properly, and the open-source options trade money for maintenance. If you already live in Jira, using Jira as a ticketing system explains what works and when to stop.
The real cost is fit: their idea of a status, a queue and an SLA. For standard customer support that is fine. It gets awkward for teams whose tickets are really workflows — field visits, approvals, multi-step fulfilment — where a help desk becomes a place to record the work rather than do it.
Build it
A coding agent can now build a working help desk in days. It will build the ticket list, the reply box and a dashboard very quickly. What it tends to skip is the part your spreadsheet was already struggling with: an activity history nobody can rewrite, SLA clocks that pause and resume, routing that acts on its own, and a clear line between what the customer sees and what only the team sees.
If you build it, build these first
- A ticket lifecycle with a fixed set of states, and every change written to an activity history that cannot be edited afterwards.
- Replies and internal notes as different things, stored and shown differently, so a note meant for the team never reaches the customer.
- Intake from the channels you actually use, so a request becomes a ticket without anyone copying it.
- Routing and SLA clocks that act on their own — assign on arrival, pause while waiting on the customer, flag before the breach, not after.
- A way for the customer to see their own ticket's status, which removes most of the "any update?" traffic in one move.
Knowledge-base deflection, live chat and reporting dashboards are real scope, and optional for a first version.
For the full requirement list, see what an IT ticketing system has to do, counted across the same 18 help desks. And if you are building with a coding agent, the Helpdesk Ticketing planner is the spec we hand ours: the ticket lifecycle, the reply-versus-note boundary and the SLA rules, written so the agent cannot quietly skip them.