What Proactive Support Actually Means, and Why Desks Stay Reactive

Tuesday, 09:40, at Redbrook Engineering. Imogen runs a desk of four for about 380 people across a head office and a works site. For the third year running the annual plan has a line in it that says "move to proactive support". Kwame has just claimed ticket 7312, an account that locked itself at 09:15, the eleventh this week with the same cause: an old password saved on somebody's phone. He will fix it in six minutes, as he fixed the other ten. Nobody will fix the cause this week either, because the queue holds forty-one tickets and the plan is a document. Documents do not claim tickets.

Proactive support is work the desk does before a request arrives, with the aim of making that request unnecessary, earlier, or cheaper. It is three different things wearing one word. The word has been used so loosely that most people hear it as "more monitoring" or "a dashboard with a map on it". This article is part of our From Reactive to Proactive Support series. The series is about putting prevention in the calendar rather than in the plan. This article says what the word means before the rest of the series says how to do it.

It covers why reactive is the natural state of a desk and not a moral failing, and why proactive is not more monitoring. Then come the three kinds, prevention, pre-emption and preparation, each with a plain example. Next comes the time-budget question every proactive plan has to answer before anything else. The article then covers the audit of one month's tickets at Redbrook, sorted into three piles. It ends with a short war story and the reactive-proactive audit sheet to copy, in that order.

Reactive Is the Natural State of a Desk

A reactive desk starts work when someone reports a problem and stops when the problem is fixed. Every desk begins this way because it is what a desk is for. A request arrives, it gets a number, a person, a clock and a place in a list. The list is visible on a screen, the clock is counting, and the requester is waiting. Nothing about the cause of the request has any of those properties. The cause has no number, no owner, no clock and no requester. It is not in the list. Nobody is waiting for it to be fixed, because nobody knows it is the thing they are waiting for.

Reactive work wins every hour of every day because it is the only work that asks. A ticket with a service-level target that breaches at 11:00 is louder than a cause that will produce another forty tickets this month. It is louder at 10:55 in a way that the cause will never be. The same is true of the report. A desk is measured on response time, resolution time and backlog, all of them properties of tickets that exist. A desk that removed a cause has nothing to put on the report except a number that did not go up. You cannot screenshot a ticket that never arrived.

This is why "we should be more proactive" appears in three annual plans in a row and in no calendars. The plan is written in a quiet week, usually January, by someone who means it. The queue does not read the plan. By February the queue has reclaimed every hour the plan was going to use, one ticket at a time, each one reasonable. The plan goes back in the drawer with its predecessors. I have written that line in a plan myself. Twice. The drawer at my old desk was quite full.

None of this is a failing of the people on the desk. It is the shape of the work. The shape can only be changed by changing the calendar, which is the subject of the whole series and especially of the prevention hour. Before the calendar, though, the word needs defining, because a desk that sets out to be proactive without knowing which kind it means usually buys something instead.

"Proactive" Does Not Mean More Monitoring

Monitoring tells you sooner that something has broken, which is reaction with a head start, not prevention. A monitoring tool watches a service, a disk or a link and raises an alert when a threshold is crossed. A good one opens a ticket by itself, and the mechanics of that are in the monitoring-to-ticket series. It is worth having. Monitoring shortens the gap between the fault and the desk knowing about it. Sometimes it closes the gap between the fault and the user noticing, which is pre-emption. We will get to that. What it does not do is remove the fault. The disk that fills every month still fills every month; the alert simply arrives before the complaint does.

The confusion comes from the sales pitch, which is not the vendor's fault so much as the word's. A screen of forty green tiles looks proactive. It looks like the desk is watching, which it is. But a desk that reacts to forty alerts a day is a reactive desk with a faster doorbell. The test is simple: did the number of things that break go down, or only the time it took to find out? If the count of alerts stays level year on year, the monitoring is doing what it was built for and the proactive work has not started. A dashboard is a very fast way of being reactive.

Keep the monitoring, then, and stop counting it as the proactive programme. It is one of the signal sources the programme uses, alongside the ticket data. The tickets are usually the better source for a small desk, because they come with the user's own words and the technician's note about what fixed it. The alert says the disk is at ninety percent. The ticket says the disk is at ninety percent because the finance application writes a log it never trims. That sentence is the one prevention is built from.

The Three Kinds, Side by Side

