Vendor Incident Contacts One-Pager for Small Teams

When your payment processor goes down on a Sunday morning, the fix is not in your codebase — it is in their support queue. The difference between a twenty-minute 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, verified and ready. This is that page: one row per critical vendor, eight fields, filled while it's calm, tested once, reviewed quarterly.

1. 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, the two or three tools your customers touch. Eight fields, one line:

Keep it in the repo or wiki where your runbooks live — next to the incident plan, not in someone's inbox. A contacts sheet that lives in one person's email is a single point of failure with a vacation mode.

2. Fill it while it's calm (30 minutes, total)

The numbers hide in predictable places, and every one is findable in peacetime:

• The admin dashboard → support or help section: the ticket queue, tier, and usually the direct contact block.
• The signed contract → the support schedule: SLA hours, response times, escalation names. This is the legally real copy.
• The trust center / security page → security@ address, incident disclosure contact, sometimes a dedicated hotline.
• The original welcome email from your account manager — the name that skips the queue is usually sitting in it.

Then the part everyone skips: test the path once. Send one low-stakes ticket per vendor ("quick question about our plan") and write down how long the reply took. A contact you have never tested is a guess. The test also confirms the account ID works and shows you what their queue's real response time looks like — which is often different from the SLA in the brochure.

3. The five-minute path when it's already broken

1. Status page first (30 seconds). If it's red, you just saved yourself an hour of debugging someone else's outage. If it's green and your users are broken anyway, that's a ticket-worthy incident — their monitoring missed it.
2. Tier-1 ticket, account ID pasted, facts only (2 minutes). Three lines: what's broken, when it started, what it affects. No essays — the first ticket sets the clock on your SLA.
3. Escalate on the contract's clock. No movement inside the SLA window → the escalation contact from the one-pager, quoting the SLA by name. Calm, dated, specific: "P1 opened 09:52, SLA is 4 hours, currently 4h20m without response."
4. Phone or chat for money-critical vendors. Payment rails down = phone call, not email. Voice gets a human; a queue gets a position.
5. Cross-check the world. Downdetector, the vendor's 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.
6. Post the internal note (1 minute). Who is affected, what vendor, ticket number, who owns the chase. Silence makes a technical incident a trust incident.

Paste-in ticket opener, three lines:

Account: [ID] — P1: [what is broken] since [time UTC]. Affects: [what/users/revenue]. Need: confirmation + ETA, escalation if no response within [SLA].

4. The quarterly ten-minute check that keeps it true

Contact sheets rot on a schedule you can predict: vendors get acquired, support pages move, account managers leave, plans get downgraded. Once a quarter, ten minutes:

• Every contact still replies? (The "still works" test is one low-stakes ticket per vendor.)
• Tier and SLA still what the contract says? Downgrades are quiet.
• Status page URL unchanged? Rebrands move them.
• Internal owner still at the company? Reassign on offboarding — this check belongs in the offboarding checklist.
• Any vendor added this quarter? New row before the next incident, not during it.

Stack the check onto an existing ritual — the annual ops budget review or the license register prune — so it happens without a hero.

5. The mistakes that turn 20 minutes into a lost day

• The contacts live in one person's head (or inbox). The most common configuration, and the reason a simple outage becomes a search party. The page exists precisely so any two people can run the chase.
• The account ID is unknown mid-incident. Five minutes of scrolling invoices while the queue clock runs. Paste it into the sheet the day you sign up.
• No after-hours path on the payment-critical vendor. Discovered on a Sunday is the worst time. Discover it Tuesday instead — and fix it or accept it in writing.
• The sheet was never tested. An untested contact is a guess wearing a formal outfit. One test ticket, once, converts it into a fact.
• "We'll find the number when we need it." That is not a response plan; that is a scavenger hunt with stakes. The one-pager costs thirty minutes once a year. The outage without it costs the afternoon, every time.

Worked example: the Sunday processor outage

A five-person studio, Sunday 09:40: checkout fails, their own logs clean, tier-1 chat queue showing "we are experiencing 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, found the processor's escalation contact, 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.

Takeaways

• The contact sheet is an asset, not an admin chore. It converts the first five minutes of a vendor outage from a search party into a phone call.
• Test it in peacetime or it doesn't count. One low-stakes ticket per vendor, once, with the response time written down.
• The clock you enforce is the one in the contract. SLA + account ID + escalation name on one page is what makes "we pay for support" mean something.

Related notes

• Vendor Escalation Ladder — the rungs to climb when tier-1 stalls; this page is what you climb it with.
• Vendor Outage Runbook — what to run when the vendor's service is down and yours is collateral damage.
• Vendor Security Review Checklist — the evaluation that happens before you sign; the contacts sheet is what you build from it.
• Vendor Contract Checklist — where the SLA and escalation clauses get written so the sheet has teeth.
• Payment Outage Playbook — the money-critical case where this page earns its keep fastest.
• First 30 Minutes of Incident Response — the same five-minute discipline, for your own systems.
• Incident Commander Checklist — one name owns the chase; the one-pager is in their kit.
• Software License Register — the sibling register: one row per thing you pay for, reviewed on the same calendar.
• Annual Ops Budget Template — where renewal dates live; stack the quarterly contact check onto it.

An outage at a vendor is not an excuse for a search party. One page, one row per critical vendor, eight fields — status page, security contact, account ID, SLA, after-hours path, escalation name, owner, last-verified date — 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. Teams that improvise the contact search finance the outage twice: once in downtime, once in trust.