# Turn a vague automation idea into a brief you can build from. A fictional support inbox, mapped into one testable first step. Use this example to prepare your own brief; it is not a client report. 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. **Workflow teardown** ยท SUPPORT-SCOPE / EXAMPLE-01 Example recommendation: settle the category rules before commissioning the PoC. ## 01. 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. Read the message โ†’ Look up the context โ†’ Choose a queue โ†’ Assign an owner ## 02. Inside the scope document ### The workflow map 01 / Current state 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. ### An input inventory 02 / Evidence available List example records, fields, category definitions and access constraints. Separate material already available from material someone still needs to approve, redact or collect. ### A problem statement 03 / Decision to test 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. ### The proposed first slice 04 / Scope boundary 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. ### An acceptance outline 05 / Checks to agree 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. ### A recommendation 06 / Next action 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. ## 03. 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-01: A request with a clear category **Proposed 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-02: An overlapping or unclear request **Rule 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-03: Empty or unsupported input **Boundary 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-04: A failed external dependency **Proposed 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. ## 04. 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. ## 05. 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 owner:** Support 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 owner:** Data owner + buyer ## 06. 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. ## Questions ### 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. ## Your own brief ### Workflow and business owner [ ] ### Current trigger and steps [ ] ### Inputs available and access owner [ ] ### Useful output [ ] ### Normal, ambiguous and failure cases [ ] ### Exclusions [ ] ### Evidence still needed [ ] ### Decision owner and review date [ ] [Discuss the next scope](https://urbanodx.com/contact/?package=teardown&from=service_details&utm_source=urbanodx&utm_medium=sample&utm_campaign=202609-deliverables)