Making the Decision and Writing It Down: The Decision Record

Tuesday, 11:20, at Acme. Sam has been IT manager for five weeks and has just opened a renewal notice for the ticketing system. The amount is larger than last year's, and the notice period ends in three weeks. The question Sam asks the desk is a reasonable one: "Why did we pick this one?" Nobody knows. Ruth chose it, two years ago, with a spreadsheet and a trial and, by all accounts, a great deal of care. Ruth left in the spring. The spreadsheet was on her laptop, which was wiped. The technicians remember that "the other one was worse" and that "there was a thing about e-mail". The only argument for renewing is that it is what they have. The only argument for leaving is the number on the notice. Sam has three weeks to choose between two arguments that are not about the tool at all. The decision was made well. It simply was not kept.

A decision record is a one-page document, written on the day a choice is made. It says what was chosen, why, and what was rejected and why. It also says who signed, when the decision will be looked at again, and how the organisation would leave if it had to. It is not a project plan and not a contract. It is the memory of the decision, kept for the people who were not in the room, including the future version of the people who were. This article is part of our Choosing a Ticketing System series. It covers the last step: turning the sheets, trials and worksheets from the earlier articles into a choice. It then turns the choice into one page that survives the person who made it.

It covers why the record exists and who reads it, and how to make the decision from the evidence without reopening the evaluation. Next come what was chosen and why, in plain sentences, and what was rejected and why, fairly. Then it covers who signs and how dissent is kept, and what will be revisited and when. Next come the exit plan, written on the day you buy, and where the record lives. It ends with the record's sections as a table, a short war story, and the decision record to copy, in that order.

Why Write It Down, and Who Reads It

A decision that is not written down will be made again, at full cost, by someone with less evidence. That is the whole argument. The Acme renewal is what it looks like in practice. There is a careful choice, two years of use, and then a new manager choosing between renewal and departure. They have nothing but a number and some folklore. The record is cheap. It takes an hour to write on the day the evidence is fresh. It is the only hour of the whole project that pays out for years.

The record has three readers, and it is written for all of them at once. The first is the person two years from now who asks "why this one?" They need the reasons and the rejected options in a form that takes five minutes to read. The second is the person who disagreed at the time, and who will, in good faith, raise the question again in a corridor in nine months. For them the record is the fairest possible answer. It shows that their objection was heard and says what the decision rested on instead. The third is the person who one day has to leave the tool, by choice or because the vendor has made the choice for them. They need to know where the data is, how to get it out, and what that was estimated to cost. Three readers, one page. It is the best-value page a desk lead ever writes.

The record is also what makes the earlier work worth having done. A requirements worksheet, two scoring sheets, two trial plans, a total-cost worksheet and two migration sheets are a thick folder. A thick folder is not read. The record is the one page that sits on top of the folder and says what the folder concluded. The folder is attached for anyone who wants to check. Without the record, the folder is evidence for a case nobody remembers bringing.

Making the Decision From the Evidence

The decision is made by one named person, reading the evidence in a fixed order, in one sitting. The people who did the work are in the room, and the people who will sign are told what the order is. The order matters because each document answers a different question and the later ones depend on the earlier. Read the requirements worksheet first, to remind everyone what the desk said it needed before any demo. Check that nothing on the must list has been quietly forgotten. Then the scoring sheets, which rank the candidates on paper. Then the trial plans from designing a fair trial, which say what happened when the paper met the tickets. Then the total-cost worksheet with the migration sheets inside it, which say what each candidate costs over years in money and hours. By the end of the fourth document the decision has usually made itself, and the sitting is about saying it aloud.

Judgement enters where the evidence is close, and the honest response to a close call is to write down that it was close. Consider two candidates within a few points on the sheet, both passing the trial, a hundred hours apart on migration. That is a decision, but it is a decision by a margin. The record should say "by a margin, on migration cost" rather than dress it as a landslide. A record that overstates the margin will be disbelieved by the person who was in the room and knew better. A record that states it will be trusted, including the next time that person is asked whether the process was fair.

Resist the two ways a decision sitting goes wrong. The first is reopening the evaluation: someone proposes a new criterion, a new candidate, or one more week of trial. The sitting becomes a planning meeting for a decision that will now happen later. New information that genuinely changes the picture is rare at this stage. The test is whether it would have changed a must. If not, note it in the record as a thing to watch and decide anyway. The second is deciding by the loudest preference. That happens when the documents are not read in order and the conversation starts with "well, I liked". Reading the evidence first is not bureaucracy. It is how a group of tired people stops the decision from being made by whoever is least tired.

