Teaching Prevention After the Rescue, Without a Lecture

Thursday, 10:20, at Northgate Retail. Tom has just pulled the Harbor Street store's weekly rota out of the file service's recycle bin. It had been there since Carla, the store manager, tidied her folders on Tuesday evening. The rescue took four minutes. Carla's reply arrives before he has finished writing the note: "THANK YOU. I had eleven people's shifts in that and I was about to redo it from the whiteboard." Tom has a choice about what to type next. He can say "no problem" and resolve the ticket. He can attach the desk's three-page guide to file hygiene. Or he can say one true sentence that Carla will still remember in a month. That is the only one of the three that changes what happens next Tuesday.

Teaching prevention after the rescue is using the minute of gratitude that follows a recovered file. You pass on the one thing that would have made the rescue unnecessary, in a way the person can hear. It is not a policy, a guide or a reminder. It is a sentence, sent by the person who just helped, at the only moment anyone has ever been known to listen. This article is part of our Deleted Files & Recovery Requests series. The series covers the request, the restore, the file that cannot be recovered, versioning, prevention and measurement. This article is about the message that goes out when the file comes back.

It covers why the rescue is the only teachable moment. Then it covers the one-sentence lesson and how to choose it, and where to save and why, in words a user keeps. Next come the desktop folder problem and the desk's fix for it, naming and the overwrite, and not lecturing. Then it covers when the lesson should become policy instead, and the follow-up that is not a nag. It ends with a short war story and the after-rescue message to copy, in that order.

Why the Rescue Is the Only Teachable Moment

People learn where to save files at exactly one time, which is the minute after they nearly lost one. Before the loss, the subject is abstract and the guide is unread. A document called "File Storage Best Practice" has never once been opened on purpose. During the loss, the person is frightened and cannot take anything in. A month after the rescue, the fright has faded and so has the lesson. The minute after the file comes back is different. The person is relieved, grateful, paying attention, and holding in their mind the exact action that caused the problem. A sentence said then lands. The same sentence in an all-staff e-mail does not land, and the desk has sent that e-mail, so it knows.

The moment is also narrow. It lasts from the reply that says "it's back" until the person has moved on to the next thing. On a busy day, that is a few minutes. The lesson therefore goes in the same message as the good news. It does not go in a follow-up, in a separate ticket, or in a "while I have you" that arrives after lunch. Good news first, in the first line, because the person reads nothing else until they have it. Then the one sentence. Then the way to ask more. That is the whole shape.

There is a quieter reason the moment matters. A rescue is a small act of trust. The person asked for help, the desk delivered, and the person is now disposed to believe the desk about files. That disposition is worth something and it is easily spent. A lecture spends it. A three-page attachment spends it. One sentence that is plainly for the person's own benefit, and nothing else, invests it. The desk that understands this treats every recovery ticket as two jobs, the rescue and the sentence. It does the second with as much care as the first. (The first is easier. The second is shorter.)

The One-Sentence Lesson

The lesson is one sentence, chosen to match the exact loss, and it says what to do, not what not to do. "Save the rota into the store's shared folder rather than your desktop, and it will be backed up and keep its own history" is a lesson. "You should not save important files to your desktop" is a reproach with the same information in it, and the person hears the reproach. The difference is the direction. The lesson points at the next time, and the reproach points at the last time. Only one of those can still be changed.

One sentence means one. A rescue that reveals three bad habits produces three temptations. The message that addresses all three teaches none of them, because the reader stops at the first "also". Pick the habit that caused this loss and leave the others for their own rescues, which will come. If the file was in the wrong place, the lesson is the place. If the file was overwritten, the lesson is version history. In that case, the user guide in Versioning Saves More Than Backups Do is the thing to link. If the file was deleted by a tidy-up, the lesson is the recycle bin and how long it keeps things. If the file was never saved, the lesson is the automatic save and where it puts things. The table below pairs each shape of loss with its sentence and with the structural fix that sits behind it. That fix is the desk's job rather than the user's.

Notice that every lesson in the middle column has a "because" in it. People follow instructions they understand the reason for and ignore the rest. The reason for saving to the shared folder is not "policy" but "it is backed up and keeps history and your desktop is not". Say the reason every time. It is the part they remember when the instruction has faded.

Where to Save, and Why, in Words a User Keeps

Most users have never been told, in plain words, which places are safe and which are not. The after-rescue message is the first time anyone has explained it to them with a reason attached. The explanation fits in three lines. The shared folders on the file service are backed up, keep earlier versions, and can be reached by the desk when something goes wrong; they are where work lives. The desktop and documents folders on the computer are not backed up unless the desk has set them up to be, and most people cannot tell by looking; they are where work gets lost. The sync folder is a view of the service, protected for anything that has finished syncing and not for anything that has not.

Users save to the desktop because it is the first thing they see and the easiest place to find a file again. No amount of explaining changes that. The explanation only works if the desk also makes the safe place as easy as the desktop. That is the point of the structural fixes in the table. A desk that redirects the desktop to the file service has made the lesson unnecessary. A desk that puts a shortcut to the team's shared folder on every desktop has made it easy. A desk that does neither and sends the lesson anyway is asking people to be careful instead of making carelessness safe. People are not reliably careful, including the people on the desk.

