Offer ladder
Decision
Section titled “Decision”Every engagement follows one commercial path:
- Workflow Design Sprint — decide what should be controlled and whether to fund implementation.
- Build — install the agreed control for a fixed price and defined acceptance criteria.
- Run — operate and improve the control for a flat recurring fee.
Do not sell hourly Builds, standalone SaaS, transaction pricing, queue-clearing labor, or consequential decision-making. Workflow Control is the shared delivery mechanism across all three stages.
Canonical pricing
Section titled “Canonical pricing”| Offer | Price | Commercial unit | Default term |
|---|---|---|---|
| Workflow Design Sprint | $10K–$15K | One high-consequence workflow with fixed scope | 7–10 business days; standalone engagement |
| Build | $25K–$75K | One accepted implementation scope | Fixed price; typically 6–12 weeks |
| Run — Maintain | $2.5K–$4K/month | One implemented control with limited change capacity | Annual agreement |
| Run — Operate | $6K–$9K/month | Maintained control plus rule and system-exception operations | Annual agreement |
| Run — Embedded | $12K–$18K/month | Dedicated capacity across greater workflow or response complexity | Annual agreement |
Most Run clients should fit Operate. Maintain is an entry or downgrade path. Embedded is for genuinely broader scope or committed response capacity—not a way to sell client queue labor.
Workflow Design Sprint
Section titled “Workflow Design Sprint”What the client buys
Section titled “What the client buys”An implementation-ready decision for one critical workflow, not a generic workshop or unpaid discovery phase.
| Deliverable | Decision it supports |
|---|---|
| Executive Control Brief | What problem, consequence, decision, and unresolved tradeoff matter? |
| Current-State Workflow Model | How do people, systems, waits, rules, workarounds, and exceptions operate now? |
| Failure and Exposure Register | Which failures deserve control first, based on consequence, frequency, detectability, and owner? |
| Future-State Control Specification | Which states, owners, deadlines, gates, evidence, exceptions, escalations, and human decisions should exist? |
| Metrics and baseline plan | Which definitions, sources, current values, or measurement gaps will govern the decision? |
| Implementation Decision Pack | What first release, system boundary, risk, acceptance criteria, timeline, and fixed price should be approved? |
- Scope one workflow and a defined interview, evidence, system, and validation boundary.
- The client owns the Sprint findings and editable working files.
- The Sprint is valuable without a Build. Do not make implementation the only usable outcome.
- An agreed portion of the Sprint fee may be credited toward a Build only when the proposal says so. It is not automatic.
- FZF may recommend Build, further measurement, a narrower scope, or stop.
- A Sprint does not include production implementation or an outcome guarantee.
Use the current public Workflow Design Sprint as the market-facing reference, while keeping internal commercial terms on this page.
What the client buys
Section titled “What the client buys”A fixed-price implementation of the accepted control around existing systems. The statement of work must define:
- Trigger and completion state
- Included systems, data, roles, and workflow paths
- Client-specific rules and evidence requirements
- Automated actions and human approval gates
- Exception, retry, recovery, and duplicate-protection behavior
- Security, access, audit, backup, and operational assumptions
- Measures and acceptance evidence
- Exclusions, dependencies, and change control
- Build is fixed-price and outcome-defined. Do not quote an hourly implementation rate.
- Work starts after an accepted Sprint or equivalent decision pack, signed scope, named client owner, and confirmed access plan.
- A material change to systems, workflow boundary, authority, or acceptance criteria requires a written change order or a separate Build. Do not hide change inside Run.
- The client retains ownership of its data and Sprint artifacts and receives a perpetual right to use the implementation as stated in the contract.
- FZF retains its reusable framework, components, patterns, and delivery methods.
- Acceptance proves the contracted capability and behavior. It does not by itself prove a business outcome.
Run keeps the implemented control current after go-live. It is not generic support and not outsourced execution of the client’s business process.
| Tier | Included control | Not included by default |
|---|---|---|
| Maintain | Hosting, monitoring, repair of integration breakage, and minor changes within the accepted control | New client-rule operations, SLA-based exception triage, major workflow changes, or dedicated capacity |
| Operate | Maintain plus new end-client rule encoding, system-exception triage and routing with an agreed SLA, monthly control reporting, and automation backlog management | Client queue resolution, financial or claim decisions, and major new workflows |
| Embedded | Operate plus dedicated capacity, multiple agreed workflows, or priority response | Staff augmentation, per-transaction processing, or unrestricted project capacity |
Run terms
Section titled “Run terms”- Run uses an annual agreement and a flat monthly fee within the selected tier.
- Price reflects the number and complexity of controls, systems, rule change, response commitment, reporting, and reserved capacity—not transaction volume.
- The statement of work defines support hours, response targets, contacts, environments, included change capacity, and escalation.
- Major workflow expansion returns to a scoped Build. Repeated exceptions enter the automation backlog; they do not create an open-ended labor queue.
- Monthly reporting uses stable definitions and distinguishes activity, control health, workflow behavior, and business outcomes.
Run control, not queue-clearing labor
Section titled “Run control, not queue-clearing labor”The dividing line is authority and economic shape, not whether a person is involved.
| FZF Run control | Queue-clearing labor FZF declines | |
|---|---|---|
| What is sold | A healthy, current, accountable control | People or transactions processed |
| Fee driver | Agreed control complexity and committed capacity | Headcount, hours, records, claims, invoices, or volume |
| FZF role | Monitor systems; maintain safe rules; classify and route system exceptions; preserve evidence; report; automate recurrence | Work the client’s operating queue to completion |
| Client role | Resolve business exceptions and make authoritative decisions | Transfer operating or decision authority to the provider |
| Direction of manual work | Repeated safe patterns should shrink through automation | Labor scales with volume |
FZF may own
Section titled “FZF may own”- Control and integration health
- Safe client-rule implementation within accepted authority
- Classification and routing of system exceptions to a named client owner
- Automated requests for missing system artifacts when authorized
- Recovery, audit evidence, control reporting, and the automation backlog
The client must own
Section titled “The client must own”- Ambiguous evidence and conflicting authoritative values
- Invoice revisions, credits, write-offs, resends, disputes, collections, and payment decisions
- Medical, legal, compensability, reserving, settlement, claim-closure, employment, accommodation, and safety judgments
- Client, worker, carrier, TPA, regulator, and other consequential relationship decisions
- The operating work required to resolve its business queue unless separately handled by another provider
Decision test: if the fee or staffing requirement rises directly with invoice, claim, worker, or task volume, redesign or decline the scope.
Application by service
Section titled “Application by service”| Offer | Staffing Billing Control | Staffing Workers’ Compensation Control |
|---|---|---|
| Sprint | Baseline one approved-time-to-delivery path; map client rules, evidence, holds, decisions, and recovery | Baseline one path such as injury intake, work-status follow-up, authorization aging, or packet completeness; define authority and evidence |
| Build | Install intake, validation, document matching, client rules, release, delivery, exceptions, recovery, and reporting | Install claim state, actions, alerts, documents, reporting, safe integrations, and human-review gates |
| Run | Maintain delivery rules and integrations, route system exceptions, report control measures, and automate recurring safe patterns | Maintain agreed policies and integrations, route system exceptions, report action and evidence measures, and automate safe follow-up patterns |
The service changes the workflow and measures. It does not change this commercial ladder.
Proposal checklist
Section titled “Proposal checklist”Before sending any offer, confirm:
- The opportunity passes the Sales playbook qualification rules.
- The service and claim wording match Portfolio prioritization and Validation and evidence.
- Scope, systems, data, assumptions, exclusions, client owner, and authority are explicit.
- Price is inside the canonical band or has written approval for an exception.
- The fee is fixed for Sprint or Build and volume-independent for Run.
- Measures and acceptance criteria do not imply a guaranteed business outcome.
- Run responsibilities stop at control operation and system-exception routing.