Section B · Operating model

Working Agreement Template

The one-page document that anchors the deployment. Why it exists, what goes in it, the template itself, and the protocol for getting it signed.

Why a working agreement

Most FDE-DE deployments don't fail because the technology doesn't work. They fail because the customer and the platform team had different unspoken expectations about what would ship, when, and how it would be measured. The working agreement surfaces those unspoken expectations and writes them down.

Three forcing functions it provides:

Forces scope clarity. Writing "in scope" and "out of scope" explicitly makes the customer realize they didn't actually agree on it.
Forces success criteria. "Renewal alerts within 7 days of due date for 95% of MSAs" is testable. "Better renewal visibility" is not.
Forces escalation paths. Naming who owns what and when to escalate means you don't have to renegotiate it in a crisis.

It's not a contract — your AE owns the contract. It's a working artifact for the team running the deployment. Both sides refer back to it when something looks off.

The shape

One page. Markdown or Google Doc. Signed off by the customer's executive sponsor and your team lead. Nine sections:

Objective — one sentence, business outcome.
In scope — specific document classes, use cases, output targets.
Out of scope — what you're not doing. Equally important.
Success criteria — measurable, with thresholds.
Timeline — week-by-week first month, monthly thereafter.
Owners — both sides, including escalation routes.
Kill criteria — what triggers a pause or reshape.
Reporting cadence — Friday status, monthly leadership review.
Sign-off — names + date.

The template

working_agreement.md

# [Customer] × [Platform] — Working Agreement
Version 1.0 · Effective YYYY-MM-DD · Review monthly

## 1. Objective

One sentence. Business outcome, not technical output.

Example: "Surface upcoming agreement renewals 90 days in advance so the
procurement team can renegotiate before notice deadlines, reducing
auto-renew lock-ins."

## 2. In scope

Specific. Listed.

- Document classes: [MSA, SOW, NDA, supplier agreements]
- Source systems: [DocuSign CLM, SharePoint /contracts folder]
- Output targets:
  - Snowflake schema `prod.contract_intel.*`
  - Looker dashboards: Renewal Pipeline, Spend Coverage
  - Email digest to procurement leadership every Monday
- Time period covered: agreements active or signed within last 3 years
- Geographic scope: US + UK entities

## 3. Out of scope

What we're explicitly NOT doing.

- ERP writeback to SAP (separate Phase 2 conversation)
- Real-time / event-driven updates (daily batch is the baseline)
- Pre-2022 documents (corpus quality below SLA)
- Non-English documents (Phase 2 if value demonstrated)
- Renegotiation workflow / e-signature integration

## 4. Success criteria

Measurable. With thresholds. Per use case.

- **Renewal alerts**: 95% of MSAs flagged ≥ 90 days before their
  earliest notice deadline.
- **Extraction accuracy** (per document class, rolling 30-day audit
  on 100-document sample):
  - MSA fields (parties, effective_date, renewal_term): ≥ 95%
  - SOW fields (value, term, deliverables): ≥ 92%
  - Supplier agreement fields: ≥ 90%
- **Coverage**: 80% of in-scope active agreements ingested + extracted
  within 60 days.
- **Off-contract spend report**: ≥ 1 quarterly review consumed by
  CPO with documented action.

## 5. Timeline

### Days 1–14: Discovery
- W1: kickoff, stakeholder interviews, access requests filed
- W2: corpus reading, working agreement drafted and signed

### Days 15–30: First slice
- W3: MSA ingestion + extraction in staging
- W4: first dashboard live; customer can see output

### Days 31–60: Scale to SLA
- W5–6: onboard remaining document classes
- W7–8: integrate with Snowflake marts and Looker semantic layer

### Days 61–90: Mature
- W9–10: runbooks written and tested with customer's data team
- W11–12: joint on-call; CS picks up relationship

## 6. Owners

| Workstream                | Customer owner       | Platform owner |
|---------------------------|----------------------|----------------|
| Overall deployment        | [VP Procurement]     | [FDE-DE name]  |
| Data engineering          | [Data lead name]     | [FDE-DE name]  |
| Identity / IT             | [IT director]        | [FDE-DE name]  |
| Business analysts         | [Procurement lead]   | [FDE-DE name]  |
| Account / commercial      | [VP Procurement]     | [AE name]      |

### Escalation routes
- Technical blocker: → Platform Engineering Manager
- Commercial / scope: → AE → VP Sales
- At-risk deployment: → FDE Lead → VP CX

## 7. Kill criteria

We will recommend pausing or reshaping the deployment if:

- 30 days post-discovery, < 70% of in-scope documents can be ingested
  due to source-system constraints we cannot work around.
- Extraction quality on any priority class is below SLA after two
  full remediation cycles.
- Customer stakeholders cannot align on a single in-scope use case
  for > 3 consecutive weeks.
- A regulatory / security requirement surfaces that materially
  changes architecture (separate review path).

If any of these triggers, we'll bring options — reshape, defer,
or stop — to a joint review within 1 week.

## 8. Reporting cadence

- **Friday status doc** (every Friday by 12pm customer time)
  - What shipped, what's open, what I need from you, what I'm
    worried about, next week's plan.