Tie the words to the person's own folders. "The Harbor Street folder under Stores" is a place Carla can picture. "The appropriate network location" is not. If the person's team does not have an obvious shared folder, that is a finding. In that case, the message should say "I have made you one at this address" rather than "you should use a shared folder". A lesson about where to save that does not name a place is a lesson about nothing.

The Desktop Folder Problem

The desktop folder is responsible for more unrecoverable files than any other place. The problem is the desk's to fix, not the user's to avoid. The desktop is visible, and it is where downloads land. It is where a file saved in a hurry goes by default in many applications. It feels like "my computer" in a way a drive letter does not. On a managed computer the desk can make the desktop and documents folders live on the file service. With that change, they look and behave as they always did and are quietly backed up and versioned with everything else. That change is called folder redirection, in plain words "your desktop is really a folder on the server". It is the single most effective prevention step in this whole series, because it removes the choice instead of asking people to make it well.

Where redirection is not yet in place, the after-rescue message says so honestly and still gives the person a safe place today. "Your desktop on that laptop is not backed up, and that is something we are fixing across the company; until it is, please keep the rota in the Harbor Street folder, and I have put a shortcut to it on your desktop so it is one click away." The sentence owns the gap, gives a place, and makes the place easy. It does not say "you should know better", because the person had no way of knowing, and the desk did.

The half-measures are worth knowing because they are often all a desk can do this month. A shortcut on the desktop pointing at the shared folder gives the convenience without the risk. A sync client that mirrors the desktop folder to the service does much the same on computers the desk does not fully manage. The sync caveats from the versioning article apply. A quarterly reminder from the desk to the people who were rescued last quarter, asking whether the shortcut is still there, is cheap. None of these replaces redirection. All of them are better than a lesson repeated to the same person twice.

Naming, Save-As and the Overwrite

Naming is the habit that users ask about most after an overwrite. That is because the overwrite usually happened through a save-as into a name that already existed. The person wants a rule that stops it happening again. The useful rule is small: start file names with the date, year first, then month, then day, followed by what the file is. That way, versions sort in order and a save-as produces a new name by default. "Rota Harbor Street" becomes "the date, then Rota Harbor Street", and next week's copy is a different file rather than this week's file replaced. The rule costs nothing to adopt and removes most template overwrites on its own.

Resist the urge to issue a naming standard. A standard with prefixes, codes and a controlled vocabulary will be followed for a fortnight by the person who wrote it. The desk will inherit a share where half the files follow it and half do not. That is worse than none. One line, "date first, then what it is", in the team's folder guide and in the after-rescue message when naming was the cause, is the whole standard. Where a team genuinely needs more, the team's own manager writes it, for their own files, and keeps it. The desk's interest ends at files that can be found and are not saved over.

Version history makes naming matter less, and the message can say so. A person whose files live on a service that keeps versions can recover a save-as mistake in a minute from the history. In that situation, the date-first habit becomes a convenience rather than a protection. Say which situation the person is in. On the old server without versions, the date-first name is the only earlier copy there will be. In that case, the sentence is "on that server, save a dated copy before a big edit, because there is nothing else to go back to".

Not Lecturing

The difference between a lesson and a lecture is not length; it is whether the message is for the reader or about them. A lecture explains what the reader should have done, cites the policy, copies the manager, and attaches the guide. It leaves the reader feeling that the rescue came with a bill. A lesson gives the reader one thing they can use, with a reason, and stops. The test is to read the message as the person who just lost eleven people's shifts and got them back. Does any sentence make them feel smaller? Cut that sentence. The general craft of telling users things without talking down to them is in Training Users Without Lecturing. The after-rescue message is its best-timed case.

Five rules keep the message on the right side of the line. Never use "should have", "unfortunately" or "as per". Never copy the manager on a lesson. The manager is copied when the organisation needs to decide something, and a rescued rota is not that. Never attach the guide; link the one page that matters, or nothing. Never add a second lesson. And never make the lesson conditional on the person's gratitude, so that the thanks feel like they bought a telling-off. The tone for a moment when the reader is still a little shaken is the same tone the desk uses in any hard moment. Tone in Hard Moments sets it out. Here the hard moment has just passed and the tone is warm, brief and useful.

Self-deprecation helps, in one clause, when it is true. "I keep a dated copy before every big edit because I once saved a blank template over a quarter's figures" is a sentence from a colleague, not a policy. It is believed in a way the policy never is. I have said that sentence more than once, and it has always been true, which is the only condition for using it.

When the Lesson Should Become Policy

A lesson sent once is teaching. A lesson sent to the same person twice is a sign that the structural fix is late. A lesson sent to twenty different people in a quarter is not a teaching problem at all. It is a desk that has chosen to send twenty messages instead of making one change. Count the lessons. Every after-rescue message carries the shape of the loss it followed. A quarterly look at those shapes, in the way Finding the Repeat Tickets describes, tells the desk which structural fix from the table is overdue. The desktop lesson sent twelve times is a redirection project with twelve tickets of evidence. The version history lesson sent eight times is a knowledge base article that nobody has found, or a share where versions are off.

