Your payment processor goes down on a Sunday morning. Checkout fails. Your logs are clean. And the first thing the support engineer asks — before they can even look at your ticket — is your account ID. If finding that number takes five minutes of scrolling invoices, you have already lost the first hour of your weekend.
The difference between a twenty-minute vendor incident and a lost afternoon is almost never technical skill. It is whether the right human at the right vendor gets reached in the first five minutes. That only happens if you already have their emergency contact, your account ID, and your contract's response-time promise on one page.
This is that page. One row per critical vendor, eight fields.
The eight fields every critical vendor gets
One row per vendor that can stop revenue or stop work — your payment processor, your hosting, your SSO, your email. Eight fields:
- Status page URL — the first check: is it them or is it you? Thirty seconds, no login.
- Incident / security contact (email AND phone) — tier-1 chat queues melt exactly when everyone else's does. A direct escalation address cuts the line.
- Account / customer ID — the first thing every support engineer asks for. Hunting for it mid-outage costs minutes you don't have.
- Plan tier + support SLA — "we pay for 4-hour P1 response" turns a vague wait into a clock you can enforce.
- After-hours path — outages don't respect business hours. If the answer is "none", that's a finding, not a field.
- Named escalation contact (account manager) — the person whose inbox skips the queue. On paid tiers it's usually free for the asking.
- Internal owner + backup — who calls. If the owner is on a flight, the backup needs the same page.
- Last-verified date — a contact list nobody has checked in a year is a wish list.
Keep it in the repo or wiki where your runbooks live. A contacts sheet that lives in one person's email is a single point of failure with a vacation mode.
Fill it while it's calm (30 minutes, total)
The numbers hide in predictable places: the admin dashboard's support section, the signed contract's support schedule (the legally real copy), the vendor's trust center / security page, and the original welcome email from your account manager.
Then the part everyone skips: test the path once. Send one low-stakes ticket per vendor and write down how long the reply took. A contact you have never tested is a guess — and the test shows you what their queue's real response time looks like, which is often different from the brochure SLA.
The five-minute path when it's already broken
- Status page first (30 seconds). If it's red, you just saved yourself an hour of debugging someone else's outage.
- Tier-1 ticket, account ID pasted, facts only (2 minutes). What's broken, when it started, what it affects. The first ticket sets the clock on your SLA.
- Escalate on the contract's clock. No movement inside the SLA window → the escalation contact, quoting the SLA by name. Calm, dated, specific: "P1 opened 09:52, SLA is 4 hours, currently 4h20m without response."
- Phone for money-critical vendors. Payment rails down = voice, not email. Voice gets a human; a queue gets a position.
- Cross-check the world. Downdetector, their community forum, a search of their name in the last hour — if fifty other companies are posting, you have scope evidence for your own comms.
- Post the internal note (1 minute). Silence makes a technical incident a trust incident.
Paste-in ticket opener:
Account: [ID] — P1: [what is broken] since [time UTC]. Affects: [what/users/revenue]. Need: confirmation + ETA, escalation if no response within [SLA].
The quarterly ten-minute check
Contact sheets rot on a predictable schedule: vendors get acquired, support pages move, account managers leave, plans get quietly downgraded. Once a quarter, ten minutes: every contact still replies? SLA still what the contract says? Status page URL unchanged? Internal owner still at the company? Any vendor added this quarter — new row before the next incident, not during it? Stack the check onto your license-register or budget review so it happens without a hero.
Worked example: the Sunday processor outage
Five-person studio, Sunday 09:40: checkout fails, tier-1 chat showing "higher than usual volume" — at the same time as everyone else's. Because the studio kept the one-pager, the founder did not debug: he opened the sheet, pasted the account ID, sent the three-line P1 quoting the contract's 4-hour SLA, and posted the internal note at 09:52. An engineer called back in 38 minutes. Total incident: about two hours, with the customer-facing "payments are temporarily delayed, no action needed" message sent before the coffee went cold.
The contrast case is the same studio a year earlier: no account ID, no escalation name, ninety minutes lost to a chat queue before anyone thought to check whether the outage was even theirs.
The full checklist is free
The ops-notes page has all eight fields, the fill-it-while-it's-calm sources, the five-minute path, the paste-in P1 opener, and the quarterly verify — plus crosslinks into the vendor escalation ladder, vendor outage runbook, vendor security review, and payment outage playbook. Free, no signup.
If you want the printable version, the Hive80 Lab ops kits bundle the incident and continuity checklists as instant downloads — the First 30 Minutes card is free, and the full Ops Mega Bundle ($29) covers the whole incident-response stack.
An outage at a vendor is not an excuse for a search party. One page, eight fields, filled while it's calm, tested once, reviewed quarterly. Small teams that can reach the right human in five minutes turn vendor outages into a two-hour footnote.
Top comments (0)