Telling Users Before They Notice: The Proactive Message

Thursday, 16:40, at Acme. Sam has spent the afternoon on the weekly sweep, moved to Thursday because Friday is a holiday. Nine laptops cleaned and back above the threshold, one battery swapped by appointment, one certificate on the intranet server renewed four days before it would have expired and taken the staff directory with it. Nine users have no idea anything happened to their machines. The battery user said thank you. The certificate was never going to be noticed by anyone, which was the point. At five, Carla, the operations director, stops by the desk on her way out. "Quiet week for you lot? I haven't had a single complaint. I was thinking we could probably manage with one of you on Fridays." She means it kindly, which is the worst kind.

Sam has just met the problem that sits underneath this whole series: prevention is invisible by design. A prevented ticket leaves no trace. It does not even have the decency to haunt anybody. A proactive notice is a short message to a user about something the desk found and fixed, or is about to fix, before the user noticed it. This article is about three decisions around it. The first is whether to tell the user at all, and the second is what the message says when you do. The third is how a desk claims some credit for work nobody saw without inflating it or becoming a nuisance. This article is part of our Proactive Remediation series, and it is the communication half of every sweep the other articles describe.

It covers the quiet fix nobody sees and why it is a problem. Next come three reasons to tell and one not to, then the shape of the proactive message. Timing, which is before rather than after, follows. Then come the message that asks the user to do something and the one-time announcement before the first sweep. The article covers the credit the desk never gets and the honest ways to claim some. It finishes with a short war story and the proactive notice to copy, in that order.

The Quiet Fix Nobody Sees

A fix that arrives before the fault has no witness. When a technician repairs a dead laptop, the user watches, waits, and is grateful. When the same technician swaps the drive a week before it would have died, the user has an appointment they did not ask for. They have a laptop that works exactly as it did yesterday. Nothing has changed from where the user sits. The work is real and the gratitude is not. A desk that does a great deal of prevention is a desk that is thanked less each quarter while working as hard as ever.

The second consequence is the one Carla voiced. A desk is judged, in most organisations, by complaints and by visible outages, and prevention reduces both. So the better the desk gets at it the more it looks idle. The budget process has no column for the outage that did not happen. The monthly report counts tickets, and the tickets the sweep prevented are not in it, because they were never raised. A desk can prevent itself out of a headcount, and some have.

The cure for invisibility is not noise. A desk that responds by telling everyone about everything becomes a desk that sends messages nobody reads. The one message that genuinely needed reading, "your laptop's drive is failing, we need an hour", gets filed with the rest. The three decisions in this article are about being seen exactly as much as the work deserves. That means telling the users who need telling, in two lines. It means putting the rest into a record that management reads once a quarter. Seen enough, and no more.

Three Reasons to Tell, and One Not To

Tell the user when they will notice a change. Consider a cleared cache that signs them out of a web application, or a restarted machine that lost the windows they had open. Consider a folder that has moved to the share. Each of these will be discovered, and a user who discovers a change with no explanation assumes something broke. Two lines sent before they sit down turn a mystery into maintenance. The test is simple: if the user could, on Monday morning, say "that's different", they get a message.

Tell the user when they need to act. There may be files to move, an appointment to agree, a restart to do at the end of the day, or a password that will expire. The notice is the request, and it carries a date and a reason. Tell the user, too, when they would otherwise find out some other way and wonder. A new drive in a laptop is visible to anyone who looks at the serial number. A technician who was at their desk while they were out will be mentioned by a colleague. A short note saying "we were at your machine today, here is why" costs thirty seconds and prevents a week of low-level unease.

Do not tell the user when the change is invisible and needs nothing from them. Take the print service restarted at ten on Sunday night, or the certificate renewed on the server. Take the log folder capped on a machine they never log into. These go in the ticket and the monthly line, not in anyone's inbox. I once sent forty users a message about a certificate renewal they could not have noticed. I got eleven replies asking what a certificate was and one asking whether the desk was all right. The table below is the decision in one place.

The Shape of the Proactive Message

The message has four parts and fits in four or five lines. It says what we found, in the user's terms, and what we did or will do. It says what you will notice or need to do, and how to say no or ask a question. "What we found" is never a reading from a report. Not "your system drive was at 6 percent free" but "your laptop was close to running out of space, which is what makes it freeze". "What we did" is one sentence, in plain words, without the name of a tool or a script. "What you will notice" is the honest part, and the part most often skipped. For example: "the first time you open the intranet it will ask you to sign in again". "How to ask" is the ticket number and the desk's address, and the sentence that says the user can decline, where declining is possible.

The tone is a colleague leaving a note on your desk, and that means short sentences, no apology for existing, and no programme language. Do not write "as part of our ongoing commitment to proactive service excellence". Not in a notice. Not anywhere. Not even ironically. A user reading that line learns only that the desk has started talking like a brochure. The next notice from the desk is deleted on sight. Write the way the technician would say it at the user's desk, which the Support Tone and Voice series covers in general. The proactive notice is that voice applied to a user who did not ask.

