Run a recovery meeting with a visible decision log

A recovery meeting needs one shared record. Without one, people leave with separate versions of who agreed to what, when evidence should arrive, or why a task exists. A visible decision log gives a customer success manager a practical way to slow down a tense discussion and capture exact agreement. The log does not decide a technical cause. The log records facts, open questions, owners, and review points from a single conversation.

Prepare before anyone joins. Read the incident record, earlier notes, and customer messages. Pull statements with a source and a time into a draft. Keep source language close to its origin. If an incident record says an alert appeared at 14:20 local time, copy the source wording. Do not turn an alert into a service conclusion. Put unresolved items in question form. “Has physical inspection occurred?” gives an owner a clear task. “Equipment failure” pretends an answer exists before evidence supports one.

Send a short agenda with the draft log. Ask attendees to bring corrections, relevant records, and names for people who control access or investigations. State why a draft exists. You want corrections before people start debating causes. A customer contact might know a shift began later than a system record suggests. A field lead might know a visitor request needs a facilities contact. Those details shape the next action, so gather them early.

Use a format everyone sees during the call. A shared document or screen share works when each row stays readable. Give every row an item, current evidence, owner, next checkpoint, and source when several records matter. The fields encourage clear language. “Inspection access” is an item. “Facilities requires visitor name” is current evidence. “Hector” is an owner. “Wednesday 14:00 local time, access status sent” is a checkpoint. One reader should understand a row without guessing why work began.

Open with a direct purpose. Say, “We will leave with one record of confirmed facts, open questions, owners, and review times. Stop me whenever wording misses your meaning.” Then read the first fact and name its source. Pause before moving ahead. Silence gives a quieter attendee room to correct a statement. A correction made during the meeting costs less than a correction after several people act on an inaccurate note.

Use four status labels consistently. Confirmed means a source supports the wording and attendees accept the wording. Pending means a named person has work to do. Unknown means no answer has evidence yet. Disputed means participants describe the same event differently. Labels keep a log from turning into an accidental verdict. When two teams give different timestamps, write both timestamps and identify each source. Assign a comparison task. Do not blend two accounts into a vague compromise sentence.

Consider a fictional recovery meeting. Hector, a network manager, says, “We met twice and still lack an owner for the fix.” Asha, the customer success manager, shares the log. Her first row says, “Service interruption reported Tuesday at 14:20 local time. Customer shift notes and incident record both refer to an event.” Hector asks whether a field visit has approval. Asha answers, “Approval status is unknown. We need a named person for approval.” Her wording keeps a missing answer visible.

The field lead says an inspection needs site access. Hector says facilities needs a visitor name by Wednesday noon. Asha enters two rows. The first reads, “Field inspection request. Owner: field lead. Checkpoint: visitor name sent to facilities Wednesday 11:00.” The second reads, “Site access confirmation. Owner: Hector. Checkpoint: access response Wednesday 14:00.” Separate rows matter. The field lead has work before Hector responds, and Hector has work after receiving a name. One combined row would hide either handoff.

A technical specialist then says a site component appears involved. Asha stops before entering a cause. She asks, “Which record supports involvement, and which question still needs review?” The specialist names a diagnostic reading and says no physical inspection has occurred. Asha records, “Diagnostic reading needs physical inspection review. Owner: technical specialist. Checkpoint: evidence update after site visit.” Hector sees a useful distinction between a reading and a finding. The group agrees customer communication will describe review status rather than assign a cause.

Broad promises need a return to observable work. A sponsor says, “We need assurance this never repeats.” Asha answers, “Today we need an investigation question and a review point. Which question deserves attention first?” The sponsor asks whether a similar configuration appears at other locations. Asha records a review task and asks who owns a comparison of configuration records. She acknowledges concern without placing an unsupported promise in a shared record.

Watch for group names in the owner column. “Operations” often hides an unfinished handoff. Ask who will speak for operations and report progress at the next checkpoint. Several people might contribute, yet one person needs responsibility for bringing an update. Watch dates too. “Friday” does not tell participants what should exist by Friday. Replace a bare date with a result: “Physical inspection notes reviewed Friday 10:00 local time.” A useful checkpoint contains an expected artifact or answer.

Absent owners need special care. Do not quietly assign work to someone outside the conversation. Record a present person who will obtain agreement from the absent owner. Name when confirmation should return. If no one has a route to agreement, mark the item unknown and state why. This prevents a task from looking settled when no person has accepted work. A visible gap often prompts a leader to bring the missing person into the next call.

Near the end, read each row aloud. Ask every owner whether the action, evidence, and time match owner understanding. When wording changes, mark the correction during the call instead of quietly replacing language later. Ask which evidence should exist before another meeting, then schedule review around available evidence. Send the log promptly. Invite factual corrections until a stated time. When a correction arrives, show what changed and name its source, so later readers see a reliable history.

Run a final row test before sharing. Hide the evidence field and ask whether an outside reader knows why an action exists. Hide the owner field and ask whether a person has agreed to move work forward. Hide the checkpoint field and ask what information participants expect next. Repair a weak row before sending. “Monitor service” fails all three tests. “Field lead sends inspection findings after Wednesday visit” gives a reason, person, and expected update.

For practice, set up a fictional service interruption with four facts and two unknowns. Ask one colleague to represent facilities, one technical operations, and one customer operations. Give facilities a visitor name deadline of Wednesday 11:00. Give technical operations a site visit at 15:00 Wednesday. Enter every statement into the shared log before discussion moves on. When technical operations describes evidence expected after the visit, write their exact words in the evidence field and set Thursday 09:30 local time as the review checkpoint.