Involve the people who will have to live with the result, which means the whole desk is consulted and one person decides. Consultation is real: each technician's written verdict from the trial is read aloud, and anyone who thinks the evidence has been misread says so now. Deciding is also real: one person, usually the desk lead, says which candidate it is and why. The budget holder and data owner sign that they accept it. A committee that decides will decide to decide later. A person who decides, having consulted, can be wrong, and that is what the review date is for.

What Was Chosen, and Why, in Plain Sentences

The first block of the record names the choice and gives the reasons. The reasons are at most three sentences, each of which points at evidence. "Chosen because it passed all five trial scenarios, including the reopen scenario the other candidate failed; because its five-year cost in money and hours was the lower of the two by roughly a quarter on the worksheet; and because the data stays on our own server, which the tenancy contract requires." Three reasons, three documents, no adjectives. A reader can check every clause against the folder. A reader who disagrees can say which clause they disagree with rather than disagreeing with the mood.

Write the reasons as behaviours and costs, never as a feature list. "Has a good knowledge base" is a sentence from a brochure. "Technicians can write an article from a ticket and mark it visible to agents only or to everyone, which the runbook project needs" is a reason. The difference is that the second one can turn out to be wrong in a way the record will catch at review. The first one cannot be wrong because it does not say anything. Keep the praise for the pub. The record is for the reasons.

Add one more sentence, and it is the hardest one to write: the fact that would have changed the decision. "Had the other candidate reopened tickets in place from an e-mailed reply, it would have been chosen on cost." This sentence does three things. It tells the future reader how close the call was. It tells the vendor of the rejected candidate, if you choose to tell them, exactly what lost them the desk. That is the most useful feedback a vendor ever gets. And this sentence tells the person who disagreed that their preferred option lost on a specific, checkable point rather than on taste. A decision record without this sentence is a verdict. With it, it is a reason.

What Was Rejected, and Why, Fairly

Every candidate that was seriously considered gets one line: its name, the stage at which it left, and the deciding fact. "Rejected at requirements: could not give the fleet mailbox its own queue, which was must M1." "Rejected after trial: failed the e-mail loop scenario on day two; vendor confirmed the behaviour is by design." "Rejected on cost: passed the trial, scored within four points, five-year total higher by roughly a third on the worksheet, mostly in per-agent charges at year-three headcount." The incumbent gets a line too, because staying was an option: "Staying rejected: current workaround cost of roughly six hours a week exceeds the cheapest migration within a year."

Be fair to the rejected tools, which means writing "rejected for us" and not "bad". A tool that failed your must is a tool that does something else well for someone else. The record is not the place to settle scores with a presenter who annoyed you. Fairness here is not politeness; it is accuracy, and accuracy is what the record is for. In two years your desk may be different, and the rejected tool may be different. The person reading the record needs to know what was true then, not what was felt. "Failed the e-mail loop scenario" is true. "Hopeless with e-mail" is a review, and reviews age badly.

The rejected lines are also the record's defence against the corridor. Nine months from now someone will say "we should have gone with the other one". The desk lead who has the record can say "it failed the loop scenario, here is the day it happened and what the vendor said". The conversation ends, kindly. Without the record the conversation does not end. It recurs, every quarter, with slightly less detail each time, until the folklore has replaced the facts and the renewal notice arrives at Acme. Write the rejected lines on the day. They are the ones nobody will be able to reconstruct later.

Who Signed, and How Dissent Is Kept

Three signatures belong on the record, and each means something different. The decider, usually the desk lead, signs that this is the choice and these are the reasons. The budget holder signs that the five-year cost in the worksheet is understood and accepted, hours included. The data owner, whoever is accountable for where personal information lives, signs that the hosting model and the contract's data clauses have been read and are acceptable. A signature is not ceremony. It is the answer to "who agreed to this?" when the question is asked in anger. The person who signed is protected by it as much as anyone. The record shows what they were shown.

Record who was consulted in a line, by role. Include the technicians who worked the trial, the requesters who raised tickets in it, and the manager who read the one-page report. This is not a list of people who agreed. It is a list of people who were asked, and it is what makes the record honest when someone later says "nobody asked us". They may have been asked and disagreed, which is the next line.

