When to Add Tools, and When the Spreadsheet Is Still Enough

Tuesday, 14:00, the budget meeting at Acme. Dana is the IT department: seventy staff, one building, a spreadsheet called "IT jobs" with thirty-one open rows, and a reputation for fixing things by Thursday. The managing director, halfway down the agenda, says "Shouldn't we have a proper system for this? Everyone seems to have one." It is a fair question and Dana has been asked it before. It came in a vendor's e-mail, from a new sales manager who had a ticket system at his last place, and from her own mother. Her answer today is the one this article is about: not yet, and here is exactly how I will know when.

A tool decision is the choice to add a piece of software to the way the desk works. First comes a ticket system, and later remote control, a knowledge base, monitoring that opens tickets, and automation. The decision has triggers, conditions in the desk's own work that a tool fixes and nothing else does. And it has false triggers, which are everything else. A desk that adds a tool on a real trigger gets its hours back within a quarter. A desk that adds one on a false trigger spends a quarter configuring it and ends up with the same problem, now with a licence. This article is part of our Scaling Support Through Growth series. And it sits between the article on adding heads and the one on adding process. A tool is the middle lever: cheaper than a person, dearer than a habit, and useless without the habit.

It covers the spreadsheet that was enough and why. Then come the three triggers for a ticket system: a second person, a reporting question nobody can answer, and a channel nobody owns. Next it covers the triggers that are not, the tool that will not fix a process, and choosing without overbuying. The migration as part of the decision, the other tools and their own triggers, a short war story, and the tool trigger list follow, in that order. The list is there to copy.

The Spreadsheet That Was Enough

A list is a help desk tool, and for one person at a small organisation it is the right one. Dana's spreadsheet has a row per request with a date, a name, a one-line description, a status and a note. It does the three things a solo desk needs. It exists outside her head, shows what is open, and can be sorted by date so the oldest row is at the top. The solo series in Running Support Solo is built around exactly this list, and nothing in this article is a criticism of it. A list kept honestly beats a ticket system kept badly.

What the list cannot do is also worth saying plainly, because the triggers are the moments those limits start to cost hours. It has one editor, so it fails when there are two. It has no memory of its own changes, so a deleted row is gone and a changed status has no history. It is not visible to the requester, so every "what happened to my request?" is an interruption. It does not count itself, so a question about last quarter is a question about Dana's afternoon. And it cannot receive anything. Every request arrives somewhere else, in the mailbox, the corridor, the chat, and has to be typed in by hand. That means the list is only as complete as the typist's memory at five o'clock. None of those is a problem at seventy staff and one technician. Each becomes one at a particular moment, and the moments are the triggers.

Trigger One: More Than One Person

The first trigger is the second person, and it fires on their first day. Two people cannot share one person's list, because a list has no idea of ownership. It does not know who is working on row fourteen or stop both people opening the same request at once. It does not record that the handover on Friday afternoon moved six items from one name to the other. Within a month of the second person starting, the desk has the conversation that every two-person desk has had: "I thought you had that one." The request in question is three weeks old and the requester has stopped asking.

What the tool adds at this trigger is a queue with a name on every ticket and a history of every change. It also adds a handover that is a filter rather than a conversation. The mechanics of ownership, and why a group queue is a place a ticket belongs to nobody, are in Keeping Tickets From Hiding. The trigger is not the headcount; it is the second editor. A solo desk at a hundred and fifty staff can run on a list, and a two-person desk at eighty cannot. The one-person desk that is about to become two should have the tool in place before the second person's first day. That way, the first thing they learn is the queue and not the spreadsheet they will have to leave.

Trigger Two: A Reporting Question Nobody Can Answer

The second trigger is a question about the desk's work that the desk cannot answer without an afternoon and a highlighter. "How many requests did finance raise last quarter?" "How long do people wait, on average, for a password reset?" "Is the warehouse scanner problem getting worse?" These are reasonable questions, usually asked by the person who pays for the desk. And the first time one is asked, a list can answer it with an afternoon's tallying. The third time, the afternoon is a trigger. The desk is being asked to manage from numbers and has no way to produce them that does not cost the hours the numbers are meant to save.

What the tool adds is counting that happens because the work happened. That covers volume by month, by category, by department, and the age of what is open. It also covers the time between a request arriving and the first reply. The first three numbers a desk should look at, and why those three, are in First Metrics, and the point here is narrower. The trigger fires when a decision is waiting on a number. A desk may want a second person or want to retire a category of work. Or it may want to explain to the finance director why the warehouse is unhappy. In those cases, the desk needs the number to exist already, and a list will never have it. The sentence that fires this trigger is "I'll have to go through the spreadsheet", said for the third time.

Trigger Three: A Channel Nobody Owns

The third trigger is a route into the desk that nobody is responsible for. The commonest is the shared support mailbox. It is an address that both technicians can read and neither owns. A request can sit there unread for a week because each assumed the other had it. The second commonest is the chat channel, where a question scrolls off the top of the screen by lunchtime. The third is the technician's personal inbox, which becomes a channel the day the first requester learns that it is faster than the official route. Each of these is a door into the desk with no record on the other side. And a desk with one of them is losing requests at a rate it cannot measure, because the lost ones are the ones that were never written down.

