Making Business Impact Visible

Farah has been on the desk at Larkin Timber for three weeks when ticket 9114 arrives at 13:40 on a Thursday: "The label app on the goods-out tablet keeps closing. Can someone look?" One tablet, one person, polite tone, no deadline mentioned. She applies the grid properly, as she was taught in her first week: impact low, one person; urgency medium, there is presumably some other way to print a label. Medium. She replies with a time, tomorrow morning, and moves on to a High. Farah does not know that the goods-out tablet is the only thing in the building that produces a delivery note. She does not know that Thursday is the heaviest despatch day of the week. She also does not know that the haulier collects at 15:30 and does not wait. Nobody has written these facts anywhere she can see.

Business impact is what it costs the organisation when a thing stops working, measured in people who cannot do their jobs and processes that cannot run. It is the first half of every priority decision, and it is invisible to the desk by default. The desk sees devices, usernames and ticket subjects. The business sees despatch, payroll, patient records and month-end. Nothing in ticket 9114 said "despatch". The grid worked exactly as designed. It was handed the wrong facts, and it had no way of knowing. This article is part of our Prioritization Frameworks series. It is about writing the facts down in advance. Then a technician in her third week sees what the technician in her tenth year would have seen.

It starts with why impact is invisible to the desk until someone makes it visible. Then comes the critical business process list and how to build it from ten short conversations. Next is mapping each process onto the services and devices it runs on, which is where the hidden single points sit. After that come the how-many-are-blocked count and how to get it in one question. Then comes the calendar of peaks, when the same fault costs more. Next is the VIP problem and how to handle it honestly without a second, secret set of promises. The article then covers putting the register to work on the ticket at triage and keeping it alive. It ends with the impact register itself, laid out to be filled in. How the two halves of the decision combine is covered in Impact Times Urgency in Practice. This article is about supplying the impact half with something better than a guess.

Impact Is Invisible by Default

The desk sees the organisation through its tickets, and tickets describe symptoms in the requester's vocabulary. "The tablet app keeps closing." "I cannot get into the shared folder." "The printer by the window is flashing." None of those sentences contains the word that would tell a stranger what the organisation loses while the symptom persists. The requester did not leave it out to be unhelpful; they left it out because, to them, it is too well known to say. Everyone in goods-out knows what the tablet is for. Nobody on the desk does, until somebody tells them.

Experienced technicians carry the missing facts in their heads, which is why the desk seems to work until the experienced technician is on holiday. Dev, who has been at Larkin for nine years, would have read "goods-out tablet" and "Thursday" and set the ticket to Urgent before finishing the sentence. That knowledge is real and valuable, and it is in exactly one place, which is a problem. A desk whose impact assessment depends on who is on shift has not got an impact assessment. It has got Dev.

Making impact visible means moving those facts from Dev's head into a short written list that any technician can read in the time it takes to triage a ticket. The list answers three questions about each important thing the organisation does: what does it run on, how many people stop when it stops, and when does it matter most. With those three answers beside the queue, Farah's ticket 9114 becomes "goods-out tablet, delivery notes, every outbound load, Thursday peak, haulier at 15:30". The grid gets the facts it needed. The list is called an impact register here, and it is shorter than it sounds. (Everything in this article is shorter than it sounds, which is the only reason any of it gets done.)

The Critical Business Process List

Start with processes, not systems, because processes are what the business will shout about. A critical business process is something the organisation does that meets two tests. If it stopped for a working day, it would cost money, break a legal obligation or harm a customer. And someone senior would phone the desk about it by name. Despatching orders. Running payroll. Taking payments at the till. Sending lab results to the doctors. Answering the repairs line. Admitting a patient. Each is an activity with a start and an end and people who perform it. Each runs on a handful of systems that the desk supports without necessarily knowing what they are for.

Build the list by asking each department head one question, in person, for ten minutes: "What do you do here that, if it stopped for a day, you would come and find me about?" Write down the verbs they use. Then ask the second question: "And what does that run on?" Write down the nouns. Ten conversations, ten minutes each, and the first draft of the list exists by the end of a week. Department heads enjoy this conversation, because nobody from IT has ever asked them what their department is for. The answers are more interesting than the desk expects.

Cap the list at ten to fifteen processes, and defend the cap. Every department will nominate everything it does, on the reasonable grounds that it all matters to them. The test is the phone call: would someone senior ring the desk about this within an hour, by name, if it stopped? Monthly reporting matters, and nobody rings about it within an hour. The till matters, and the store manager rings within four minutes. A list of forty critical processes is a list on which nothing is critical. The technician who has to read it at triage will stop reading it by Tuesday.

