Service architecture

Decision

Lead with specific service brands tied to a buyer, problem, and outcome. Use Workflow Control as the shared delivery mechanism. Sell each qualified service through the same Design, Build, and Run commercial path.

Do not ask a buyer to purchase “Workflow Control” in the abstract. A Controller buys control over billing delay. A risk leader buys control over missed workers’ compensation actions and evidence. Workflow Control explains how FZF produces those results across existing systems.

flowchart LR
    subgraph Buyer_context["Buyer and problem"]
        SBC["Staffing Billing Control"]
        WCC["Staffing Workers' Compensation Control"]
        C["Candidate workflow<br/>not yet a service brand"]
    end

    subgraph Commercial_path["One commercial path"]
        D["Workflow Design Sprint<br/>observe and specify"] --> B["Build<br/>install the control"] --> R["Run<br/>operate and improve"]
    end

    SBC --> D
    WCC --> D
    C -. "only after promotion" .-> D
    WC["Workflow Control<br/>shared delivery mechanism"] --- B
    WC --- R

Four layers, four jobs

Layer	Reader question	Current expression
Market problem	What is happening in the buyer’s language?	Billing delay, held invoices, stale work-status evidence, overdue claim actions
Specific service brand	Who buys, for what job and measurable consequence?	Staffing Billing Control, Staffing Workers’ Compensation Control
Shared mechanism	How does FZF deliver across different workflows?	Workflow Control: state, ownership, deadlines, rules, evidence, exceptions, human gates, and audit history across existing systems
Commercial path	How does the client buy and expand the work?	Workflow Design Sprint → fixed-price Build → recurring Run

Keeping these layers separate prevents two errors: generic capability copy with no reason to buy, and a collection of unrelated custom projects with no shared delivery model.

When a workflow deserves a service brand

A workflow becomes a distinct service only when all of these are specific enough to survive buyer conversations and delivery review:

1. Primary buyer: one role owns the consequence and can sponsor action.
2. High-consequence job: the work has a clear trigger, desired progress, and cost of delay or failure.
3. Measurable outcome: the buyer accepts at least one direct workflow measure and one relevant business measure.
4. Workflow boundary: the start, finish, systems, handoffs, exceptions, and retained human decisions are explicit.
5. Distinct operating language: buyers describe the problem in terms they already use; FZF does not need to create a category.
6. Credible evidence: the strongest wording is supported at the level recorded in Validation and evidence.
7. Repeatable delivery: prior components and methods can reduce future delivery effort without forcing every client into one template.
8. Commercial demand: qualified buyers will fund the Workflow Design Sprint and downstream offer path.

If a workflow fails one or more tests, keep it in the candidate register or offer it as an expansion inside an existing client relationship. Do not create a landing page or standalone sales sequence merely because FZF can build it.

Design, Build, and Run

The three stages answer different client decisions:

Stage	Decision it resolves	Output
Workflow Design Sprint	Is this workflow worth controlling, and what exactly should be built?	Current-state model, failure and exposure register, future-state control, baseline plan, acceptance criteria, and implementation decision
Build	Can FZF install the agreed control safely around the existing stack?	Working integrations, workflow state, rules, evidence, exception paths, human gates, reporting, and acceptance evidence
Run	Who keeps the control healthy and improves it as systems and client rules change?	Monitoring, rule maintenance, system-exception routing, control reporting, and an automation backlog

Run does not convert FZF into outsourced operations. The client retains its queue work and decision authority. The full line between retained control and labor is canonical in the Offer ladder.

Architecture rules

• Reuse technology, methods, and control patterns across services; do not force one market message across different buyers.
• Keep each service’s result and measures specific; do not lead with “visibility,” “AI,” or “automation” alone.
• Preserve client-specific rules where they create the value. Reuse should lower delivery cost, not erase real operating differences.
• Do not turn recurring components into a SaaS roadmap. They remain the internal core of a productized service.
• Do not replace the client’s ATS, VMS, payroll, accounting, credentialing, claims, or other authoritative system.
• Review new brands through the scorecard and rules in Portfolio prioritization.