Proactive support is prevention, pre-emption or preparation, and the three differ in what they do to the ticket. Prevention removes the cause, so the ticket never arrives. Pre-emption fixes the fault before the user reports it, so the ticket arrives on the desk's schedule or not at all. Preparation makes the desk ready for the ticket that will arrive anyway, so it costs less when it does. All three are proactive; only the first reduces the amount of work in the world. The other two move it or cheapen it, which is still worth a great deal. But a plan that promises "fewer tickets" and delivers preparation will be asked why the count has not moved.

The table puts the three beside each other with a Redbrook example for each, and names the article in this library that owns the mechanism. This series is the roof of the library rather than a new floor. Each mechanism already has its own article, and this one points at them rather than rebuilding them.

Most real proactive work is a mix, and the mix is decided by what the desk can reach. A cause that lives in a system the desk owns can be prevented. A cause that lives in a supplier's product or another department's process can often only be pre-empted or prepared for, until the owner of the cause is persuaded, which is a later conversation. The useful habit is to name the kind out loud every time something is proposed: "that is preparation, it will not reduce the count, and it is still worth an afternoon." Naming it stops the programme promising one thing and delivering another.

Prevention: Removing the Cause

Prevention is the only kind that makes the queue smaller, and it works by finding the one cause behind many tickets and removing it. The eleven lockouts in Kwame's week share a cause: a password changed on the computer and still saved on the phone, which retries the old one until the account locks. Fix the eleven and you have eleven resolutions. Fix the cause and you have, next week, perhaps one. The hunt for the shared cause is the subject of finding the repeat tickets. The fix itself is getting the permanent fix done. The next article in this series is about choosing which cause to go after first. Here it is enough to say that prevention is a decision about causes, and a desk that only ever sees tickets never gets to make it.

Prevention costs time up front and pays it back slowly, which is the whole reason it does not happen on its own. The sweep of saved sessions at Redbrook took Kwame four hours spread over two prevention slots, plus a sentence added to the reset reply template. The lockouts fell from about fifty-four a month to about nine. At a quarter of an hour each, that is roughly eleven technician hours a month, every month, for a one-time cost of four. Nobody argues with that sum once it is written down. The difficulty is that it cannot be written down until the four hours have been spent, and the four hours are the hours the queue claims first.

Prevention is also the kind with the longest reach and the most owners, which is why the series gives it four of its six articles. Some causes the desk can remove by itself in an afternoon. Some need a maintenance routine that runs every quarter, which is the third article. Some belong to someone else entirely, and the desk's part is evidence and persuasion. All of them begin the same way: a cause named, a count of the tickets it produces, and an hour in the calendar with a name on it.

Pre-emption: Fixing It Before It Is Reported

Pre-emption is doing the reactive fix earlier, on the desk's timetable, before the user has had to ask. The fault is real and the work is the same; what changes is who chose the moment. A disk that is going to fill on Monday can be cleaned on Friday afternoon, when the technician has a sweep running and the user is not waiting. A laptop whose battery is reporting wear can be swapped at the user's next visit to the office rather than on the morning it dies in a client meeting. The signals that make this possible, and the weekly sweep that reads them, are in fixing before the ticket, and this article leaves them there.

Pre-emption does not reduce the work; it moves it to a better time and removes the waiting. That is its honest description and it should be used, because the two things it removes, the user's downtime and the interruption to the desk, are worth more than the ticket. A disk cleaned on Friday costs the same forty minutes as a disk cleaned on Monday. But Monday's version came with a user who could not open the month-end report, a phone call, a walk-up, and a technician pulled off something else. Pre-emption is the difference between work and emergency work, and emergency work costs about double, in my experience, before you count the mood.

The limit of pre-emption is that it needs a signal, and most faults do not send one. Disks, batteries, certificates and the event log give warning; a user's confusion about a new form does not. A desk whose proactive plan is entirely pre-emption will cover the hardware and the infrastructure and nothing else, which is a fine start and a poor finish. (It is also the part the monitoring vendor will offer to sell you, which is how the confusion in the previous section got started.)

Preparation: Being Ready When It Happens Anyway

Preparation is everything the desk does so that the ticket it cannot prevent costs less when it comes. The licence error in Redbrook's drawing application arrives about twice a week and will go on arriving until the supplier changes something. Nobody at the desk can prevent it. What the desk could do, and did, was write the recognition test and the three-step workaround down once. That makes the fix take two minutes from any technician instead of forty from whoever happens to remember. That record is the known-error record, and the runbook that does the same job for routine procedures is in the technician docs series.

