Customer Embedding

The four deployment stages

A typical FDE deployment moves through:

1. Discovery (week 1–2) — meet the team, learn the data, surface the unwritten requirements, write a working scope.
2. First slice (weeks 2–4) — ship the smallest end-to-end useful thing. Ingest one source, extract from a representative sample, post results somewhere the customer can see them.
3. Scale to SLA (weeks 4–10) — expand coverage, hit quality targets, integrate with the customer's downstream stack (warehouse, ERP, BI).
4. Handoff (weeks 10+) — knowledge transfer to customer team or customer success, runbooks, on-call protocol, sunset of FDE involvement (often gradually).

Loops test all four. Most rounds focus on stages 1 and 2.

Discovery week

The single highest-leverage week of the deployment. Done well, it sets up everything else. Done poorly, you spend months building the wrong thing.

What you do

• Read their contracts — at least 20, varied. You can't model what you haven't read.
• Talk to the people who use the data today — usually procurement analysts, finance ops, paralegals. Ask what question they wish they could answer in 30 seconds.
• Talk to the people who'll consume your output — often a different group. Sometimes a VP who saw a demo and signed the contract. Their definition of success matters more than the analyst's.
• Map their existing stack — ERP, CLM, warehouse, BI, identity. Where do contracts live today? Where would extracted data need to land for them to act on it?
• Find the friction — what manual process is the platform replacing? How long does it take today? That's your baseline.

What you don't do

• Don't write code yet. Code in discovery week is almost always rework.
• Don't promise outcomes. You don't know yet what's feasible.
• Don't make architecture decisions. The data shape will surprise you.

Scoping & the working agreement

By end of week two, you should have a written working agreement with the customer. Not a contract — a one-page doc the team can refer to. It includes:

• The objective — one sentence, business outcome, not technical.
• What's in scope — specifically: which document types, which use cases, which downstream consumers.
• What's explicitly out of scope — the things you'd otherwise be asked to do. Naming them avoids scope creep three weeks in.
• Success criteria — measurable, not vibes. "Renewal alerts firing within 7 days of due date for 95% of master service agreements" is good. "Better renewal visibility" is not.
• Timeline with milestones — week-by-week for the first month, monthly thereafter.
• Who owns what — both sides. Including escalation routes.
• Kill criteria — what conditions would trigger a pause or pivot.

The senior move

Get this in writing, signed off by the customer's senior stakeholder. Not because of contract enforcement, but because the act of writing it surfaces the disagreements. Customers say "yeah, we agreed on X" until you write X down and they realize X was actually X-prime.

Weekly cadence

A working FDE deployment has a rhythm:

The Friday status doc

Five sections, fits on one screen:

1. What shipped this week. Concrete artifacts. Not "made progress on X" — "extraction quality on supplier contracts moved from 78% to 91% accuracy; the pipeline is now reading 800 more docs."
2. What's open. The 2–3 things in flight.
3. What I need from you. Explicit asks. Decisions, access, approvals. If there's nothing, say so.
4. What I'm worried about. Honest. If the SLA is at risk, say so now. If the timeline is slipping, name it.
5. Next week's plan. One paragraph.

Kill criteria

Underrated FDE muscle. A deployment that should be killed but isn't burns your time and damages the platform's reputation. Conditions worth a candid kill conversation:

• The customer's data isn't what they said it was. Three weeks in, you realize 80% of their "contracts" are actually unsigned templates and amendments without parent agreements. The platform can't deliver the promise.
• The customer's stakeholders disagree internally about what success looks like. You can't ship into political stalemate. Either escalate to your AE / leadership or pause.
• The integration the customer needs requires platform-team work they aren't going to prioritize. Don't pretend you'll work around it forever.
• The original signed scope was for a use case the customer no longer cares about. They've moved on; you should too. Reshape the deployment or stop.

How to kill cleanly

1. Surface the diagnosis privately to internal leadership first. Not surprise the customer.
2. Bring the diagnosis to the customer with data. "Here's what we've learned over the last N weeks. Here's why we don't think the original objective is the right one. Here are three options."
3. Offer alternatives. Reshape the deployment, hand back, push to platform team. Don't just announce a stop.
4. Document what was learned. The next FDE deployment at a similar customer should benefit from this one's mistakes.

Escalation paths

Three escalation lanes, used differently:

Platform escalation (technical)

For "the platform doesn't do X and we need it to" or "extraction quality on this layout class is structurally bad." Escalate to platform engineering or product PM with a customer-evidence-backed write-up: which customer, which document, what we observed, what we tried.

Commercial escalation (account)

For "the customer wants something out of contract scope" or "the customer is dragging their feet on access we need." Escalate to your account executive or customer success manager. They own the relationship contractually; they should drive the conversation.

Leadership escalation (strategic)

For "this deployment is at risk of failing" or "this customer is becoming a reference risk." Internal leadership needs to know early. The worst time for them to learn is during a renewal call.

Handoff

A successful deployment doesn't keep the FDE forever. The handoff motion:

• Runbooks. What to do when the pipeline breaks, what to do when an extraction class regresses, who to call.
• Customer-team training. Their data team should be able to add new document types, debug pipeline issues, run basic queries against the data layer.
• Customer success transition. A CSM picks up relationship management; you stay available for technical escalations.
• FDE-light maintenance. Quarterly check-ins, not weekly. Available for incidents.

Doing handoff well is what lets you take on the next deployment. It's also what makes the customer renewable: they shouldn't feel abandoned, but they shouldn't be dependent either.

Interview probes