- **Monday sync** (30 min)
  - Review status, surface blockers, agree on the week's targets.
- **Monthly leadership review** (45 min)
  - Customer sponsor + platform leadership; SLA status, risks,
    expansion conversation.

## 9. Sign-off

- Customer sponsor: __________________________  Date: __________
- Platform lead:    __________________________  Date: __________
- AE / CS:          __________________________  Date: __________

Anti-patterns

Vague success criteria

"Improved renewal visibility" is unsignable. "95% of MSAs flagged ≥ 90 days before their earliest notice deadline" is signable. If you can't measure it, the customer will measure it however they feel at month three.

Skipping "out of scope"

The most-skipped section. Without it, scope creep is inevitable. Customers don't think they're being unreasonable when they ask for ERP writeback in week six — they just didn't see it written down as out of scope.

Stretched-too-far timeline

"Hit all classes by week six" sounds aggressive and signals confidence. It also means slipping that milestone in week five is the deployment's first credibility loss. Pad lightly; deliver early instead.

Hand-waved owners

"Both teams will collaborate on integration." Doesn't survive contact with a missed deliverable. Name specific people, including escalation routes. Awkward to write; saves weeks later.

Missing kill criteria

Most documents don't include them because they feel pessimistic. Without them, a deployment that should die slogs on for months. Naming the kill criteria up front is professional, not pessimistic — it gives both sides permission to pause cleanly when the data is clear.

Signing protocol

Draft from your discovery synthesis (chapter 02).
Review with the customer's data lead first. They'll spot factual errors and political landmines.
Iterate. Usually two passes.
Send to the executive sponsor with a one-paragraph summary email. They will only read the doc if they care; the email is the failsafe.
Hold a 30-minute sign-off call with the sponsor. Walk through the document. Get verbal commitment on each section.
Capture sign-off in writing — email confirmation is fine; some customers want DocuSign.
Distribute to the working team. Pin it in the project channel.

Updating mid-deployment

The working agreement is a living document. It gets updated when:

Scope changes (new document class added, ERP writeback agreed).
Success criteria refined (e.g., SLA threshold negotiated up or down based on real data).
Timeline slips (be honest; don't pretend it didn't).
An owner changes (new IT director, your team rotates).

Each update bumps the version number; the bottom of the doc has a changelog with one line per version. The customer should always know which version is current. Email when a new version ships.

Don't update silently

If the customer learns about a scope change by reading version 1.3 of the doc you didn't tell them about, you've lost trust. Every update has a sentence-long announcement: "scope expanded to include German-language MSAs per request from [name]; SLA at the same threshold."

✓ Check yourself

Answer from memory before opening each one.

A draft success criterion reads "better renewal visibility". What test do you apply, and what do you write instead?

Show answer
Ask whether it has a threshold and a sample you can measure; it has neither, so the customer will judge it by feel at month three. Rewrite it as a measurable claim such as "95% of MSAs flagged at least 90 days before their earliest notice deadline". See anti-patterns.
In week six the customer asks for ERP writeback and the agreement's out-of-scope list is empty. What did that omission cost, and what do you do now?

Show answer
Without the line the customer did not see ERP writeback as unreasonable, so scope creep was unavoidable. Treat the request as a scope conversation, agree timeline and criteria changes, bump the version, add a changelog line and announce it. See updating mid-deployment.
Kill criteria are agreed on day 14, when nobody doubts the deployment. Why then, and what does a good one look like?

Show answer
Agreed early, they give both sides permission to pause without blame when the data is clear. A good one is a threshold with a time window, for example under 70% of in-scope documents ingestible 30 days after discovery. A trigger leads to options at a joint review within a week. See the template.
Describe the signing protocol in order, and say why a summary email travels with the document to the sponsor.

Show answer
Draft, review with the data lead, iterate, send to the sponsor, hold a 30-minute walk-through, capture sign-off in writing, then distribute and pin it. The email is the failsafe because the sponsor will read the full document only if they care. See signing protocol.
After two months of real data, the supplier-agreement accuracy target of 90% proves unreachable and you agree to 85%. What do you change in the document?

Show answer
Update the success criteria, bump the version number, add one changelog line and tell the customer in a sentence, such as which target moved and why. Updating silently is how a reasonable change becomes a trust problem. See updating mid-deployment.
Your AE says to drop the kill criteria because they will frighten the customer. How do you respond?

Show answer
Keep them, and change the framing. They are a professional safeguard, not pessimism, and without them a failing deployment drags on for months. Offer to word them as a pause-and-options trigger with a joint review, and let the AE own the commercial conversation around them. See anti-patterns.

Takeaway

Deployments fail on unspoken expectations, and the working agreement writes those down before work starts.
It is a working artifact for the team, not a contract; your account executive owns the contract.
It runs to one page and nine sections, signed by the customer's sponsor and your team lead.
A success criterion needs a threshold and a sample; if you cannot measure it, the customer will measure it by feel.
The out-of-scope list and the kill criteria are the two most skipped sections and the two most useful ones.
Owners are named people with escalation routes, not teams that will "collaborate".
Every change bumps the version, adds a changelog line and gets announced in a sentence.

A signed agreement only works if both sides see progress against it every week. → Cadence & Status Templates