Enterprise workflow

Suppliers knew the real scope. Buyers still owned the contract.

At $8B in annual spend and 800,000+ contracts a year, contract scoping actually lived in Excel files emailed back and forth — and Scopeworker had quietly become a transcription layer, adding 1–2 weeks before work even began. I re-architected contract creation so suppliers author scope from on-site reality, while buyers keep approval and control.

My role
PM — strategy, product decision, rollout
Scale
$8B spend · 800K contracts/yr
Adoption
~60% moved

The strategic bet was to separate authorship from authority: let the people with ground truth — suppliers on site — write the scope, while the paying customer keeps approval, compliance, and downstream control. That single move aligned the system to how work actually happens without shifting any power, and let the platform replace Excel as the system of record instead of competing with it.

$8B
annual contract spend running through this flow
~60%
of contracts moved to supplier-led authoring
1–2 wks
of scoping cycle, before work even began — cut sharply
Excel → SoR
the platform became the single source of truth
Context

The contract is the atomic unit — and creating one was the bottleneck

Scopeworker is the enterprise ERP US telecom operators like T-Mobile and Samsung use to run field execution for network build and maintenance. A contract is the core execution unit: it defines what work happens at a site, how it's done, and what the supplier gets paid, then rolls up into POs, invoices, and close-out packages.

At the time of this project, one thing was throttling an otherwise scalable platform: creating those contracts. Over 800,000 are created a year — north of $8B in spend. The prime client was T-Mobile, the largest US operator.

The problem

The platform had become a transcription layer

By design, contract creation was buyer-led: buyers defined the scope of work in the platform and issued contracts to suppliers. In reality, that's not how the work happened.

Suppliers were the ones visiting sites, assessing on-ground conditions, and determining what actually needed doing — and none of that was captured directly in Scopeworker. Suppliers shared findings in Excel files over email, which buyers then manually re-typed into contracts.

Ground truth
Supplier assesses the site
Knows what the job actually requires — but has nowhere in-platform to say so.
Off-platform
Scope lives in an Excel file, emailed over
Multiple versions circulate with no clear owner; context gets lost or misread.
Manual
Buyer transcribes it into a contract
Weeks of reconciling inputs before a contract can even be issued.
Result
1–2 weeks gone, before execution starts
Scopeworker records the outcome — it isn't the source of truth.
The real failure

The system of record was an Excel file in someone's inbox. The platform wasn't where scoping happened — it was where scoping got re-typed after the fact. Every contract started with delay and information loss baked in.

Why it was hard

This challenged a core assumption, not just a workflow

Fixing it meant touching who does what — which is exactly the kind of change that fails on adoption if you get it wrong.

  1. Shift authorship without shifting authority. Suppliers needed to define scope, but buyers were the paying customers and had to stay in control. Anything that made buyers feel sidelined would die on adoption.
  2. Replace Excel without breaking habits. Excel worked because teams knew it cold. The problem wasn't the grid — it was versioning, ownership, and auditability. We had to replace it as the system of record while keeping the familiarity.
  3. Cross-organization collaboration. Multiple users across buyer and supplier orgs editing one scope meant real version control, conflicting edits, approval states, and audit trails.
  4. System integrity across integrations. Scopeworker fed other enterprise systems. Buyer-specific validations and downstream requirements still had to hold — even when a supplier authored the data.
The decision

Separate authorship from authority

I evaluated three approaches. Two of them treated symptoms:

The options on the table
Option A
Improve buyer tooling and templates. Faster transcription is still transcription — the ground truth still starts off-platform.
Option B
Add better commenting and collaboration to the existing buyer flow. Smoother, but buyers still author what suppliers already know.
Option C ✓
Invert it. Suppliers initiate scope from on-ground assessment; buyers remain the final approvers; approved quotes explicitly convert into contracts and POs.

Option C is the only one that aligns the system with reality without moving power. Here's the shift, made explicit:

✕ Before · misaligned
Ground truth
Supplier (on site)
Authors scope
Buyer — by transcribing
Approves
Buyer
System of record
Excel + email
✓ After · aligned
Ground truth
Supplier (on site)
Authors scope
Supplier — directly
Approves
Buyer — final authority
System of record
Scopeworker

Only one row changes — who authors. Authority, approval, and compliance stay exactly where they were. That's the whole reason it was adoptable.

What we built

We didn't move Excel in. We replaced it.

1 · Collaborative, spreadsheet-like authoring

An in-platform, table-based authoring experience that felt like the tools teams already used — so structure and familiarity survived the move into a governed system. It also carried context Excel never could, like structured line-item information.

Illustrative reconstruction · in-platform scope authoring, not a product screenshot
Line itemQtyUnitRateAmount
Foundation pour — tower base1ea$8,200$8,200
40ft crane rental2day$1,450$2,900
Antenna install crew — 3 sector1crew$3,400$3,400
Fiber pull — 400m400m$6.50$2,600
authored by supplier pending buyer approval total  $17,100
The supplier builds the scope line by line, in the system — no email, no re-typing. The buyer reviews the exact same object they'll approve.

2 · Controlled collaboration and versioning

Multiple users across both organizations could edit one scope, with every change tracked, attributable, and auditable — and an email notification whenever a new version was published. Buyers kept final approval authority throughout.

Illustrative reconstruction · version history & approval state
v3Published by supplier · added crane day + fiber runawaiting buyer
v2Edited by supplier · revised foundation qtysuperseded
v1Initial scope by supplier · from site assessmentsuperseded
↳ on approve, v3 converts into a contract + PO — one explicit, auditable step.
The thing Excel never had: one owner per version, a clear trail of who changed what, and an unambiguous approval gate.

3 · Buyer-specific validations

The subtle part: I decoupled who creates the data from whose rules apply. Buyer validations kept running against supplier-authored scopes, so compliance and downstream-system compatibility held even though the author had changed.

Authored by
Supplier
↓  buyer's rules still run
Validated against
Buyer's compliance + integration requirements
Result
A compliant contract, whoever typed it
Execution

Shipped on existing rails, rolled out incrementally

The goal was never feature completeness — it was making Scopeworker the real system of record, fast, without a risky big-bang.

Outcome

From transcription layer to single source of truth

~60%
of contracts moved to the supplier-led flow
~480K
contracts a year now authored this way
In-platform
all scoping communication, off email

Contract creation cycles dropped sharply, buyers gained earlier visibility and clearer control, and suppliers became first-class participants instead of email attachments. Scopeworker went from recording contracts after the fact to being the place they're actually created.

Second-order effects

  • Cut the dependency on email and manual follow-ups across two organizations.
  • Improved trust between buyers and suppliers — shared, attributable scope instead of dueling spreadsheets.
  • Created the foundation for downstream automation.
  • Opened a new revenue stream for Scopeworker — the supplier-side product that this made possible. See case 03 →
Key takeaway

Good enterprise products don't enforce the ideal process — they adapt to how work actually happens, while preserving control, accountability, and trust. The win here wasn't a slicker form. It was designing the system around reality instead of the org chart.

What I'd pin down next

The adoption number is hard and clear (~60%). The cycle-time win I can describe but not yet quantify to the day — the version of this story with a precise before/after on scoping cycle time is the stronger one, and that's the first thing I'd instrument on a re-run.

← Supplier monetization Next: A weekend PR, 300+/day →