Name the ticket and keep the message on it. The notice is a public reply on the proactive ticket the technician raised on the user's behalf. That way, the user's reply, if there is one, lands on the same ticket and the whole exchange has a record. The technician's working, the folder sizes and the before-and-after numbers, stay in the internal note. The user sees four lines. A year from now the desk sees everything.

Before, Not After

The proactive message goes before the thing the user will notice, wherever that is possible. A message that arrives after a change is an explanation. A message that arrives before it is a courtesy. "We will be at your desk between nine and ten tomorrow to swap the battery; it takes about twenty minutes and you can keep working on the loan laptop" gives the user control over their morning. "We swapped your battery this morning while you were in the meeting" gives them a fact. Both are better than silence; only the first is a choice.

For the work that is already safely done, the "we did" message is right. That message should still arrive before the user discovers the change rather than after. The cleared cache is the common case: the cleanup ran on Friday, so the message is sent on Friday. And the user reads it on Monday morning before the sign-in prompt rather than after it. Timing is a courtesy about the user's attention. A message that arrives after the surprise has to overcome the surprise first.

Be honest about delay without narrating it. Suppose the sweep found the drive warning on the first of the month and the swap is on the twentieth because the spare was late. In that case, the message says what will happen and when, not "we noticed this three weeks ago". The user does not need the desk's internal history to make a decision. And a history of delay in a notice reads as either a confession or an excuse. The ticket holds the history. The notice holds the plan.

The Message That Asks for Something

When the user has to act, the message carries one ask, a date, and a reason, and it says what happens if the date passes. One ask: not "move your files, restart, and let us know when you are free for the battery", which is three messages wearing one subject line. The date is near and specific, "by Friday the week after next" rather than "soon". And the reason is the user's reason, "so the laptop does not freeze again", not the desk's. What happens if the date passes is stated without threat: "if the space is still short we will book a time to look at it together". The user should be able to read the message in fifteen seconds and know exactly what to do and by when.

Offer two times for anything that needs the technician at the user's desk, because "when would suit you" produces a week of silence and "nine or two tomorrow?" produces an answer. For files, name the folder and the size, in terms the user will recognise. Offer the easiest route first: "the recordings in your Documents folder, about forty gigabytes; the share at the usual path has room, or tell us if they need to stay and we will look at a bigger drive". The user is being told where the space went, not what they should have done with it.

Follow up once, after the date, in two lines, and then convert. A user who has not moved the files in a week gets a short note and an offered time. A user who has not replied to the second note gets a call. The craft of a follow-up that gets a reply rather than an eye-roll is the business of Follow-Up Messages That Get Replies. The proactive version differs only in that the user never asked for any of this. So the second message is shorter and kinder than usual, not longer.

The One-Time Announcement

Before the first sweep runs, everyone gets one message, and after that only the users with a hit do. The announcement says what the sweep reads, in plain words: free space, the machine's own health figures, whether updates are waiting. It says what the desk may clean without asking, which is system files the user never created. It says what the desk will never touch, which is anything the user made or saved. It says how the user will hear about a hit, which is a short note on a ticket, and how to ask a question or object. It is short, it is friendly, and it goes out once, with a copy kept somewhere permanent for new starters.

The announcement is also where the swollen-battery paragraph from the hardware article belongs, because the sweep cannot see swelling and the user can. One sentence, with what to look for and what to do, turns every user into part of the hardware watch. If you run QuerySolv, the announcement lives naturally as a knowledge base article visible to everyone. In that case, each proactive ticket's internal note can point at it rather than repeating it. In any tool, the test concerns a user who gets their first hit notice. They should be able to find, in one click, the page that says what the sweep is and why the desk was looking.

Where the maintenance is a scheduled window that affects a whole site, the message is the planned-maintenance notice. That is a different document with a different audience and its own article in Planned Maintenance Notices. The distinction is worth holding: the planned-maintenance notice is one message to many people about a time. The proactive notice is one message to one person about their machine. Desks that confuse the two send everyone a note about one laptop, or send one person a notice about the whole building.

The Credit the Desk Never Gets

A desk is funded on what it is seen to do, and prevention is not seen. So the desk has to make it visible on purpose, honestly, in four places. The first is the ticket. Every proactive fix is a ticket, raised by the technician on the user's behalf, with a first line that says it was found before it was reported. That one habit puts the work into the same numbers as everything else. And it is the reason the first article in this series insists on it. A desk that prevents thirty tickets a month without raising thirty tickets has done the work and destroyed the evidence.