The other place the lesson belongs is onboarding. Every new starter gets the three lines about where to save on their first day, with the real folder names, before any rescue has been needed. It is the one time the abstract version of the lesson is read, because the new starter is reading everything. The lesson saves the desk the rescue and the message both. The first-week guide in First-Week Support for New Starters is where the three lines go. Keep them to three, and name the folders.

And the lesson belongs in the knowledge base, as a short article per shape. That lets the after-rescue message link one page instead of explaining. The version history guide is one; "where to save and why" is another; "freeing space in your sync folder without deleting anything" is a third. Three short pages, each written once, each linked from hundreds of messages over the years. The knowledge base article does the teaching for the desk on the days the desk is too busy to write a sentence. Those days are most days.

The Follow-Up That Is Not a Nag

One message, once, at the moment of the rescue, and then nothing, unless the person asks. The desk does not send a reminder a week later, does not check whether the shortcut was used, and does not add the person to a list. The message ends with an open door: "if you want me to set the shortcut up on your other computer too, or want to see how the version history works, reply here and I will". That line turns the lesson from a broadcast into an offer. A surprising number of people take it, usually with a question they would never have raised as a ticket. If you run QuerySolv, a reply to the resolved ticket reopens it with the whole history attached. That means the question costs the person nothing, and the technician who answers can see what was rescued and why. In any tool, the way back should be a reply, not a new request.

Where the person takes the offer, do the thing and say nothing more about prevention. The shortcut set up on the second computer is its own lesson. Where they do not, the ticket closes on the confirmation and the desk moves on. Prevention taught well is light: one sentence, one reason, one open door. It is the structural fix behind it that carries the weight.

A Short War Story: The Fifty-Seven Rescues at Pinefold Accountancy

At Pinefold Accountancy, a technician called Sunita kept a tally one year of the files she had pulled back. They came from laptop recycle bins, old laptops awaiting wipe and sync client bins, for people who had saved their work to the desktop. By the end of the year the tally stood at fifty-seven. Each one was followed by a cheerful message explaining where to save and why. Nobody on the desk had proposed redirecting the desktops. That was because the rescues were quick, the messages were well received, and the number was never added up until she added it up. The fifty-eighth was not quick. It was a year-end working paper for a client, saved to the desktop of a laptop that failed on a Tuesday in the busiest week of the year. There was no bin, no history and nothing in the backup set. A partner spent about twenty hours rebuilding it from the client's records while the filing deadline moved toward him. Redirection went in across the firm over the following month, and took one technician about a week. The desktop rescue stopped being a ticket type at all. The lesson was that a lesson sent fifty-seven times is a change request wearing a friendly voice. The desk should have read its own tally in the spring.

The After-Rescue Message

The message below is the one Tom now sends on every recovery ticket, with the good news first and one lesson chosen from the table to match the loss. The bracketed parts are filled in with the person's own file, folder and situation. The lesson line is one of the six in the second block, never two. The last line is the open door. The whole message should fit on a phone screen without scrolling. If it does not, something in it is a lecture.

AFTER-RESCUE MESSAGE — GOOD NEWS, ONE LESSON, ONE OPEN DOOR
Ticket: ________   File: ______________________   Recovered from: ______________

Hi ______________,

Good news: ______________________ is back. I recovered it from
______________________ and put it at ______________________ as of
____/____ ____:____. Please open it and check the most recent change
you remember is there; if anything is missing, reply here.

[ONE lesson from the list below, in your own words, with its reason]

If you would like me to do any of these, reply to this message and I will
sort it: set up the shortcut on your other computer, show you the version
history, or make you a shared folder.

______________
Support desk

--- LESSON LINES (pick exactly one; include the reason) ---
Place:   Save it in ______________ (your team's shared folder); that folder is
         backed up every night and keeps earlier versions, and the desktop is not.
         I have put a shortcut to it on your desktop.
Version: Next time a file looks wrong, open its version history from the file's
         menu and pick the copy from before; it takes a minute and needs no ticket.
         Guide: ______________
Bin:     Deleted files sit in the recycle bin for about ______, so if something
         vanishes, look there first and tell us the same day if it is not there.
Sync:    The folder on your laptop is a window onto the service, so deleting
         there deletes everywhere; to free space, ask us to make folders online-only.
Save:    Save the file with a name in the shared folder as soon as you start, and
         the automatic save keeps a copy every few minutes from then on.
Name:    Put the date at the start of the name, year first; files then sort
         themselves and a save-as makes a new file instead of replacing this one.

Tom sent Carla the good news, the "place" lesson with the Harbor Street folder named, and the open door, in five lines. Carla replied asking for the shortcut on the back-office computer as well. Setting it up took him two minutes on a remote session, and the rota has lived in the shared folder since. Her reply is in the ticket, under the restore note, where the next technician will find it if the rota ever goes missing again. It has not. The desk's tally of desktop rescues is still kept. It is the number that will get redirection approved for the store laptops next year.

Frequently Asked Questions