What the tool adds is that every door ends in the same queue. A mail to the support address becomes a ticket with a number. A chat message becomes a ticket. The web form becomes a ticket, and the requester gets the number back whichever door they used. The design of that, which doors to open and which to close, is owned by One Queue, Many Doors. The mechanics of the mailbox in particular are owned by How a Mailbox Becomes a Queue. The trigger fires the first time a request is found in a channel a week after it arrived, with nobody's name on it. That has happened at every desk I have run. It happened at the last one on a Tuesday, in the mailbox, under a newsletter.

Triggers That Are Not

A vendor demonstration is not a trigger. The demonstration shows a desk that does not exist, with tickets that arrive clean and categorise themselves. And the feeling of wanting that desk is real and is not evidence about yours. A new manager who had a tool at their last organisation is not a trigger, though their experience is worth hearing once the trigger has fired. A bad week is not a trigger; a bad quarter might be, if it was bad in the ways above. "Everyone has one" is not a trigger, and the desks that have one and should not are the subject of the war story below. A feature is not a trigger: no desk ever needed a tool because the tool could do something, only because the desk could not.

The test for a real trigger is that it names hours. "We lost three requests in the mailbox last month and the oldest took nine days to find" is a trigger. "We spent two afternoons last quarter tallying the spreadsheet for the board" is a trigger. "It would be good to have a proper system" is a wish. The honest reply to it is the one Dana gave: not yet, and here is what will change my mind. Write the three triggers on a card, put it in the drawer, and look at it when the next demonstration arrives. (The demonstration will be very good. That is what they are for.)

The Tool That Will Not Fix a Process

A ticket system does not triage. Suppose a desk buys one to stop losing tickets, when the tickets were lost because nobody read the new ones at a fixed time. That desk will lose them faster and with better records. A tool amplifies the way of working it is given. Give it a triage rhythm, a named owner for every ticket and a priority rule, and it makes those three habits cheap and visible. Give it none of those and it becomes a very well-organised list of things nobody is doing, with a dashboard. The owner's instinct that "a proper system" will bring order is understandable and backwards. The order comes first, and the system is how the order survives the third technician.

The signs that the problem is process rather than tool are specific. Tickets are old and unassigned, which no tool fixes, because assignment is a decision a person makes at a fixed time. Two technicians give different answers to "which first?", which no tool fixes, because the priority rule is a sentence someone has to write. The requester is never told the ticket was closed, which the tool can prompt for and cannot force. Each of these is a one-page habit, and the ladder of them, in order, is in When to Add Process, and How Much. Where a desk has both problems, no habits and a spreadsheet, add the habits first and the tool a month later. The habits take a week to learn and the tool takes a quarter to regret. The cost of getting the order wrong has its own article in The Cost of a Bad Tool or a Bad Process. And the figures in it are mostly hours spent configuring software to compensate for a conversation nobody had.

Choosing Without Overbuying

When a trigger has fired, the choice is between kinds of tool, and the first mistake is to choose by looking at tools. Write down what the desk needs before any demonstration, from the triggers themselves. That means ownership and history if the trigger was the second person, reports if it was the question, channels into one queue if it was the mailbox. That list, and how to turn it into a fair trial, is owned by Requirements Before Demos and its series. The series compares the kinds, a cloud help desk, a self-hosted help desk, an open-source ticketing tool, an ITSM suite, fairly and without names. In the interest of the same fairness: the publisher of this library sells one of the self-hosted kind, QuerySolv, licensed once per installation rather than per person. That sentence is a disclosure rather than a recommendation. The triggers in this article do not care which kind you choose.

The second mistake is to buy for the desk you might have in five years. A desk of two that chooses a suite built for a desk of forty will spend its first quarter configuring workflows it does not need. It will spend its second quarter turning them off. The size test is blunt: the tool should be running, with the three habits in it, within a fortnight of the decision. And a technician who has never seen it should be working the queue by the end of their first day. A tool that needs a project plan is a tool for a desk that has a project manager. The hosting and licensing question, which is where most of the long-term cost hides, is in Hosting and Licensing Models. The only advice this article adds is to read the cost out five years, not one. The desk will be bigger and the pricing model will know it.

The third mistake is to skip the trial, or to run one that only the person who wanted the tool takes part in. A fair trial runs the real queue, or a copy of a month of it. It runs for long enough that the mailbox trigger and the reporting trigger both get tested. The technician who was least keen does most of the testing. That person's objections are the requirements the list missed.

The Migration Is Part of the Decision

Moving from a spreadsheet to a first ticket system is the easy migration, and it is still a migration. The open rows become tickets, by hand if there are fifty and by import if there are five hundred. The closed rows are either imported as history or archived as a read-only file with the date, and the second is usually right. The requesters are told that their request now has a number and where to find it. The old mailbox is pointed at the new queue. All of that is a week's work for a desk of two. And it is the cheapest migration the desk will ever do, because there is no old system to argue with.