Name each process in the department's own words and add a one-line description that a new technician could understand. "Despatch: picking, labelling and loading customer orders onto hauliers; every outbound delivery depends on it." Not "WMS outbound workflow", which is a system name wearing a process costume. The description is what tells Farah why the tablet matters, and it is the sentence Dev would have said if he had been there. A process on the list without a plain description is a word, and words are not what the triager needs.

From Process to Service: What Each One Runs On

Each process on the list runs on a short chain of things the desk supports, and the chain is where the surprises live. Despatch at Larkin Timber runs on the warehouse system, the goods-out tablet with the label app, and the label printer on the loading bay. It also runs on the wireless in the yard and a shared mailbox the hauliers send collection times to. Five things, and a fault in any one of them stops despatch. The tablet is not a tablet. It is a fifth of a critical process, and the register is where that fact gets written so that it is no longer a surprise.

Walk each process with the department head and write down every system, device, account and connection it needs, in the order the process uses them. Then ask the question that finds the single points: "Is there only one of any of these?" One label printer, one tablet, one person who knows the password, one interface that runs on a machine under someone's desk. These are the entries that turn a Low ticket into a High one. They are almost never visible from the ticket, because the requester does not know they are single points either. They just know that the tablet is broken and that Thursday is Thursday.

The chain is not an asset inventory and should not try to be one. A full list of every device in the building is a different document, useful for other purposes. A desk that tries to build it inside the impact register will never finish either. The register lists only what a critical process depends on, which for most processes is three to six things. If a process seems to depend on twenty, it is either several processes or the department head is listing everything they can see from their chair. A second ten-minute conversation sorts it out. The broader question of what the desk supports at all belongs to The Service Catalog Idea; the register is the short list of what must not stop.

The How-Many-Are-Blocked Count

Impact is a count of people before it is anything else, and the count should be a number written in the ticket, not an adjective. "Lots of people" is not a count. "The warehouse" is not a count. "Six pickers and the two on the bay, so eight, and the office cannot raise delivery notes, so eleven" is a count, and it took one question to get. The question is "who cannot work right now because of this, and who is working slower?" The register answers it for any process on the list. It carries the headcount of each process beside its name.

Get the count in one message when the ticket does not supply it. Ask for a number and a name: "How many people are affected, and is anyone completely stopped?" The requester usually knows and will say. If they do not, the department's headcount is on the register. The count of people performing the process on a Thursday afternoon is a fair estimate until a better one arrives. Write the number into the ticket beside the priority, with the word "blocked" or "slowed" next to it. Then the next technician does not have to ask again. The monthly review can also see what the desk thought it was dealing with.

Count the people behind the process, not just the people standing at the broken device. One tablet has one user. But the delivery notes it prints are waited for by the loaders, the driver, the customer and the invoicing clerk. The clerk cannot raise an invoice until the note exists. That chain is why the register lists "people affected" per process rather than per device: the number belongs to the process, and the device inherits it. A technician who counts the one person at the tablet has counted correctly and answered the wrong question.

Distinguish stopped from slowed, because the two produce different urgency. Eight people stopped is high urgency; eight people slowed by a workaround that holds until the end of the day is medium. The count gives impact. The stopped-or-slowed word gives most of urgency. Between them they place the ticket on the grid with no further argument. Write them as a line in the ticket: "Despatch; 11 affected, 8 stopped; Thursday peak, haulier 15:30". They are also the shortest honest explanation the desk can give anyone of why the ticket is where it is.

The Calendar: When the Same Fault Costs More

The same fault has a different impact on different days, and the days are predictable. A payroll system that falters on the twelfth is an inconvenience. The same fault on the day the payroll run must be submitted is a room full of people not being paid on Friday. A despatch fault at 09:00 on a Monday has the whole day to recover; at 14:30 on a Thursday it has an hour before the haulier arrives. The grid's urgency axis asks "is there a deadline today?" The calendar is the list of deadlines the requester may not think to mention. To them, everyone knows it is payroll day.

Each process on the register gets a line for its peaks: the days, dates or hours when a fault in it costs most. Despatch: Thursdays, and daily from 14:00 to 15:30 before the haulier. Payroll: the two working days before the monthly submission date. Tills: Saturdays, and the week before any public holiday. Lab results: weekday mornings when the clinics run. Month-end close: the last three working days of each month and the first two of the next. Term start, stocktake week, the audit, the board meeting, the annual renewal. Ask the department head "when would this be worst?" and they will tell you instantly, because they have lived it.

The peak line changes the urgency the triager assigns, and it should be read every time a register process is touched. A fault in payroll on the twelfth is impact high (the process is on the list) and urgency low (nothing is due today). The grid makes that High: worked today, not in a panic. The same fault two days before submission is impact high and urgency high, which is Emergency. The register is what tells a third-week technician which of those two days it is. Without the calendar, the technician has to know the organisation's rhythm by heart, and that takes a year to learn and one holiday to forget.

