The Vendor Validation Playbook

The story behind it

A SaaS client engagement stalled five-plus weeks waiting on a vendor approval. The vendor was a phone-verification provider. The approval was for an AI-evaluation gate — a separate approval cycle from the basic account, which had passed instantly. Nobody knew that gate existed. The build sat. The client lost faith. The deal walked.

The retrospective produced a single insight: we don't fail because vendors fail. We fail because we commit to deliverables before we know whether the vendor can deliver them for THIS client's specific use case in THIS region with THIS timeline.

The playbook is the gate that would have caught the failure.

The thinking

Second-order thinking matters here. The first-order question is "does the API work?" — almost always yes; that's why we considered the vendor. The second-order question is "does the vendor onboard fast enough that the API working will translate to delivery on our timeline?"

You can validate APIs in minutes. You can't validate vendor SLAs from the homepage. Vendor approval cycles range from instant to six-plus weeks, and the difference between "instant" and "six weeks" isn't a feature flag — it's a use case, a region, a tier, a regulatory bundle. The validation has to be specific.

The framework

The five-question set

For every third-party tool the proposed solution will touch, answer all five before the deliverable enters the SOW:

1. 01. Account approval status. Does the client already have it? Can we get it? What's the approval timeline? — Catches the original failure mode.
2. 02. Regional availability. Does the vendor support the client's geography for the use case we need? — Geography blocks aren't visible from a homepage.
3. 03. API capability for the SPECIFIC use case. Not "does it have an API" but "does the API do what we need." — Vendor capabilities and deliverable requirements diverge.
4. 04. Approval / onboarding SLA. Published or empirically known. — Drives the SOW timeline. Vendor approvals run in parallel to build only if the SLA is known.
5. 05. Support responsiveness signal. Reviews, public complaints, time-to-first-response. — Predicts what happens when something breaks mid-build.

The conditional clause

Every SOW deliverable that depends on a vendor gets the same conditional language baked in: "Subject to vendor approval and capability validation for the client's specific use case in their region. Validation has been completed in Discovery; the status of each required vendor is documented in the engagement's vendor matrix. If a vendor blocks delivery during the build, we will escalate within 3 business days, propose an alternate path within 7 business days, and re-scope in writing if no resolution by 14 business days."

The clause never gets removed. If the deliverable doesn't depend on a vendor, the clause is harmless. If it does, the clause is what protects both sides.

Escalation timeline

Vendor unresponsiveness during a live engagement runs on an explicit clock. Day 3: loop the vendor's success contact or LinkedIn-warm-intro path. Day 5: activate the alternate path in parallel if one was documented. Day 7: open the re-scope conversation with the client. Day 14: formal scope amendment — deliverable removed or replaced with equivalent-value alternate work.

The timeline is in the SOW. The client sees it at kickoff. Nothing about vendor risk gets hidden.

The common-stack canon

Over engagements, validation answers compound. The vendors we touch repeatedly — WhatsApp Business API, Twilio, Plivo, Stripe, Razorpay, the major AI providers, GoHighLevel, HubSpot, Apollo, Clay, Apify, Slack, Discord, n8n — get pre-validated in a canon document. When a client picks a stack, we already know the gotchas.

New vendors get added to the canon after one validation cycle. Over time, Discovery becomes faster — not because the questions change, but because the answers for common vendors are already known.

Steal this

If you ship integrated work, three moves transfer. First: write the five-question set onto a Notion template and use it before every contract. Second: add the conditional clause to your SOW template — once. It protects every future engagement automatically. Third: start a personal canon of vendors-you-touch-often with their gotchas. After three engagements with the same vendor, the canon becomes your unfair advantage.

The playbook's power isn't the validation. It's the habit of validating before committing. The habit prevents the failure mode. The framework just makes the habit cheap.

Related

• → Fulfillment Process — where the Vendor Validation Gate fits in the engagement lifecycle
• → Prospect Flow — the pre-sale flow that surfaces vendor dependencies