The 90-Day Plan

The four phases

The numbers shift per deployment. A small, well-scoped customer might compress to 60 days total. A large, multi-business-unit customer might run 6+ months. The phase shapes are the same.

Days 1–14: Discovery

Goals

• Map the customer's stack, stakeholders, and data reality.
• Identify the highest-leverage use case for the first slice.
• Ship a signed one-page working agreement.

Week 1

• Day 1: kickoff call with the customer's executive sponsor and data lead. Set the meeting cadence. Get access requests started (identity, sample documents, warehouse).
• Day 2: file identity / IT tickets — Okta SSO, SCIM, sample-data access. These have the longest lead time; start now.
• Day 3–4: interview the customer's data analysts, procurement / legal analysts, the executive sponsor (often three separate conversations). Use the question banks in 02-discovery-template.
• Day 5: read 20+ representative documents from the customer's corpus. Take notes on layout variance, completeness, age range.

Week 2

• Day 6–7: map their existing stack — ERP, CLM, warehouse, BI, identity. Draw a diagram. Verify with their data team.
• Day 8: run an OCR-quality preflight on a 50-document sample. Eyeball the output.
• Day 9: synthesize findings into a draft working agreement. One page. Objectives, scope, success criteria, owners, kill criteria. Use the template in 03-working-agreement.
• Day 10–12: review draft with the customer's data lead, then the executive sponsor. Iterate.
• Day 13–14: sign the working agreement. This is the milestone that closes discovery.

What you should know by end of week 2

• The five most important document classes in the customer's corpus.
• What manual workflow the platform is replacing, and how many hours per week it costs them today.
• Who at the customer signs off on the data being right.
• Where the output needs to land for the customer to act (BI dashboard? ERP? procurement suite? all three?).
• What freezes / change windows constrain when you can deploy.

Days 15–30: First slice

Goals

• Stand up ingestion for one document source.
• Run extraction against one document class with HITL.
• Land output in the customer's staging environment.
• Customer can see and act on a first useful result by end of week 4.

Week 3

• Build ingestion connector for the customer's chosen source (drop bucket, CLM API, file share).
• Configure extraction for one document class.
• Wire HITL queue with the customer's analyst capacity in mind.
• Begin landing data into a staging schema in the customer's warehouse.

Week 4

• Run end-to-end on 100–500 documents.
• Build one starter dashboard in the customer's BI tool showing extracted output.
• Walk the customer through the dashboard live. Capture corrections.
• Ship Friday status doc with "this is what you can see today" framing.

Days 31–60: Scale to SLA

Goals

• Expand to all document classes the working agreement scoped.
• Hit the contracted accuracy SLA per class.
• Wire output into the customer's downstream systems (warehouse marts, BI, possibly ERP write-back).
• Begin training the customer's data team.

Weeks 5–6

• Onboard remaining document classes one at a time.
• Calibrate HITL thresholds per class against measured accuracy.
• Start building the customer-facing SLA dashboard (extraction quality by class, HITL queue health, refresh cadence).

Weeks 7–8

• Build the mart layer in the customer's warehouse using dbt — renewal pipeline, off-contract spend, supplier rollups.
• Hand the customer's analysts the semantic layer; pair-session through how to extend it.
• Validate against the SLA on a labeled audit sample. If any class is below, contain and remediate.

Sign of phase completion

The SLA dashboard shows accuracy above contracted thresholds for all in-scope classes for at least 30 consecutive days. The customer's data team has accessed the marts independently and built at least one of their own queries on top.

Days 61–90: Mature & plan handoff

Goals

• Runbooks live, tested, and owned by the customer's team.
• On-call posture shifted from FDE-primary to joint.
• Customer success picks up the relationship for ongoing maintenance.
• Plan written for the FDE's exit and future expansion conversations.

Weeks 9–10

• Write the runbooks (see 06-runbook-templates): pipeline failure, quality alert, schema drift, backfill, new doc class, HITL queue overflow.
• Pair-test the runbooks with the customer's data team. They follow; you observe.
• Document the customer-specific extension configuration (their doc-class taxonomy, their threshold tunings, their mart definitions).

Weeks 11–12

• Transition to joint on-call. They handle first response with your runbooks; you escalate only when they can't resolve.
• Hand off the relationship to customer success. Joint introduction call.
• Write the expansion proposal — additional business units, additional document classes, deeper integration — for the AE to take into renewal.
• Ship the deployment summary doc to internal leadership: what was built, what was learned, reusable artifacts for the next deployment.

Sign of phase completion

The customer's data team has resolved at least one incident from the runbooks without paging you. Customer success has the relationship. You have a clear next-deployment.

Milestone checklist

The hard milestones, in order. If you slip past one, surface to internal leadership before slipping past the next.

• ☐ Day 14: signed one-page working agreement
• ☐ Day 30: customer can see useful output from the first slice in their staging environment
• ☐ Day 45: all in-scope document classes onboarded
• ☐ Day 60: SLA holds for 30 consecutive days
• ☐ Day 75: runbooks written, tested with customer's team
• ☐ Day 90: joint on-call active; customer success has the relationship; expansion proposal drafted