Moving from one ticket system to another is a different animal. The decision to add a second tool to replace a first should carry the migration's cost in the sum. That is the point of Migration Cost Is Part of the Decision. The history has to be kept or deliberately left; the categories, statuses and fields have to be remapped; the technicians have to be retrained. And the ways migrations fail, which are mostly about the history and the cutover weekend, are in Why Migrations Go Wrong. A desk that replaces its tool every three years spends a quarter in every three on the move. Choose the first one as if it will last, and it will last longer than the demonstration suggested.

The Other Tools and Their Triggers

The ticket system is the first tool and the only one most desks need at the second-person threshold. The others each have a trigger of their own, and the trigger is never "the ticket system vendor also sells one". Remote control is triggered by the second site or the remote half, when the walk to the desk is a drive or impossible. It comes with a consent and logging discipline that is not optional, set out in Remote Support Tooling. A knowledge base is triggered by the third time the same answer is typed into a ticket; most help desk tools include one. And the question of what goes in it and who keeps it true is owned by What a Knowledge Base Is For. Monitoring that opens tickets is triggered by the first outage the desk learned about from a requester rather than from the system. Automation, routing rules and timers, is triggered by a rule a human applies the same way fifty times a month, and never before the rule exists.

The last column is the one to read twice. Every tool in the table carries a habit. And the habit has to exist before the tool, in a form plain enough that the tool is just the habit done faster. A knowledge base with no owner is a folder. Monitoring with no answer rule is a noise. Automation with no written rule is a guess made at speed. Its limits, which are mostly the limits of the rule, are in What to Automate First, and What Never.

A Short War Story: The Suite at Northgate Retail

Northgate Retail's three-person desk supported about a hundred and eighty staff across head office and a dozen stores. It bought an ITSM suite because store managers' requests kept getting lost. The regional director had also seen the same suite at a larger retailer and liked the dashboards. The desk lead, Sam, spent most of nine months configuring workflows, approval chains and a service catalogue with forty entries, with a consultant's help for two of them. Requests kept getting lost, because the reason they were lost had never been that the spreadsheet was a spreadsheet. It was that nobody read the shared mailbox at a fixed time and nobody's name went on a request when it arrived. When a new technician joined in the tenth month and asked what the morning routine was, there was none. The suite's forty-entry catalogue had been used by four store managers. Northgate wrote off the suite's first year and moved to a simpler tool in a fortnight. It started reading the mailbox at nine and two with a name on every ticket. After that, the lost requests stopped within a month. A tool bought to fix a process is the same process, with a licence and a longer menu.

The Tool Trigger List

The list below is the card for the drawer: one page, five tools, each with its triggers, its false triggers and the habit that must already exist. Fill in the top half when a trigger seems to have fired, with the hours it names. Show that page to whoever has to agree before any demonstration is booked. A page with no hours on it is a wish, and should go back in the drawer. A page with hours on it is a decision. And the series article Planning a Year Ahead is where the decision gets a quarter and a budget line.

TOOL TRIGGER LIST — ONE PAGE
Desk: ______________________   Date: ____________   Prepared by: ______________
Tool being considered: ______________________

TRIGGERS (tick what has happened; write the hours or the count beside it)
  Ticket system
    [ ] a second person starts on ____________
    [ ] a reporting question could not be answered without ____ hours of tallying, ____ times
    [ ] a request was found in a channel nobody owns, ____ days after it arrived, ____ times
  Remote control
    [ ] a second site or home workers; visits in the last quarter: ____ at ____ hours each
  Knowledge base
    [ ] the same answer typed into tickets ____ times last month
  Monitoring to ticket
    [ ] an outage learned about from a requester on ____________
  Automation and routing
    [ ] a rule applied by hand ____ times last month, the same way each time

NOT TRIGGERS (tick if any of these is the real reason; if so, stop here)
  [ ] a demonstration      [ ] a new manager's previous tool     [ ] a bad week
  [ ] "everyone has one"   [ ] a feature we could use             [ ] the vendor also sells it

THE HABIT THAT MUST ALREADY EXIST (all ticked before the tool is added)
  [ ] triage at set times, written down         [ ] an owner by name on every item
  [ ] a one-page priority rule                  [ ] a consent and logging rule (remote)
  [ ] an owner and a date on every article (KB) [ ] the rule itself, written (automation)

THE DECISION
  Requirements written before any demonstration:  [ ]   (count: ____)
  Trial run on the real queue, by the least keen technician:  [ ]   dates: ____________
  Migration cost included in the sum:  [ ]   estimated ____ hours
  Cost read out five years, not one:  [ ]
  Decision: ______________   Taken on: ____________   By: ______________

Dana's card went in the drawer with none of the trigger boxes ticked. That was the honest state of a seventy-person company with one technician and a list that worked. Fourteen months later the managing director approved a second technician, and the card came out with the first box ticked before the advert was written. The tool was running a week before the new person started. Nobody at Acme has had the "I thought you had that one" conversation, which is the only measure of the decision that matters.

Frequently Asked Questions