Preparation is the kind most desks are already doing without calling it proactive, and the kind that is easiest to expand. A spare dock on the shelf is preparation. A template for the outage message, written in a calm week and filled in during a loud one, is preparation. The incident routine, with its named lead and its update cadence, is preparation for the worst day of the quarter. None of it reduces the ticket count. All of it reduces the hours, the waiting and the number of people shouting. A plan that measures only the count will undervalue every bit of it.

Count preparation as proactive and report it honestly as such. "We cannot stop the licence error; we have made it a two-minute ticket" is a true sentence and a good one. It will be believed, which matters more than it should when the same desk later says "we have stopped the lockouts". The credibility a desk earns by not overclaiming preparation is the credibility it spends when it claims prevention.

The Time-Budget Question Every Plan Must Answer First

Every proactive plan has to answer one question before it says anything else: where do the hours come from? Not in principle, in the calendar. Prevention costs hours before it returns any, and the hours it costs are the same hours the queue is using now, because the desk has no others. A plan that lists eight proactive initiatives and does not say which hours they will consume, from whom, starting when, is a list of wishes. The queue will treat it as one. The honest plan names the hours first and the initiatives second.

Redbrook's arithmetic is worth doing in full, because it is the arithmetic every small desk faces. Four technicians at roughly thirty-five working hours a week is about 140 hours. Imogen's best estimate came from a fortnight of the team noting what they were doing each hour. She estimated that about 112 of those hours went on the queue and the interruptions around it. About 28 went on everything else (the project to replace the works-site switches, training, covering for leave, meetings). None, in any week she could find, went on removing a cause. The preventable tickets in her audit, below, came to around 165 a month at a bit under half an hour each. That is something like 75 technician hours a month, or 17 or 18 a week, being spent on tickets whose cause could be removed. The desk had no hours budgeted for removing them and eighteen hours a week budgeted for suffering them.

The answer to the question is always the same shape, and it is never free. It is a fixed, small, protected slice of the week, taken out of the queue's hours on purpose, with the manager's name on the decision. For a desk of four that usually means an hour a week each to begin with, which is four of the 112 queue hours. The queue will be very slightly slower for a quarter until the first cause is removed and gives the hours back with interest. The slice, how it is protected, and the conversation with leadership that goes with it are the fourth article in this series. Here the point is only that the question comes first, and a plan that cannot answer it in hours should not be presented as a plan.

The Audit at Redbrook: One Month, Three Piles

The reactive-proactive audit is one month of tickets sorted into three piles, preventable, pre-emptable and inevitable. It is the first thing a desk should do, because it turns "we should be more proactive" into a count. Imogen took the previous month, 520 tickets, and sorted them with Rosa over two afternoons. The sorting question for each ticket was not "could this have been avoided in a perfect world" but "is there a specific, named cause that the desk, or someone the desk can persuade, could remove or get ahead of". If yes and the cause can be removed, the ticket is preventable. If the fault is real but a signal existed before the user noticed, it is pre-emptable. If neither, it is inevitable, which includes every genuine request, every how-do-I, every new starter and every hardware failure that gave no warning.

The piles came out at 165 preventable, 70 pre-emptable and 285 inevitable. The preventable pile was the interesting one, because it was not 165 different causes. It was about nine. The stale-credential lockouts were 54 of them. A printer driver that reset its defaults after every monthly update was 31. Disk-full slowdowns on the older works-site machines were 16. A shared mailbox permission that had to be granted by hand for every new person in the sales team was 14. The rest of the pile was five smaller causes and a tail of singletons. Nine causes, three of them removable by the desk alone, were producing about a third of the month. Nobody on the desk was surprised. Everybody on the desk could have named the top three without the audit. What the audit added was the count beside each name, and the count is what gets an hour into a calendar.

Calibrate the sort before trusting it, because it is a judgement and two people will make it differently. Imogen and Rosa sorted the first fifty tickets together and argued about eleven of them. They wrote down the rule they settled on for each argument ("a request that only exists because a process is broken is preventable; a request that would exist anyway is inevitable"). Then they sorted the rest separately. The rules went on the audit sheet below, so that next quarter's audit uses the same ones and the piles can be compared. Without the rules, the second audit measures a change in the sorter rather than a change in the desk. If you run QuerySolv, the month's ticket list and the hands-on time per ticket type come out of the standard volume and resolution-time reports. In that setup, the event history on each ticket shows what was actually done. With any other tool, an export to a spreadsheet does the same job in an hour.

