Write the symptom down before you touch anything

Somebody tells you it has stopped. The reminders, the order emails, the nightly export. You open the settings and everything says on. So you switch it off and on again. You re-save the template. You reconnect the account for good measure.

By lunchtime something seems to work. Nobody knows which of the three changes did it. The error list that would have told you went when you reconnected. The change history now holds three edits with your name on them.

On Thursday it stops again. You are back on the settings page with nothing written down. Three suspects instead of one, and another week of customers who did not get what they were promised.

A symptom sheet is not a diagnosis. Not a to-do list. Not an email to the supplier saying "it's broken, please fix". It is ten lines, written in ten minutes, before your hand goes anywhere near a setting.

The rules

The symptom is a number, not an adjective. "Orders are down" is a mood. "Nine orders yesterday, against a usual thirty" is a symptom. Take the count from the system's own record: the sent list, the order list, the log. Write down which screen it came from. You will need to measure it the same way when you think it is fixed.

Find the last time it definitely worked. Not the last time nobody complained. The last record that shows it working, with a date and a time. Everything that changed between then and now is a suspect. Start with those.

"Nothing changed" is never true. Something always changed. An update installed itself overnight. A password was reset. A subscription renewed, or failed to. Somebody new was given a login. The calendar moved past a date that mattered. Write down every change you can find, and leave the list open for the ones you cannot.

Size it before you solve it. Count how many customers, bookings or orders are affected before you do anything else. That number decides who gets a phone call today. It also tells you whether this is a morning's work or a week's.

Write what fixed looks like before you start. Success criteria written after the fix get fitted to whatever happened. Written first, they are a test the fix can fail. Mark the decision point as well. If the plan dies halfway, change the sheet, not only the settings.

Do it now

1. Pick the thing that is broken today. If nothing is, pick the last thing that broke and still annoys you.
2. Open a blank document. Do not open the settings of the broken thing yet.
3. Go to the system's own record and count. Messages sent, orders received, rows exported. Count, do not estimate.
4. Find the last record of it working properly. Note the date, the time and where you saw it.
5. Fill in the sheet below, every line. Where you do not know, write unknown. Unknown is honest. A guess on this sheet becomes a fact by Friday.
6. Paste the finished sheet into a chatbot with the prompt below. Add anything it finds to the sheet.
7. Save it, with the time, somewhere your team can open. Now you may touch something.

Symptom:         <what is not happening, in one sentence, with a count>
Evidence:        <the exact screen or export the count came from>
First noticed:   <when, and by whom>
Last known good: <the last time it definitely worked, and the record that shows it>
Size:            <how many customers, bookings or orders are affected, counted>
Changed since:   <every change you can find, however small>
Goal:            <one sentence>
Steps:           <numbered, each one something you can check>
Decision point:  <the step whose answer changes the rest>
Success means:   <the number that must move, and the figure it must reach>

Here is a symptom sheet for something that stopped working in my business.
<paste the sheet>

Do not tell me the cause and do not suggest a fix.
List every line that is vague, estimated or missing a number.
Then list changes I have not considered that could stop this working:
renewals, expiry dates, automatic updates, new logins, anything on a calendar.

A worked example

Say you run a four-practitioner physiotherapy clinic. Reminder texts go out at six the evening before each appointment, sent by the booking system through a text-message service. On Thursday morning a patient rings to say she never got hers. Nadia, the practice manager, opens a blank document before she opens any settings.

Symptom:         0 of 34 reminder texts sent in Wednesday's 6pm run, all 34 marked Failed
Evidence:        booking system, Messages screen, filtered to Wednesday 18:00. No reason shown
First noticed:   Thursday 08:50, a patient phoned about a missing text
Last known good: Monday's run, 34 of 34 due sent. 2 patients had no mobile on file
Also odd:        Tuesday's run sent 12 of 33 due, then every one after that Failed
Size:            55 patients with no reminder: 21 booked for Wednesday, 34 booked for today
Changed since:   booking system updated itself Monday night. Reminder wording edited Tuesday
Goal:            tonight's 6pm run texts every patient who has a mobile number
Steps:           1 read the text service's own log. 2 send one test text. 3 fix the one link found
Decision point:  step 1. If the texts never reached the text service, the booking system is the suspect
Success means:   Thursday's 6pm run sends 35 of 35 due, 0 Failed, after a test text arrives

Eleven lines. Not one setting touched.

The failure you will hit

You will find the cause while you are writing the sheet. Or think you have. The reminder wording was edited on Tuesday, the timing fits, and your hand is already on the mouse. Finish the sheet first. A suspect that fits the timeline is still only a suspect. The success line tells you whether undoing it fixed anything, so it has to exist before you undo it.

Not for you if

If your answer to anything breaking is to ring the supplier and wait on hold, this track is not for you. It assumes you will read your own system's records before anybody else's. And if nothing in your business shows what was sent, paid or booked, fix that first. No record, no symptom.

Step two narrows the fault by halves, with a number before and after. The Vault is the paid library, and Operations is one of its categories.