The update you owe a customer once the outage is over

Can I prove to the customer what happened without them having to trust me?

The ticket

CUSTOMER TICKET: we need something in writing about this morning

Account: Beacon Analytics (growth) Impact: resolved, update outstanding Started: the outage is over, the ticket is not

Thanks for getting it working again. I need to send something to my own leadership before end of day and I would rather forward yours than write my own version of it.

What I need to be able to answer is what happened, how long we were affected, whether any of our data is wrong now, and whether this is going to happen again next time you do maintenance. Please do not send me the engineering detail, I will not be able to use it and neither will they.

Your job

1. Write the update. The investigation is already done and the facts are given to you.
2. Say what was affected in words the customer can check for themselves.
3. Cite at least one figure, name at least one thing you eliminated, and end by committing somebody to something.

Working notes

There is no system to bring up for this one. tse start puts two files in front of you: the evidence you have to work from, and a draft that somebody else started and did badly.

Rewrite the draft, then run tse check. The grader checks the things a machine honestly can, then hands you a short list to judge yourself, because the part that decides whether this update lands is not something a linter can see.

Track

Customer communication

Time

about 30 minutes

Difficulty

Straightforward

Tier

Core

Do these first: Application loads but customer data does not

Start it

In a Codespace or a local clone:

tse start communication/01-the-update-you-owe-after-an-outage

That provisions the broken system and prints the ticket above. Investigate with ordinary tools, then run tse check.

Investigation scratchpad

Saved in this browser as you type. Nothing is uploaded. 0 of 7 filled in.

1. Customer symptom

In their words, not yours. Include scope and urgency.

2. Prediction

Before running anything: target layer, expected output, two likely causes.

3. Evidence gathered

The command or query, and why it is safe to run here.

4. Confirmed / disproven / still unknown

Three separate lists. This is the step people skip.

5. What it proves

One proof sentence, one safe next step, one alternate hypothesis.

6. Customer update and escalation note

Plain language. Impact first. No blame, no speculation.

7. Recall

One gap, one command to repeat tomorrow, one confidence score.

Copy as markdownClear

Hints

Each hint gives away a little more. Try to spend a few minutes on your own evidence first, because the recall is what makes it stick.

Hint 1 of 3

Read the draft you were given and ask who it was written for.

It is not wrong about the facts. Every technical claim in it is true. It is written for somebody who already knows how the system is put together, and it is being sent to somebody who has told you plainly that they cannot use that.

The customer asked four questions in their ticket, and they are the outline:

1. What happened, in terms they can repeat to their leadership.
2. How long they were affected.
3. Whether their data is wrong now.
4. Whether it will happen again.

The draft answers roughly half of one of them.

Start from what they could not do rather than from what broke. Those are different sentences, and only the first one is checkable by the person reading it. "The customer list would not load for 47 minutes" is something they can verify against their own logs. "The connection setting was wrong" is something they have to take on faith.

Hint 2 of 3

Everything you are allowed to say is in evidence.md, sorted into the things the update needs.

The four moves, in the order they usually work:

Move	Why it is there
Name the workflow and the duration	It is the only part they can check without trusting you
Say what caused it, at their altitude	They have to repeat this to somebody else
Name what you ruled out	Usually their real worry, and it is not in their ticket
Commit somebody to something	Without this, the message ends and nothing happens

The third one is the one people skip. The customer did not ask "was our data changed", but it is the question underneath their ticket, and answering it before they ask is most of what makes an update feel competent rather than defensive.

On the fourth: "we will look into it" is not a commitment, because nobody owns it and nothing has a date. "I will send you the outcome by Friday" is one.

One more thing worth getting right. You have a real fact available about how this reached them, which is that a maintenance step was able to make the change without anyone catching it. Saying so is uncomfortable and it is the sentence that stops them asking whether it will happen again.

Hint 3 of 3

Run the grader on the draft as it stands and read what it names:

tse check

It fails all six, and each failure tells you the specific thing to add. Work down them in order. The two that most drafts still fail on a second attempt:

Internal vocabulary. The starting draft names four things the customer cannot act on. Every one of them invites a question you then have to answer instead of closing the ticket. Say "the address our application uses to reach the database" rather than naming the setting that held it.

The ending. The grader is looking for a commitment, and it is looking in the last few lines because that is where the reader looks. A sentence that begins "I will" or "we have" and carries a date or a named thing will satisfy it. So will asking them for something specific.

