Workflow failure · Operator field guide

An estimate version is a client promise, not a filename

Version history matters because a commercial estimate changes the work a team is authorized to perform. The system should show what changed, why it changed, and which version won.

Trace 01 · Signal → cause → consequence

Diagnose the operating failure before buying a tool

Visible signal

The team has multiple files with nearly identical names, a producer edits the current version while the client reviews an older PDF, and approval arrives without a version reference.

Underlying cause

File history is being used as workflow state. Copies record that something existed, but not why it changed or whether it remained open for approval.

Business consequence

The wrong scope can be sold, the correct scope can be produced from the wrong number, and the company has no clean evidence when a revision dispute appears.

Control 02 · Operating principles

Three controls that survive the software

Snapshot before every external decision

A client-facing revision should create an immutable snapshot. Draft edits can remain fluid, but delivery, approval, rejection, and supersession need stable states.

Version the whole decision

Line items alone are incomplete. Options, assumptions, exclusions, validity dates, notes, and client-facing context belong to the same version boundary.

Close stale approval paths

When a revision supersedes an estimate, older links must stop authorizing work. Historical access can remain read-only while approval authority moves forward.

Runbook 03 · Smallest useful workflow

Run this on one real job

Do not begin with a company-wide migration. Prove the control on representative work, record the exceptions, and expand only when the operator can trust the new state.

01

Define version triggers

Create a new version when scope, total, schedule, usage, major assumptions, or an option changes. Formatting corrections can be recorded without pretending the economic offer changed.

  • Triggers are documented
  • Client-facing delivery always points to a fixed version
  • Draft and issued states are distinguishable
02

Require a change reason

Record whether the change came from client scope, vendor information, internal correction, negotiated concession, or production discovery. The reason determines who owns the consequence.

  • Change origin is selected
  • Material amount change is visible
  • The responsible operator is recorded
03

Compare at decision level

Show changed totals, new or removed lines, assumption changes, and option changes. A raw cell diff is less useful than a concise explanation of what the client or producer needs to reconsider.

  • Added and removed scope is obvious
  • Markup or percentage effects are included
  • Unchanged assumptions remain accessible
04

Bind approval to version and scenario

Store the version, selected option, approver, and timestamp as one record. Once approved, preserve that baseline even if later changes create a new operating forecast.

  • Stale versions cannot approve
  • Approval is idempotent
  • The approved baseline is immutable

Instrument 04 · Evidence

Measure whether the control is earning its place

  1. Client decisions with an explicit estimate version and option
  2. Stale approval attempts prevented
  3. Average revisions per bid and reason distribution
  4. Time required to explain the difference between any two issued versions

Boundary 05 · Product truth

Where Production Engine fits today

The current build is strongest from company rate card through estimate, option approval, and initial budget creation. The design-partner program exists to test the next control on live work without pretending the whole production stack is finished.

Present in the current repo

  • Creates append-only estimate snapshots with version numbers
  • Stores scenarios separately from the estimate record
  • Resolves public approval tokens to one estimate and records the selected scenario

Design-partner scope

  • Define which shop changes create a version
  • Test revision and supersession behavior on live bids
  • Prioritize the comparison and notification views operators need

Honest boundary: The underlying snapshot and approval mechanisms exist, but a complete client-facing revision comparison and notification workflow remains design-partner work.

Paid design-partner program

Put one live workflow under control in 90 days.

Implementation, rate-card and workflow mapping, access for five operators, and direct product-team collaboration.

$2,500 implementation + $499/month for five operators · 90-day commitment

FAQ 06 · Buying questions

Questions to resolve before implementation

Does every edit require a new version?

No. Version on meaningful client or economic changes. Keep draft editing efficient, but snapshot before external delivery and any state that can authorize work.

Can an approved estimate still change?

The approved baseline should not change. New scope should create a revision or change record so the original promise and later decision both remain visible.

Is cloud file history enough?

It preserves file states, which is useful. It does not inherently know which version was issued, superseded, approved, or converted into a project budget.

Index 07 · Internal route

Continue the operating system

Paid design-partner program

If this failure costs real producer time or margin, test it on a live job.

Implementation, rate-card and workflow mapping, access for five operators, and direct product-team collaboration.

$2,500 implementation + $499/month for five operators · 90-day commitment