Write the hours beside the piles, not just the counts, because the hours are what the time-budget question is answered in. A pile of 165 preventable tickets at a bit under half an hour each is about 75 hours a month. A pile of 70 pre-emptable tickets at closer to an hour each, because they tend to be the slow, messy ones with a user waiting, is about 60. The inevitable pile is the desk's real baseline load, the work that will remain when the programme has done everything it can. It is worth knowing for the staffing conversation, which is the headcount case in another series. Redbrook's inevitable pile was 285 tickets and about 170 hours. That is the desk that would exist if prevention finished its work, and it is a smaller, calmer desk than the one that existed in the audit month.

A Short War Story: The Forty Red Tiles at Tollgate Foods

Tollgate Foods' desk of three, led by a technician called Soren, was told at a budget review that it needed to "become proactive". The operations director approved a monitoring tool the following month, because a tool was the only proactive thing anyone in the room could name. By the end of the quarter the wall screen showed forty tiles, each site, each server, each link. Most mornings two or three of them were red before anyone had reported anything, which everyone agreed was progress. The ticket count did not move. The same depot printer jammed every Tuesday. The same two handhelds dropped off the wireless in the chiller. The same shared drive filled on the last working day of each month. The desk now knew about each of them about twenty minutes sooner. At the next review the director asked why the proactive tool had not reduced the tickets. Soren, who had spent the quarter tuning alert thresholds instead of fixing the drive, had no answer that fitted on a slide. The cost was a quarter of one technician's time, a tool subscription, and a director who now believed proactive support did not work. Monitoring buys you twenty minutes; prevention buys you the Tuesday, and only one of them was ever going to change the count.

The Reactive-Proactive Audit Sheet

The sheet below is the audit as a form, done once a quarter on one ordinary month. Section A fixes the month and the sort rules, so that the next audit is comparable. Section B is the three piles with their counts and hours. Section C is the part that matters: the named causes behind the preventable pile, with a count each. That becomes the input to the next article's candidates list. Section D is the time-budget line, filled in honestly, even if the answer is "none yet". Keep the completed sheets; the third one is the first time you will be able to see the piles moving.

REACTIVE-PROACTIVE AUDIT — ONE MONTH, ONE PAGE
Desk: ______________________   Month audited: ____________   Sorted by: ______________ and ______________

A. THE SORT (same rules every quarter)
   Preventable  = a specific, named cause that the desk, or someone the desk can
                  persuade, could remove; the ticket would then not arrive
   Pre-emptable = a real fault, but a signal existed before the user noticed
                  (disk, battery, certificate, event log, a known pattern)
   Inevitable   = a genuine request, a how-do-I, a starter, a leaver, a failure
                  with no warning, or a cause nobody can reach
   First 50 sorted together by both sorters: yes / no
   Rules agreed from the arguments:
     1. _______________________________________________________________
     2. _______________________________________________________________
     3. _______________________________________________________________

B. THE THREE PILES                      Tickets    Hours (hands-on, from a sample)
   Preventable .......................  ______     ______
   Pre-emptable ......................  ______     ______
   Inevitable ........................  ______     ______
   Total for the month ...............  ______     ______

C. THE CAUSES BEHIND THE PREVENTABLE PILE (largest first)
   Cause                                  Tickets   Hours   Who can remove it
   1. ______________________________      ______    _____   ______________
   2. ______________________________      ______    _____   ______________
   3. ______________________________      ______    _____   ______________
   4. ______________________________      ______    _____   ______________
   5. ______________________________      ______    _____   ______________
   Smaller causes and singletons .....    ______    _____

D. THE TIME BUDGET (in hours a week, for the whole desk)
   Hours on the queue and its interruptions ........ ______
   Hours on projects, training, cover, meetings ..... ______
   Hours on removing a cause, this month ............ ______
   Hours proposed for prevention next quarter ....... ______   protected by: ______________

E. BEFORE THIS LEAVES THE DESK
   [ ] One ordinary month; nothing unusual in it, or the oddity is noted here: ____________
   [ ] Every ticket is in exactly one pile
   [ ] Hours are from a sample of real tickets, not a guess
   [ ] Section C names causes, not categories ("saved old password on phones", not "lockouts")
   [ ] Section D is honest, even if the prevention line says zero

Imogen's first sheet said zero on the prevention line, which she left in rather than rounding it up to something that looked like effort. It was the most useful number on the page. The next article is about what she did with section C.

Frequently Asked Questions