Business outcome
What the organization needed to be true at the end.
Design Pattern · September 2026
From applications to work
Businesses do not need CRM software; they need work performed. Decompose the outcome into roles, tasks, workflow, and capabilities, and the application stops being the organizing unit.
Under the pillar Labor as Code™
What is actually needed
Nobody needs a CRM. What is needed is: identify a prospect, remember what is known about them, communicate, schedule follow-up, track commitments, prepare material, record interactions, recognize signals, and decide what happens next.
A healthcare organization does not need patient relationship management software either. It needs to receive an inquiry, identify the patient, understand intent, schedule care, collect information, communicate instructions, coordinate staff, follow up, observe completion, escalate exceptions, and measure outcomes.
Once the work is written out this way, the question of whether a dedicated application is required becomes answerable rather than assumed.
The work decomposition model
The model runs from the outcome downward, and then back up through evidence. Every layer is written down, because a layer nobody can state is a layer nobody can automate or govern.
Roles
Who is accountable, who performs, who approves, who is informed.
Tasks
The discrete pieces of work, named the way staff name them.
Workflow
Order, timing, branches, and what happens when nobody responds.
Required capabilities
Forms, records, messaging, storage, scheduling, reporting, approvals.
Existing platform services
Which owned service supplies each capability.
Execution
Human, conventional automation, or AI for each step.
Observable evidence
What each step leaves behind that proves it happened.
Outcome
Compared against the metric the business already reports.
Why the unit matters
When the application is the organizing unit, the work is fitted to whatever the vendor imagined, and the gap between the two is absorbed by staff doing things off-system.
When the work is the organizing unit, the tooling is fitted to the work, and off-system behavior becomes a visible signal that something is wrong rather than an invisible tax.
Put this to work
From applications to work application record
Apply From applications to work to a real piece of work and record what happened.
- For
- Operators redesigning a team, service, or AI workforce.
- What you keep
- A from applications to work application record you can review, revise, and send.
- What counts as sound
- Names a real setting
- Shows the work before and after
- Records exceptions
- Uses an observable result
- Ends with keep, revise, or stop
Do not infer that a task can move merely because it can be described.
Nothing entered here is stored or sent. Review the prompt before sharing confidential, personal, patient, or privileged information.
Review the prompt
You can leave any field blank. The prompt will mark it as not provided.
If the record survives your review, send the question, evidence, unknowns, and requested next step.