Inside a workflow teardown
Turn a vague automation idea into a brief you can build from.
Follow a support inbox from today's manual work to one testable first scope. Inspect the inputs, unresolved questions, proposed checks and recommendation, then adapt the example to your own team.
Markdown · editable · no signup
SUPPORT-SCOPE / EXAMPLE-01
Workflow teardown
The first useful scope
Example recommendation: settle the category rules before commissioning the PoC.
A fictional support inbox, mapped into one testable first step. Use this example to prepare your own brief; it is not a client report.
Map the current task
A support coordinator reads each incoming message, looks up the customer and assigns an owner. The proposed automation concerns routing suggestions only. There is no measured time saving yet, and the brief does not assume that an AI model is the right solution.
In this fictional example, the team can share a small redacted sample and a draft category list. It still needs to confirm whether earlier labels are consistent and who can approve data access. The teardown makes those gaps visible before the team buys a build.
- 01Read the message
- 02Look up the context
- 03Choose a queue
- 04Assign an owner
Inside the scope document
File labels below describe the example bundle. This download is the sample document, not a software repository.
01 / Current state
The workflow map
Where the task starts and ends, which tools it touches and who makes each decision. Capture the exception path too: a request without enough information still needs an owner.
02 / Evidence available
An input inventory
List example records, fields, category definitions and access constraints. Separate material already available from material someone still needs to approve, redact or collect.
03 / Decision to test
A problem statement
Name the repeated task and the question the first build should answer. Here it is whether routing suggestions are useful to a reviewer, not whether the entire support operation can be automated.
04 / Scope boundary
The proposed first slice
A message enters a review screen with a suggested category and an explicit review state. A person confirms the decision. Automatic replies, CRM writes and live rollout remain outside the first test.
05 / Checks to agree
An acceptance outline
Specify normal, ambiguous, empty and unsupported inputs and the behavior expected for each. Agree how missing provider results reach manual review before implementing the main path.
06 / Next action
A recommendation
Choose between clarifying the data, testing a simple rule or scoping a PoC. Record the reason, owner and evidence needed next. A teardown can recommend preparation instead of more development.
Define the first checks
These are proposed checks for the next scope, not completed test results. Agree the inputs and expected behavior with the workflow owner. The final acceptance record will add a build identifier, actual observations and a reviewer decision.
SCOPE-01A request with a clear categoryProposed check
- Input
- An approved or synthetic message that the support lead can classify without disagreement.
- Expected behavior
- Show the source message and a category suggestion. Leave the final decision with the reviewer.
- Review notes
- Prepare examples for every category included in the scope. Keep a separate review set so the demonstration is not the only evidence.
SCOPE-02An overlapping or unclear requestRule to agree
- Input
- A message that could belong to two queues, or does not contain enough information to choose one.
- Expected behavior
- Show a manual-review state and preserve the source. The category rule defines when the tool should avoid a suggestion.
- Review notes
- The support lead must settle the overlap rules first. Record disagreements rather than forcing uncertain labels into the example set.
SCOPE-03Empty or unsupported inputBoundary to agree
- Input
- An empty message or a language or attachment type that the first scope does not support.
- Expected behavior
- Explain the limitation clearly and leave a useful correction or manual path. Do not silently treat the input as a valid classified request.
- Review notes
- List the supported fields, languages and formats in the brief. Additional input types need an explicit scope decision.
SCOPE-04A failed external dependencyProposed check
- Input
- An otherwise valid message for which the categorization provider returns no usable result.
- Expected behavior
- Keep the message, expose the failure and follow an agreed retry or manual-review policy. Avoid duplicate decisions on repeated attempts.
- Review notes
- Choose the failure owner and recovery rules before adding a live integration. The first test can use a controlled failure in a test environment.
From question to written scope
The teardown follows the evidence available. These are working stages, not a promise of calendar dates. The package timing and final scope are confirmed with your inputs before the engagement starts.
Prepare
Bring one real task
Describe the trigger, current steps, tools and owner. Share a representative example through the agreed channel, with sensitive information removed where appropriate.
Review
Trace the decisions
Walk through the normal task and one exception. Separate rules that are already agreed from assumptions about data, access, volume or user behavior.
Define
Draw the boundary
Choose one useful output and write the checks, exclusions and dependencies. Compare a manual improvement, a deterministic rule and an AI-assisted step against the task.
Decide
Issue the recommendation
Return the workflow map, evidence gaps and proposed next step. If a build is justified, agree its deliverables, price and acceptance conditions separately.
Choose the next step
Example decision: clarify the rules first
The input sample is a starting point, but overlapping categories would make the result difficult to judge. This example recommends resolving the labels and checking a simple routing baseline before paying for a model-based PoC. There is no defensible savings estimate yet.
Agree category definitions
Review disputed messages, write the routing rules and record when manual review is required. Use the same definitions for the baseline and any later prototype.
Action ownerSupport lead
Confirm usable data and access
Confirm which examples can be shared, their limitations and who can approve the next environment. Keep access approval separate from a claim that the records are representative.
Action ownerData owner + buyer
Make the brief your own
- 1
Replace the support example with one task your team performs today. Write the trigger and useful end result in terms a colleague can observe, and identify who will review the output.
- 2
List the evidence you have and the gaps you still need to close. Leave missing volume, cost and time figures as unknown until someone measures them; avoid turning assumptions into a business case.
- 3
Choose a normal example, an ambiguous one and a failure case. Write what a person should see and do in each case, plus the operations the first version must not perform.
- 4
Share the completed brief with your business and technical owners. The downloadable Markdown includes the example and a blank brief to adapt. It is a planning document, not an approved statement of work.
FAQ
Before you use this sample
Do we need to know which AI model to use?
No. Start with the task, available evidence and review rules. The teardown can identify a simpler rule-based approach or show that data preparation should come first.
Can we begin without a live API?
A redacted export or synthetic example can help define the first scope. The document should state what that evidence can show and which integration assumptions remain untested.
Does this download include a paid teardown?
No. The sample and blank brief are free to use. A paid teardown reviews your actual workflow and inputs under the agreed scope and produces a recommendation for your situation.
What happens after the teardown?
You can use the document internally, resolve the evidence gaps or agree a build. The next package is a starting point; its deliverables, exclusions, acceptance criteria and timing still need written agreement.
Urbano DX
Bring the same clarity to your project.
Share the workflow, the evidence you already have and the decision you need to make. We can define a first scope around them.