Dissent is kept, in one sentence, in the dissenter's words, with their name if they are willing. "Priya preferred candidate B for its reporting and does not think the migration estimate for it was fair." This is the sentence most records omit and most records should contain. A decision record that shows only agreement reads as a record that was written by the winners. The dissent does not change the decision. It records that the decision was made with the objection in view. It gives the review in a year a specific thing to check: was the migration estimate fair? If Priya was right, the review will say so, and the next decision will be better for it. A record that cannot hold a disagreement is a press release.

What Will Be Revisited, and When

Every decision record carries a review date and a list of triggers. The choice was made for the desk as it was and the desk will change. The review date is a calendar entry a year out, owned by the desk lead. At that review, the record is read against the requirements worksheet and the question is asked: is the tool still doing what we chose it to do? Not "is there something newer", which there always is, but "does the fleet mailbox still land in the fleet queue, do replies still reopen, can the manager still get the one page". The review takes an hour and produces a dated note at the bottom of the record. It is the cheapest insurance a desk buys against drifting into a tool that stopped fitting three years ago.

The triggers are the events that bring the review forward. They are worth listing because each one is a change to a thing the decision rested on. Headcount passing a threshold, if the licensing model charges by head. A change to the licensing model or the hosting terms announced by the vendor. An end-of-life notice for the version you run, or for the product. A scenario from the trial failing in production, which means the trial was wrong about something and the record should say which. A change to the rules about where data may live. Any of these reopens the record, not the evaluation. The question is whether the reasons still hold. Only if they do not does the funnel start again.

A decision record is close kin to the one-page change record used for infrastructure changes, described in the one-page change record. The kinship is useful: both say what was done, why, by whom, and how it would be undone. If your desk already keeps change records, keep the decision record in the same place and in the same spirit. A choice of ticketing system is the largest change a desk makes to itself, and it deserves at least the paperwork of a firewall rule.

The Exit Plan, Written on the Day You Buy

The exit plan is the part of the record that says how the organisation would leave the tool if it had to. It is written on the day of buying for one reason: that is the only day on which nobody is upset. On the day you leave, the vendor has done something, or the budget has, or a merger has. Then the exit is planned in a hurry by people who are cross. On the day you buy, the vendor is helpful, the contract is in front of you, and the clause about export is a question you can ask in a pleasant voice. Write it now. It is four lines.

The four lines are: where the data is, how it is exported, how often that export is tested, and what leaving was estimated to cost. Where the data is depends on the hosting model. For a self-hosted tool it is a database and a folder of attachments on your own server. So the exit export is part of the backup you already take. QuerySolv, for instance, runs on your own Windows server, and the same is true of any self-hosted tool. For a cloud tool it is wherever the contract says, and the export is a facility the vendor provides, on their terms. The record should quote those terms by clause number. How often it is tested is a date. Once a year, at the review, somebody takes the full export and opens it. An export that has never been opened is an exit that has never been tried. What leaving would cost is the migration estimate, which migration cost is part of the decision showed you how to make. The estimate is written down now so that the person who has to leave in a hurry starts with a number rather than a guess.

Add the notice period and the data retention period from the contract, because they are the two dates that bite. The notice period is how long before renewal you must say you are leaving. The retention period is how long after you stop paying the data remains available to export. Both are easily found on the day you buy and infuriatingly hard to find on the day you need them. An exit plan written on the day you buy is a sentence. Written on the day you leave, it is a project with a deadline you did not choose.

Where the Record Lives, and Who Is Told

The record lives where the next desk lead will look, which is the knowledge base. The record is an article visible to technicians and not to requesters, with the folder of sheets and plans attached or linked. It does not live on the decider's laptop, in the decider's mailbox, or in a shared drive folder called "Project" that will be archived with the project. Give it a name on it and a review date, in the manner described in every article has a name on it. That way, it is somebody's article and not an orphan. The record that saved Sam at Acme would have been an article called "Ticketing system decision", two years old, with Ruth's name on it and a review note from the year between.

Tell the people who were consulted what was decided and why, in the record's own words, before they hear it from the project plan. The technicians get the record. The manager who read the one-page report gets the three reasons and the review date. The budget holder gets the worksheet they signed. If the decision needs explaining upward, which it usually does, the shape of that one page is in explaining technical things to management. The decision record is most of the material. Tell the rejected vendors too, briefly and factually, with the deciding fact. It costs an e-mail and is the right thing to do. One of them may fix the thing by the time your review comes round.

