Use case · Operator field guide

Give clients a decision they can approve, not three PDFs they have to decode

Options work when each path represents a real production choice. They fail when the client is asked to compare nearly identical spreadsheets with different totals.

Trace 01 · Signal → cause → consequence

Diagnose the operating failure before buying a tool

Visible signal

The client says 'go with option two' after receiving several attachments, but the team cannot tell which revision, assumptions, or exclusions that sentence refers to.

Underlying cause

The approval channel is disconnected from the estimate state. Files move through email while the underlying scenario continues to change.

Business consequence

Production begins on an ambiguous promise, revision requests become arguments, and the approved number may not match the budget the team actually uses.

Control 02 · Operating principles

Three controls that survive the software

Every option needs a production thesis

Explain the trade: fewer deliverables, a simpler location plan, a smaller lighting footprint, or more post flexibility. A lower price without a changed plan is just margin compression.

Approval belongs to an immutable version

The client decision must resolve to one scenario inside one estimate version. If the estimate changes, the old approval link should no longer represent the new offer.

Revision is a valid outcome

Let the client ask for changes without pretending they approved. Capture the request against the exact option they reviewed so the next version starts with shared context.

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

Name options by outcome

Use labels such as single-location, recommended campaign, or expanded deliverables. Internal A/B/C keys can remain, but the client should understand the operational difference immediately.

  • The recommended path is explicit
  • Each option has a one-sentence tradeoff
  • No option relies on hidden unpaid labor
02

Keep shared assumptions visible

Present dates, usage, number of review rounds, payment terms, and client dependencies beside the options. Shared assumptions should not disappear because line items differ.

  • Client-provided items are named
  • Overtime and change-order triggers are stated
  • Expiration or decision timing is visible
03

Capture the decision in one place

Use an approval surface that records the scenario key, approver, and timestamp. Email can notify people, but it should not be the database of record.

  • Only an open, valid link can approve
  • Repeat clicks are idempotent
  • The producer can see the approved state
04

Create the initial budget from approval

The approved option should seed the project and budget atomically. That eliminates the common gap where sales won one version and production rebuilt another.

  • Budget total matches approved scenario
  • Approved assumptions remain attached
  • Subsequent changes create history instead of overwriting it

Instrument 04 · Evidence

Measure whether the control is earning its place

  1. Median hours from estimate delivery to client decision
  2. Revision requests caused by unclear assumptions
  3. Approvals tied to a current, valid estimate version
  4. Approved jobs that create a matching initial budget without re-keying

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

  • Renders client-facing estimate scenarios from a secure public token
  • Records the selected option and approval state
  • Creates a project and initial budget from the approved scenario in one transaction

Design-partner scope

  • Adapt option labels and assumptions to the shop's selling process
  • Run a live client decision through the approval path
  • Identify notification, branding, and revision controls required before broader rollout

Honest boundary: The approval path is an early workflow, not a finished client portal. Design partners should validate it on selected jobs and keep their normal contract and payment controls in place.

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

How many estimate options should a client receive?

Usually two or three. One path can feel coercive and four or more creates decision work. Only add an option when it represents a materially different production plan.

Is clicking approve the same as signing a contract?

Not automatically. Treat scope approval, contract execution, and payment authorization as distinct controls unless counsel and the product workflow explicitly combine them.

Should the cheapest option come first?

Order matters less than clarity. Lead with the recommended path when you have a professional recommendation, then show the lean or expanded alternatives with honest tradeoffs.

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