The calendar also lets the desk plan rather than react. If despatch peaks on Thursday afternoons, Thursday afternoon is not the time to update the label printer's firmware. The technician who knows that is a technician who has read the register. The planning side of peaks, deciding when changes may and may not happen, is a change-management question and lives in another series. The triage side is simpler: read the peak line, ask whether today is one of those days, and let the answer move the urgency where it belongs.

The VIP Problem, Without a Shadow SLA

Every desk is eventually asked, quietly, to treat certain people's tickets as more important than the grid says. The quiet version of saying yes is a shadow SLA. A shadow SLA is an unwritten promise, usually to senior people, that their tickets will be worked faster than the stated targets, kept by habit and never admitted. It is bad for three reasons. It cannot be defended, because it is not written anywhere. It cannot be measured, so nobody knows what it costs the other requesters. And it teaches the desk that the grid has a secret exception, after which the grid has several, because secrets breed.

The honest version of the VIP question is "what does this person do that the organisation cannot do without?" The answer is usually a process that belongs on the register. The finance director's laptop is not a critical process. The finance director submitting the regulator's return by Friday is, and it goes on the list with its peak dates. Then any ticket that blocks it gets the impact it deserves. That applies whether it comes from the director or from the junior analyst who actually does the submission. Put the process on the register, not the person. The grid will then be impressed by exactly the right thing, which is what the person is trying to get done.

Some of what a senior requester wants is not priority at all but attention, and attention can be offered openly without touching the grid. A named contact who acknowledges their ticket personally. A phone call rather than a reply. An update before they ask. The executive's assistant copied in. None of that changes which cell the ticket lands in or which clock runs. All of it can be written into the policy as a courtesy that the desk extends to a short, named list of roles. A courtesy that is written down is a service. A priority that is not written down is a shadow, and the difference is whether the desk is willing to say it out loud.

When a senior person wants the priority itself raised, that is an override. It goes through the route described in Who Decides the Priority: recorded, named, with the reason, and counted at the month's end. Offer senior people the choice between "I will put your process on the register so it is always rated correctly" and "I will quietly bump your tickets". Most choose the first once it is explained. The first is a system and the second is a favour, and favours run out. The ones who insist on the second are asking the desk to keep a secret. The desk should decline, politely, and offer the register instead.

Putting It on the Ticket

The register earns its keep only at triage, in the thirty seconds between reading a ticket and setting its priority. So it has to be where the triager can see it without hunting. Pin it beside the grid. Put it in the knowledge base as an article that only agents can see, if the tool has one. Or use a shared document with a link on the triage checklist. That checklist is laid out in A Triage Checklist You Can Laminate. The triager's habit is one glance: does anything in this ticket touch a process on the list? If no, the grid proceeds on the ticket's own facts. If yes, the register supplies the headcount and the peak, and the ticket gets its one-line impact note.

The line on the ticket is the register's output, and it has a fixed shape so it can be found later. "Process: despatch. Affected: 11, 8 stopped. Peak: yes, Thursday, haulier 15:30. Priority: Urgent." Four fragments, under twenty words, written as an internal note or in a custom field if the form has one. Most tools let a form carry a short text field, and a field called "impact note" is a fine use of one. The line does for impact what the grid note does for the priority as a whole. It tells the next technician what this one knew. It also lets the review check the decision against the register rather than against memory.

Here is the register applied to five tickets from one Thursday at Larkin Timber, each rated first on its own words and then with the register beside it. Three of the five moved. The two that did not are as important as the three that did. The register's job is not to raise priorities but to make them accurate. Accuracy sometimes means a ticket stays exactly where the grid first put it.

Ticket 9133 is the one to notice, because it moved up without any urgency at all. One person, nothing due today, and the grid still says High. The process is on the list, and a fault in it is a risk to everyone's pay packet even on a quiet day. That is the register doing the thing a headcount alone cannot, which is remembering that some single people are standing at the front of a very long line.

Keeping the Register Alive

A register that is right on the day it is written is wrong within a quarter. Processes move, systems are replaced, and the second label printer gets borrowed by goods-in and never returned. Review it every three months in the same ten-minute conversations that built it. Also review it whenever any of four things happens. A department reorganises, a system is replaced or added, or a ticket surprises the desk with its impact. Or a new technician reads it and asks a question nobody can answer. The surprise is the most useful trigger. Every "I did not know that mattered" is a missing line, and the line should be added the same day, while the surprise is fresh.

Give each process one owner outside IT, usually the department head who described it, and ask them to confirm their lines at each review. This is not bureaucracy. It is the department saying "yes, this is still what we do and what it runs on". That takes them two minutes and makes the register theirs rather than the desk's guess about them. A register that department heads have signed is also a register a senior requester cannot easily argue with, because the headcount and the peak dates came from their own colleagues.