The table below is the record's sections, what each one holds, and what goes wrong when it is missing. Use it as a checklist while writing, and as a test when reading someone else's. A record with the first two sections and nothing else is the commonest kind. It is the kind that leaves Sam with a renewal notice and folklore.

A Short War Story: The Decision Made Twice at Fernhill Academy

Fernhill Academy, a trust of four schools with a three-person desk, chose a ticketing system after a thorough evaluation led by Ruth, the IT lead. She ran a trial, scored two candidates with a second technician and chose on the strength of a failed reopen scenario. She wrote none of it down because the result had seemed obvious to everyone in the room. Eighteen months later Ruth left. The renewal notice arrived on the desk of a new business manager called Daniel. He found no record of why the tool had been chosen or what it would cost to leave. He did the responsible thing and reopened the evaluation. The desk spent three months on demos, a fresh scoring sheet and a two-week trial. That was roughly a hundred and twenty hours of technician time plus Daniel's. They chose the same tool for the same reason, which the second trial rediscovered on day eight. In the meantime the renewal had lapsed. The tool ran for six weeks on a goodwill extension while procurement caught up. The one lesson Daniel insisted on was a page in the knowledge base with his name on it. It had Ruth's reasons reconstructed as best anyone could, and a review date. A decision that is not written down is not saved; it is merely postponed until someone has to make it again with less.

The Decision Record

The record below is one page, written on the day of the decision by the decider, signed by three people, and filed in the knowledge base with the folder attached. Every line that asks for a reason expects a pointer to a document in the folder, not an adjective. The review block at the bottom is filled in a year later, and each year after, by whoever owns the record then. If the page is still one page after three reviews, the decision was a good one or the reviews were not honest. In that case, the dated notes will tell you which.

TICKETING SYSTEM DECISION RECORD — ONE PAGE
Desk: ______________________   Decided by: ______________   Date: ____________
Folder attached (requirements, scoring sheets, trial plans, cost worksheet, migration sheets): [ ]

WHAT WAS CHOSEN
  Candidate: ______________________   Hosting model: ______________   Licensing model: ______________

WHY (up to three reasons, each pointing at a document)
  1. ______________________________________________  (evidence: ______________)
  2. ______________________________________________  (evidence: ______________)
  3. ______________________________________________  (evidence: ______________)
  Margin: [ ] clear  [ ] by a margin, on ______________
  The fact that would have changed it: ________________________________________

WHAT WAS REJECTED (one line each, including staying put)
  ______________  left at [ ] requirements [ ] scoring [ ] trial [ ] cost  because ______________
  ______________  left at [ ] requirements [ ] scoring [ ] trial [ ] cost  because ______________
  Staying with the current system rejected because ______________________________

WHO SIGNED
  Decider: ______________ (role) ____   Budget holder: ______________   Data owner: ______________
  Consulted (roles): _______________________________________________
  Dissent, in the dissenter's words: __________________________________________

WHAT WILL BE REVISITED, AND WHEN
  Review date: ____________   Owner: ______________
  Triggers that bring it forward:  [ ] headcount passes ____   [ ] licensing or hosting terms change
    [ ] end-of-life notice   [ ] a trial scenario fails in production   [ ] data-location rules change
    [ ] ______________________________

THE EXIT PLAN (written today)
  Where the data is: ______________________________________________
  How it is exported: ______________________________  Contract clause: ______
  Export tested on: ____________ (then yearly at the review)
  Estimated cost of leaving (from the migration sheet): ____ to ____ hours
  Notice period: ____ weeks before ____________   Data retained after we stop paying: ____

WHERE THIS RECORD LIVES
  Knowledge base article: ______________________  Visible to: technicians only  Named owner: ______________

REVIEW NOTES (one dated line per review)
  ____________  Still fits: [ ] yes  [ ] no, because ______________________  Signed: ______________
  ____________  Still fits: [ ] yes  [ ] no, because ______________________  Signed: ______________

Sam, at Acme, did not have the record and had three weeks. The desk reconstructed what it could. The two technicians who had worked Ruth's trial remembered the reopen scenario and that "the other one made a new ticket every time". That was enough to know the choice had been made for a reason. The vendor's own trial notes, when asked, confirmed the dates. Sam renewed, with a note in the knowledge base that said so and why, and a review date a year out. It is not the record Ruth would have written. It is the record Ruth should have. The next manager will find it in the knowledge base with Sam's name on it, which is a kind of ending.

Frequently Asked Questions