Strategy & Systems Design
Future-state design: design the states, not the screens
Automated steps, same stalled process
It's easy to automate steps one at a time: generate the invoice, send the email, post the payment. The process around them stays exactly as hard to run. Cases still sit between steps, and nobody can say whether a job is waiting on photos, on the manager, or on nothing at all.
Designing the future state means deciding the states first. Each case is always in exactly one of them, each state has an owner, and each way out of it is written down. The normal path is the easy part; the design earns its keep on the exceptions.
Four parts of every transition
Trigger
What moves the case
An event, a decision or a deadline: photos attached, approval given, 30 days unpaid.
Information
What it needs first
The fields that must be present before the change can happen. Missing information is its own state, not a failure.
Action
What happens
Create the invoice, send it, notify finance. Explicit enough to build and to test.
Owner
Who answers for it
The system for rule-based changes; a named role for judgment. Nobody is “the team”.
The close-out, as states
| Change | Trigger | Needs | Action | Owner |
|---|---|---|---|---|
| Completed → Checked | Technician marks the job complete | Photos, parts used | Check the job is complete | System |
| Completed → Missing info | Photos or parts missing | — | Ask the technician; remind after 2 hours | System, then technician |
| Checked → Needs approval | Total over $2,500, or a discount applies | Total, service-plan status | Request approval with a summary | Operations manager |
| Checked or approved → Invoiced | Checks pass, or approval given | Approved total | Create the invoice in accounting | System |
| Invoiced → Sent | Invoice created | Customer email | Send the invoice and record it | System |
| Sent → Overdue | Unpaid after 30 days | — | Notify finance, start reminders | Finance |
| Sent or overdue → Paid | Payment recorded | Payment | Close the job, update reporting | System |
Completed → Checked
- Trigger
- Technician marks the job complete
- Needs
- Photos, parts used
- Action
- Check the job is complete
- Owner
- System
Completed → Missing info
- Trigger
- Photos or parts missing
- Needs
- —
- Action
- Ask the technician; remind after 2 hours
- Owner
- System, then technician
Checked → Needs approval
- Trigger
- Total over $2,500, or a discount applies
- Needs
- Total, service-plan status
- Action
- Request approval with a summary
- Owner
- Operations manager
Checked or approved → Invoiced
- Trigger
- Checks pass, or approval given
- Needs
- Approved total
- Action
- Create the invoice in accounting
- Owner
- System
Invoiced → Sent
- Trigger
- Invoice created
- Needs
- Customer email
- Action
- Send the invoice and record it
- Owner
- System
Sent → Overdue
- Trigger
- Unpaid after 30 days
- Needs
- —
- Action
- Notify finance, start reminders
- Owner
- Finance
Sent or overdue → Paid
- Trigger
- Payment recorded
- Needs
- Payment
- Action
- Close the job, update reporting
- Owner
- System
Every row answers a question discovery raised. The service-plan discount became a rule with an approval step; missing photos became a state with a reminder; unpaid invoices got an owner.
Where software stops
Does on its own
- Checks the job has photos and parts
- Creates and sends invoices under $2,500
- Sends payment reminders on schedule
- Updates the job and reporting when paid
Asks a person
- Invoices over $2,500 or with a discount
- A disputed invoice
- A job reopened after it was invoiced
Never does
- ✕ Changes a price or applies a discount by itself
- ✕ Writes off an unpaid invoice
- ✕ Edits a payment record
Done means
Acceptance criteria are written before anything is built. They decide the order of the work and tell everyone, including us, when the redesign is finished.
Acceptance criteria · job close-out
- Completes
- every job reaches Paid or a named exception state
- Visible
- anyone can see a job's state and owner
- Repairable
- a failed step can be retried from where it stopped
- Measured
- time from Completed to Sent, and how many jobs need approval
- Owned
- each state and rule has a named owner
What design hands off
In
Out
Worth doing before you build
Good fit
- A process is being redesigned across people and systems.
- You're about to choose an automation tool or commission software.
- Cases regularly stall and nobody can say where.
Not the right fit
- Nobody has looked at how the work runs today; start with discovery.
- A single, contained task with no states or owners to speak of.
Questions about future-state design
Is this the same as drawing a to-be process map?
It goes further. A to-be map shows the path; a state design also says what each change needs, who owns it, and what happens when it can't happen. That's the part an implementation needs.
Do we have to choose a tool first?
No, and it's better not to. The design is tool-independent; it's also the best way to judge whether a visual workflow tool is enough or the process needs custom software.
How do you decide what software does and what people do?
Explicit rules go to software; real judgment stays with a named person, at a clear step. Discovery usually shows that some “judgment” is a rule nobody wrote down.
What if the process changes later?
It will. States and transitions are written down, so a change is a reviewable edit to one transition rather than a rewrite. Each rule has an owner who approves changes.