Variations per deployment

Smaller deployments (one team, one document class)

Compress to 45–60 days. Skip the multi-class onboarding phase. Heavier focus on the customer-team handoff because there's no "expansion to other BUs" to fill the time.

Larger deployments (multi-business-unit, multi-region)

Expand to 6+ months. The discovery phase often runs three weeks per BU. Stagger the first slices — don't try to ship for all BUs simultaneously. Pick a lighthouse BU, prove the pattern, then replicate.

High-stakes / regulated deployments

Add a security-and-compliance phase between discovery and first slice. SOC 2 attestation reviews, BAA / DPA execution, customer-side security questionnaires. Plan an extra two weeks; some of it lives in parallel with other phases but the calendar slip is real.

Reseller / partner-driven deployments

The partner (often a Big Four consultancy) is the customer-of-record interface. Working agreement scope changes — your customer is the partner, but the SLA holds against the end-customer's data. Trickier to navigate; the discovery phase needs to include the partner's project lead as a primary stakeholder.

✓ Check yourself

Answer from memory before opening each one.

1. On day 12 a teammate offers to build the ingestion schema now, "to save time later". What do you say, and what does each choice cost if you are wrong?

   Show answer

   Hold off. A schema drawn before the stakeholder conversations finish is usually the one you discard by week three, so the rework costs weeks. Waiting costs a few days, and discovery ends at the signed agreement on day 14 anyway. See days 1 to 14.

2. The customer wants all ten document classes in the first slice because coverage looks better in a demo. What do you propose instead, and what test does the first slice have to pass?

   Show answer

   Ship one class end to end, 100 to 500 documents, with one dashboard the customer can act on by the end of week four. Customers care about outcomes, not coverage, and a thin working pipeline beats a wide half-built one. The test is whether the customer can act on what they see. See days 15 to 30.

3. In week eight all classes are onboarded and accuracy looks good on the dashboard. A colleague says the Scale to SLA phase is finished. What evidence do you still need?

   Show answer

   The SLA must hold above contracted thresholds for 30 consecutive days on a labeled audit sample, and the customer's data team must have built at least one query of their own on the marts. Onboarding is activity; the 30-day run and the customer's own use are the outcome. See days 31 to 60.

4. The day-45 milestone, all classes onboarded, slipped by two weeks. Who do you tell, when, and what does the slip do to the day-60 milestone?

   Show answer

   Tell internal leadership now, before you slip past the next milestone. The 30-day SLA run cannot start until every class is live, so day 60 moves by about the same two weeks. Surfacing the first slip is what keeps the second from being a surprise. See the milestone checklist.

5. A customer has one procurement team and one document class. Sponsor asks for the full 90-day plan. How do you reshape it, and where does the freed time go?

   Show answer

   Compress to 45 to 60 days and skip the multi-class onboarding. Put the freed time into handoff, because with no expansion to other business units there is nothing else to fill the calendar and the customer team needs the training. See variations per deployment.

6. The customer is regulated and requires a security review and a data processing agreement. The sponsor asks you to keep the 90-day date by starting the build during the review. How do you answer?

   Show answer

   Start the paperwork on day one so it runs in parallel, but do not promise the same date. The plan adds a compliance phase between discovery and first slice, about two extra weeks, and the calendar slip is real even when some work overlaps. Building before the review clears also risks rework if it changes the architecture. See variations per deployment.

Takeaway

• The 90 days split into four phases, and each ends in something you can check: a signed agreement, output the customer can act on, an SLA held for 30 days, and an incident the customer resolved alone.
• Discovery is conversation and reading; code written before the stakeholder talks is mostly rework.
• The first slice is the smallest thing the customer can act on, not the widest coverage you can demo.
• The scale phase ends when the SLA has held for 30 consecutive days and the customer's team has queried the marts without you.
• Handoff work starts during the build: runbooks, pair sessions and the on-call shift run before the last week.
• The six milestones are ordered; when one slips, tell leadership before you slip the next.
• Dates flex by customer size and risk, but the phase shapes stay the same.

The first deliverable of the plan is a signed working agreement, and the raw material for it comes from the interviews you run in the first two weeks. → Discovery Template & Question Bank

Further reading

• Service Level Objectives — Google SRE book, 2016. How to choose indicators and set targets, the vocabulary behind an accuracy or freshness SLA.
• Implementing SLOs — Google SRE Workbook, 2018. A worked method for turning a target into something you can measure and report.
• Launch Coordination Checklist — Google SRE book, 2016. A question list a launch must answer before it ships; a model for a milestone checklist.
• Accelerating SREs to On-Call and Beyond — Google SRE book, 2016. How to bring new people onto on-call in stages, the pattern behind the shift to joint on-call.
• Add data tests to your DAG — dbt Labs documentation, accessed 2026. Tests on the mart layer, which is how you show the customer's analysts that the marts hold.