Write the incident matrix before the first P1.
The proposal says you'll be supported after launch. Then the first serious incident hits and it turns out "the team" doesn't answer a phone. People in named roles do, and the time to write those names down is before the bad hour.
After launch, coverage is real only when a matrix names who owns each severity, who may change production, who speaks to customers, and what evidence proves those roles are staffed. Extend partnership language into that matrix before the first P1—not after.
A partnership sentence is not coverage
The proposal says you will be supported after launch. The contract names a response time. Then the first serious incident happens and the room discovers that "the team" does not answer a phone. Teams do not. People in roles do.
Write the coverage down as a matrix before you need it. Severity, who owns the clock, who may change production, who speaks to the customer, and what artifact proves those roles are real.
Fill the matrix for the bad hour first
Use plain language.
P1. Customers are stopped, or the state is unsafe. Someone responds now.
P2. A major degradation, or an internal operation is blocked. Same day.
P3. There is a workaround. It can be scheduled.
P4. Minor. It can wait.
For P1 and P2, name a primary and a backup. Name who may deploy, flip a flag, or edit production data. Name who is allowed to tell customers what is happening. Name the evidence that this is staffed: an on-call roster, a drill date, an access list, the last postmortem.
If a cell says "the team," rewrite it. If your partner can help but cannot touch production, say that in the matrix. Surprise access during an incident is not a plan.
How the work moves
Fill the ownership matrix for each severity
- Define severities
Write P1–P4 in plain language tied to customer and ops impact.
- Name owners
Primary, backup, and customer voice for each severity.
- Bound change rights
Who may alter production during the incident.
- Attach evidence
Roster, drill date, access list, or postmortem proof.
A support paragraph is not an on-call roster.
Who may change production is half the incident
Diagnosis can be wide. Many people can read logs. Change should be narrow. One named role may deploy or edit live data, and they write down what they did.
Incidents get worse when everyone can act and nobody can undo. Separate those two rights on the page, before the night you need them.
Evidence, not intent
A clause that says you will respond is intent. A roster with names, a channel, and a date you last practiced is evidence.
Re-read the matrix when people change. A backup who left three months ago is not a backup. Put the page next to the partnership language, not in an appendix nobody opens.
If you cannot show the evidence, do not describe the coverage as real. Describe it as a promise you have not tested.
Decision guide
Promised coverage vs evidenced coverage
| Consideration | Evidenced | Only promised |
|---|---|---|
| Owner | Named role on a current coverage calendar. | “The team will respond” with no roster. |
| Change rights | Documented who may deploy or edit production. | Anyone technical may “just fix it.” |
| Backup | Explicit handoff when primary is unavailable. | Hope that someone else sees the alert. |
| Proof | Dated drill or inspectable access list. | A support paragraph in the proposal. |
Put this into practice
Draft P1 and P2 this week. Attach the roster or the drill date. Rehearse one incident with the primary and the backup in the room. Treat a missed rehearsal the way you would treat a missed backup: as a hole, not as a scheduling detail.
When the gap is who owns the running application, that conversation belongs with web applications.
Related work: Sutton Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.