Intake and routing
Check a request for the information it needs, apply agreed routing rules, and send the responsible person a useful handoff.
The work between your tools is still work. We connect the steps people copy, forward, check, and chase—so a request can reach the right destination with its context intact.
Operational design / Follow the handoff
A reliable automation knows what a complete input looks like, what has already happened, and where a person needs to step in.
An illustrative service request router. Change the event to see the route and the resulting record.
THE DECISION IN VIEW
Validate the required fields, create the work item, and return a receipt. A defined handoff gives the next person the information they need.
The happy path still needs an owner, a record, and an observable result.
The opportunity
A form arrives in one system. Someone copies it into another, forwards the attachment, checks whether it was seen, and updates a spreadsheet. Each step may be small; together they make the process hard to trust.
We map that path with the people responsible for it. The first release should remove a specific piece of repeated work and make the remaining decisions easier to see.
What we can build
Check a request for the information it needs, apply agreed routing rules, and send the responsible person a useful handoff.
Extract or organize relevant information, generate a draft or report, and route it for review before the next action.
Keep supported systems in step when a record changes. Define the source of truth and how duplicate or out-of-order events are handled.
Make due work and stalled handoffs visible. Route unresolved cases to a person with enough context to take over.
The decision, made clearer
| A process looks like… | A practical approach | The design question |
|---|---|---|
| Known triggers and standard app connections | A visual workflow or existing integration | Can your team understand and maintain it? |
| Specific rules across several systems | A custom API workflow | Which system owns each piece of information? |
| Unstructured text or documents | An AI-assisted step with validation | What evidence makes the output acceptable? |
| A judgment or exception | A clear human handoff | Who decides, and what do they need to see? |
A good starting point
A recurring process with identifiable inputs, an owner, and a recognizable finish. Frequency matters, but so does the cost of a missed handoff.
A boundary worth discussing
A process that changes its rules every time needs clarification before automation. We first make the decision points explicit rather than encoding an unstable routine.
Working together
Follow an ordinary request and an awkward one. Capture the time spent waiting as well as the time spent doing.
Agree the trigger, source of truth, responsible person, completion signal, and path for exceptions.
Run representative examples through the connected path. Check duplicates, missing information, and unavailable systems.
Deliver documentation, visibility into runs, and a clear plan for the team that will operate the workflow.
In practice
A home-care operation needs connected enrollment and visit records. A restaurant needs a calendar staff can update themselves. The useful system follows the actual workflow.
Local Growth · Rules Engine · Ops Automation
An accessibility and home-care business with a funding check, online booking, maintenance-plan enrollment, and a client portal for visits, reports, and billing.
Inside the buildHospitality · Live Events · Web
An Astro restaurant website with a Google Sheets music calendar, three calendar views, and upcoming-event filtering—so the live lineup stays connected to the staff who manage it.
Inside the buildExplore the working pattern
Run a fictional service intake, disconnect the source, and decide what can move forward. A useful workflow makes missing information visible and gives the next person enough context to continue.
Workflow laboratory / 04
Illustrative workflow
No live customer data
The first question finds a clear next step
A fictional homeowner asks about making a front entrance easier to use and exploring possible funding.
Run the scenario to follow the whole path, or take it one step at a time.
See the real work: Live Oak Home AccessTry disconnecting the source to see how missing information changes the path.
Before we begin
It is the use of software to connect recurring steps such as intake, validation, routing, approvals, and record updates. A good workflow makes ownership and completion clear, including when a person needs to intervene.
Look for repeated work with clear inputs and an outcome you can verify. Compare the frequency, waiting time, error cost, and maintenance effort. The first candidate should be important enough to matter and focused enough to complete.
No. Predictable rules and supported integrations can cover many processes. A model is useful where the work involves interpretation, such as classifying text or preparing a draft, and its output can be checked.
That can be a good goal for a straightforward workflow. We choose the implementation around the team’s skills and document how it works. More involved logic and integrations may need an agreed development support arrangement.
The design should make the failure visible, preserve the work needed to resume, and avoid repeating an action that already completed. The appropriate retry and handoff behavior depends on the operation.
We scope the systems, branches, exception paths, data preparation, and operational support. Walking through real examples gives a more reliable estimate than counting the boxes in a workflow diagram.
Rule-based steps with clear inputs and outcomes: data entry, document routing, approvals, notifications, and system-to-system updates. Work that requires judgment on ambiguous cases stays with a person, though a model can prepare a draft or classification for that person to check.
Building a workflow by connecting pre-built triggers and actions in a visual tool—Zapier, Make, n8n—rather than writing custom integration code. It's a good fit when the platform's supported connectors already cover your systems; custom development becomes worthwhile once the logic, volume, or connections outgrow what a no-code tool handles cleanly.
Let’s make it concrete
The best starting point is the process your team already knows takes too much chasing.
Map a better workflow