The second is a line in the monthly report headed "found before reported", with the count and the rule for counting stated beside it. The third is a three-line note to management each quarter: what was swept, what was found, and what did not happen as a consequence, stated as a range. "Swept sixty laptops weekly and all servers monthly; found and fixed ninety-one conditions before anyone reported them; based on last year's rate for the same conditions, that is somewhere between fifty and ninety tickets that did not arrive, and roughly forty to a hundred hours of desk and user time." The range is the honest part, and Explaining Technical Things to Management is the article on making those three lines land. The fourth is the occasional reply to a user that says "we found this on the sweep" rather than "fixed". That is so the people who do notice connect the quiet with the desk.

What the desk does not do is inflate. It does not claim every quiet week. It does not count a cleaned laptop as a prevented outage. It does not send users a newsletter about prevention, because the newsletter is read by the person who writes it and by nobody who needed persuading. The credit the desk is entitled to is the credit the ledger supports, in a range, with the counting rule beside it. The last article in this series, Measuring the Tickets That Never Arrived, is the ledger. The three-line note is its summary; the ledger is what you show when someone asks how you got the numbers, and someone always asks.

Carla's Friday remark gets a straight answer, and the answer is not defensive. "It has been quiet because of the Thursday sweep. Here are the nine machines we cleaned this week, the battery, and the certificate on the intranet that would have taken the staff directory down on Monday. Last year we had around twenty tickets a month for the same things. If we drop Fridays, we drop the sweep, and the tickets come back." That is a sentence with a ticket list behind it, and a director can act on it. "We've actually been really busy" is a feeling, and a director cannot.

A Short War Story: The Quiet Year at Oakfield Academy

Oakfield Academy's two-person desk had its best year on record, in the sense that almost nothing went wrong. Reuben and his colleague swept the staff laptops every fortnight and replaced fourteen batteries by appointment. They caught the exam-results server's disk at twelve percent free a month before results day. They renewed the parents' portal certificate two weeks before it would have locked out every family in the school on the first evening of the summer term. Not one of those was a ticket, because the desk had fixed them and moved on. Not one was reported to anyone, because nobody had asked. At budget time the bursar proposed removing the second desk post, on reasonable grounds. Complaints were down, nothing seemed to go wrong, and the desk looked, from the outside, like two people with time on their hands. Reuben's evidence was his memory, which the bursar was polite about. The post was cut and the sweeps stopped. The following results day the server filled at nine in the morning with four hundred families refreshing a portal that would not load. The lesson Reuben wrote afterwards was short: work nobody can see is work nobody will fund. The ticket, the monthly line and the three-line note would have cost him an hour a month.

The Proactive Notice

The template below gives the three forms the notice takes: the fix already done, the appointment needed, and the action needed by a date. Each is four or five lines and follows the same four parts. And each is sent as a public reply on the proactive ticket so that the user's answer lands in the right place. Fill the blanks from the ticket, keep the user's terms rather than the report's, and resist adding a paragraph. The lines at the bottom are the rules that keep the notice from becoming a newsletter.

THE PROACTIVE NOTICE — THREE FORMS
Ticket: ________   To: ______________   Sent as: public reply on the ticket

FORM 1: FOUND AND FIXED (nothing for the user to do)
  Subject: Your ______________ (a quick note from the IT desk)
  Hello ________,
  On our regular check we noticed your ______________ was ______________,
  which is what causes ______________.
  We have ______________; it took about ____ minutes and nothing you saved
  was touched.
  The only thing you may notice is ______________.
  Nothing to do; reply to this note if anything looks different. Ticket ________.

FORM 2: FOUND; APPOINTMENT NEEDED
  Subject: Your ______________ needs a quick swap (about ____ minutes)
  Hello ________,
  On our regular check your ______________ is showing ______________. It is
  still working, and we would like to replace it before it stops.
  It takes about ____ minutes; you can keep working on a loan machine.
  Would ______ or ______ suit you? Reply with either and we will book it.
  Nothing you have saved to ______________ is affected. Ticket ________.

FORM 3: FOUND; ACTION NEEDED BY A DATE
  Subject: Your ______________ is running short of ______________
  Hello ________,
  On our regular check your ______________ is close to ______________, which
  is what makes it ______________.
  Most of the space is in ______________ (about ____ GB). The easiest fix is
  ______________; if those files need to stay, tell us and we will look at
  ______________ instead.
  Could you do that by ______________? If it is still short then, we will book
  a time to sort it out together. Ticket ________.

RULES FOR EVERY FORM
  Four parts: what we found, what we did or will do, what you will notice or
  need to do, how to reply or decline.
  The user's words, not the report's: "close to running out of space", not a
  percentage.
  One ask per message; two offered times for anything needing a visit.
  Sent before the user would notice, not after.
  Technician's working stays in the internal note; the user sees these lines only.
  Invisible changes that need nothing from the user get no notice at all.

Sam answered Carla on the Monday, with the list. The Thursday sweep stayed, and so did Fridays. Acme's monthly report now has a line near the top that reads "found before reported". Carla, who asked what it meant the first month, now reads it before the complaints count. That is because "found before reported" is the only line on the page that goes up when things are going well.

Frequently Asked Questions