A structure that passes and reads well:

What could not be done, for whom, for how long.
What caused it, at their altitude, and what you did about it.
What you ruled out, stated plainly because it is their real question.
What you are doing about the cause, who owns it, and by when.
What you want from them, if anything.

Around 200 words. If you are over 260 the grader will say so, and it is usually the second paragraph that has grown an explanation nobody asked for.

Solution

Write your customer update before you read this. Comparing your wording against the model answer is worth more than reading it cold.

Reveal the solution

Solution: the update you owe after an outage

What the evidence proved

There was nothing to investigate here, which is the point. The facts were handed to you in evidence.md and the exercise is entirely about what you do with them.

Rule	What it is really asking
States the impact in the customer's terms	Can they check your first sentence without trusting you
Cites a specific figure	Is there anything behind the reassurance
Names something ruled out	Did you answer the question underneath their ticket
Ends with a next step and an owner	Does anything happen after they read it
Uses no internal vocabulary	Are you writing to them or about them
Is the right length	Will they read to the end

The starting draft failed all six, and it was factually correct throughout. That gap is the whole lesson: being right about the system and being useful to the customer are separate achievements.

Root cause

The draft was written at the wrong altitude for its reader.

It named the setting, the kind of setting, and the value it had been given. All true, none of it usable by somebody who told you plainly they would be forwarding this to their leadership. What it never said was what the customer could not do, for how long, or what happens next.

Scoped fix

Rewrite labs/communication/_stack/customer-update.md so that:

• The first sentence names the workflow and the duration.
• The cause is described at the customer's altitude, not the system's.
• At least one eliminated cause is stated out loud, particularly their data.
• The last paragraph commits a named person to something with a date.

Then:

tse check

Customer update

This is the artifact, so here it is in full:

Hi Dana,

Your customer list was failing to load for all users between 08:14 and 09:01 this morning, a total of 47 minutes. Any page that did not read customer records kept working normally throughout, which is why the outage looked partial from your side.

The cause was a configuration change made during last night's maintenance window. It changed the address our application uses to reach the database that holds your customer records, so those requests could not complete. We have corrected the address and confirmed the customer list is loading again.

Two things I want to state plainly, because they are the questions I would be asking. There was no change to your data: no data was lost and nothing was altered. And this was not caused by anything on your side, so there is nothing for your team to undo or reconfigure.

I am raising the change itself internally, because a maintenance step should not have been able to make this edit without it being caught before it reached you. I will send you the outcome of that review by Friday. If you see any other page still failing in the meantime, send me the page name and I will check it against the same setting the same day.

Engineering escalation, if you needed one

You do not, for this one. The incident is closed and the fix is in. What the update commits you to is a separate piece of work, and communication/02 is where you write that.

Check your understanding

Three questions on what the evidence here proved, and what it pointedly did not. Wrong answers explain themselves, and so do right ones.

tse quiz

Check your understanding

Three questions on what the evidence proved and what it did not. Every answer explains itself, including the right one.

Question 1 of 3The draft you were handed was factually correct in every claim it made, and it still failed. What was wrong with it?

• It described the system instead of describing what the customer could not do
• It was too informal for a business account
• It should not have admitted the change came from maintenance
• It needed more technical detail to be convincing

Question 2 of 3The customer never asked whether their data had been altered. Why does a good update answer it anyway?

• Because a longer update signals that the incident was taken seriously
• Because it is the question underneath the ticket, and leaving it unanswered means they raise it themselves a day later
• Because support is required to state it for compliance reasons
• Because it fills space that would otherwise need technical detail

Question 3 of 3The grader checks six rules and then prints a checklist it explicitly does not score. Why is that split worth having?

• Because the unscored items are optional extras for people with spare time
• Because grading them automatically would be slower
• Because a rubric that claimed to score tone would be trusted for a judgment it cannot make
• Because the checklist changes for every exercise

3 questions, none answered yet.

Why this one exists

A customer update is an argument, not an apology. It states what was affected in terms the customer can check, cites at least one figure, names what was eliminated, and ends by committing somebody to something.

In an interview

Support rounds almost always include a writing prompt, and it is scored more harshly than candidates expect. The reason is that a customer update is the only artifact of the incident most of the company will ever read. Being able to state impact, evidence and a next step in under 300 words is a skill that is visible immediately and cannot be faked.

Commands introduced

• tse check

Evidence layers

• the written update