01
Workflow diagnostic
Map the current job, establish a baseline, rank the causes, and recommend what to change—or whether to stop.
Observe the work.Engineer the workflow.
Tinework improves complex operations by studying the work before changing the system.
01
THE APPROACH
Learn the work before changing the system.
Most workflow problems are not software problems in disguise. The work has to show where policy, training, tools, or automation will help—and where they will not.
- 01Observe
Follow the work from trigger to outcome. Record the decisions, exceptions, delays, and workarounds with permission.
- 02Decide
Separate facts from assumptions. Let the people who do the work correct the model. Name who can approve each rule.
- 03Change
Test the smallest useful change: clearer policy, training, configuration, integration, software, or a limited AI task.
02
THE ENGAGEMENT
Diagnose. Build. Hand off.
02
Implementation
Design, build, launch, and measure the approved change without creating conflicting records.
03
Handoff
Train the team, document ownership and recovery, and confirm that people use the new process.
THE AUTHORITY RULE
AI may propose. A person decides.
Observed behavior is evidence, not policy. A named owner approves each consequential rule and production change.
03
CXEY CASE STUDY
Test a briefing before replacing a system.
CXey proposes a read-only Slack briefing from HubSpot, Shopify, carrier data, and approved policy. It leaves the reply to the agent. The case states what a pilot must prove and does not claim client results.
04
ABOUT
Rick Cerf and John Madden lead Tinework engagements.
Tinework combines workflow research, product design, software engineering, implementation, and training. Rick and John stay accountable from diagnosis through handoff.
START WITH DEFINED WORK
Is the work recurring, owned, and observable?
Describe the job and the decision you need to make. The Tinework team will tell you whether a diagnostic can help.
Check the fit