Test it with the newest technician. Hand them the register and a dozen old tickets, and ask them to rate the tickets using it. Where their answers match the desk's, the register is working. Where they do not, either the register is missing a line or the ticket's subject was uninformative, and both are worth knowing. A register that only an experienced technician can apply has not solved the problem it was built for. It has written Dev's knowledge down in a way that still needs Dev to read it.

Keep it to one page, and if it grows past one, cut. The urge to add every process, every dependency and every peak is the same urge that produces the forty-item critical list. It ends the same way, with a document nobody reads at 13:40 on a Thursday. The register's whole value is that it can be read in the time it takes to triage one ticket. The moment it cannot, it has become reference material, and reference material is what the desk already had too much of.

A Short War Story: Dock Three at Bellweather Logistics

Bellweather Logistics, a parcel carrier with a depot of two hundred staff and a desk of three, had no impact register. Its impact assessment lived in the head of a senior technician called Marcus, who left in the spring. On a Friday in his second month, Ellis, the replacement, received a ticket at 13:05 from a loader. It said "the scanner at dock three says no connection". He rated it Medium on the grounds that the depot had eleven docks and this was one of them. He promised to look within the hour, which he did, at 14:20. Dock three, as Marcus could have told him and nobody else thought to, was the outbound dock for the 16:00 trunk departure. Every parcel loaded there had to be scanned onto a manifest before the trunk could legally leave. By the time Ellis understood what he was looking at, three trunks had left half-loaded to make their slots. About sixty deliveries went a day late, and the operations manager spent Monday morning writing to customers. The desk wrote its first impact register that week. It used "Dock 3: outbound trunk manifest; every parcel on the 16:00; peak 14:00 to 16:00 daily" as the first line. Ellis's lesson, which he passed on in turn, was that the register is not for the technician who knows. It is for the one who arrives after.

The Impact Register

The block below is the register as a page to fill in. One line per critical process, with the service chain, the headcount, the peak times, the owner and the workaround if there is one. Fill it from the ten-minute conversations, cap it at fifteen lines, pin it beside the grid, and bring it to every quarterly review. The example line shows the shape; delete it when you have your own.

IMPACT REGISTER — ONE PAGE
Organisation: ______________   Owner on the desk: ____________   Reviewed: __________

HOW TO USE AT TRIAGE
  1. Does the ticket touch anything in the SERVICE CHAIN column?  If no, rate on
     the ticket's own facts.
  2. If yes: impact is HIGH. Take the headcount from PEOPLE AFFECTED.
  3. Read PEAK TIMES. If today or now is a peak, urgency is at least MEDIUM; if
     work has stopped, HIGH.
  4. Write one line in the ticket:
     Process: ______  Affected: ____ (____ stopped)  Peak: yes/no ______  Priority: ______

PROCESS            SERVICE CHAIN (what it runs on)        PEOPLE     PEAK TIMES            OWNER        WORKAROUND
                                                           AFFECTED
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________
__________________ _____________________________________ _________ _____________________ ____________ ______________________

EXAMPLE LINE (replace with your own lines)
Despatch           Warehouse system; goods-out tablet     11        Thu all day;          Head of      Hand-written note,
                   and label app; bay label printer;                14:00-15:30 daily     despatch     holds about 1 hour
                   yard wireless; "hauliers" mailbox                before haulier

SINGLE POINTS (only one of these exists; a fault here stops the process)
  __________________________   __________________________   __________________________

COURTESIES (written, not secret): roles that get a named contact and a call
  Role: ______________  Courtesy: ______________________  Priority unchanged: [ ] yes

REVIEW TRIGGERS
  [ ] Quarterly, with each owner        [ ] A system replaced or added
  [ ] A department reorganised          [ ] A ticket surprised the desk
  [ ] A new technician could not apply a line

The courtesies section is there on purpose, and it is the honest answer to the VIP problem. It is a short, written list of roles who get a named contact and a phone call. A box beside each confirms that their priority is set by the grid like everyone else's. Writing it down turns a favour into a service. Leaving it off the page does not stop it happening; it only stops anyone being able to see it.

Replay Farah's Thursday with the register pinned beside the grid. She reads "goods-out tablet", glances at the register, and sees "despatch, 11 people, Thursday, haulier 15:30". The ticket is Emergency before she has finished her first sip of tea. She phones the bay and learns that hand-written notes will hold for an hour. She drops it to Urgent with the workaround noted, and has the tablet working by 14:50. Dev, on holiday, hears about it the following week and is faintly disappointed not to have been needed. That is the register working exactly as intended.

Frequently Asked Questions