Read this as a sample deliverable
This is an original, fictional decision brief for a hypothetical distribution business. The business, process, records, constraints, and recommendation below are invented to demonstrate an assessment method. No client engagement, implemented system, completed test, measured saving, or approved project is represented.
An AI strategy assessment should make a decision easier to review. This example recommends testing ordinary reporting rules first. AI remains an option for a narrower task if the evidence justifies it.
1. The decision and business problem
Decision: Should the team automate preparation of its weekly late-order report, and does any part of that work require AI?
Assumed problem: A reporting coordinator combines order and shipment exports, checks dates, and writes a short explanation for an operations manager. Repeated copying creates opportunities for omissions and inconsistent status labels. Staff time and error frequency have not been measured; neither is treated as an established saving opportunity.
Desired output: One reviewed report listing the included orders, their shipment status, unresolved exceptions, and a short factual summary. The operations manager remains responsible for deciding what action to take.
Business owner: The operations manager owns the question, approves status rules, reviews the evidence, and decides whether to continue. A reporting coordinator checks the output. A systems owner approves access and maintains any accepted implementation. This example assigns responsibilities to roles; a real brief should name the people who accept them.
2. Assumed current process
- The coordinator exports all orders in the agreed reporting window, including completed orders, and their corresponding shipments from the existing systems.
- They match records by order ID in a spreadsheet and identify incomplete or conflicting records.
- They compare the promised date with the shipment date or reporting cutoff.
- They assemble a report and draft a short summary.
- The operations manager checks exceptions and approves distribution through the existing internal channel.
The assessment would verify these steps with the people doing the work. In this fictional brief, export availability, staff capacity, and the consistency of order IDs are assumptions to confirm before a pilot.
3. Readiness findings and unresolved constraints
- Data: Assume CSV exports exist. Confirm column definitions, time zone, reporting cutoff, duplicate handling, and whether partially shipped orders need a separate rule. A digital file alone does not establish usable data.
- Access: Begin with synthetic records. Before using business exports, the systems owner must approve the fields, storage, users, and deletion arrangements. Customer names, contact details, prices, and free-text notes are outside the proposed pilot.
- Rules: The operations manager must approve definitions of late, on time, open, and unresolved. Missing dates or conflicting shipment records must become exceptions, not guessed values.
- Ownership: The coordinator needs time to review outputs and record corrections. The systems owner must accept maintenance responsibility before any operational handoff.
- Economics: Current preparation effort, rework, recurring costs, and budget are unknown. The brief cannot establish ROI or justify a production purchase yet.
Readiness decision: Suitable for a synthetic feasibility exercise. Not yet approved for business data or production use. Confirm the access and rule decisions above before starting a representative pilot.
4. Options matrix
These are qualitative planning judgments for the fictional scenario, not measured comparisons or vendor quotes. Check the capabilities of existing tools before commissioning software.
| Option | What it could address | Dependencies and limits | Decision in this example |
|---|---|---|---|
| Standardize the manual report | Consistent fields, status definitions, and review checklist. | Staff still combine exports. Confirm whether simpler cleanup removes enough friction. | Establish this baseline first. |
| Existing reporting features or deterministic rules | Repeatable matching, date comparisons, totals, and exception lists. | Stable identifiers, explicit rules, permitted exports or connectors, and a maintenance owner. | Preferred feasibility test; evaluate existing features before writing custom code. |
| Purchased reporting product | Reusable reporting and supported connections if the product fits. | Check source coverage, permissions, license terms, setup effort, and recurring cost. | Compare if existing tools cannot meet the requirements; no product selected. |
| AI-assisted narrative drafting | A first draft of commentary from an already validated report. | Approved model/data handling and sentence-level fact checking. It must not calculate authoritative status or invent causes. | Defer unless commentary remains a meaningful burden after simpler improvements. |
Recommendation: Test the smallest rules-based reporting option after standardizing the manual baseline. The main assumed work is matching and date comparison, which does not inherently require a language model. Reconsider AI only if a documented residual need warrants its additional review and operating cost. The build-versus-buy guide explains how to investigate such gaps.
5. Proposed pilot scope and sample acceptance cases
Included: One weekly report for one team, using approved copies of two exports. Produce a draft report, an exception list, and a review log. Preserve the manual process throughout the trial.
Excluded: Live ERP writes, customer communications, automatic distribution, employee performance scoring, forecasts, and recommendations about the causes of delays. No model access or production connector is authorized by this brief.
The following synthetic cases describe expected behavior. They have not been run against a system:
- Fictional order EX-101: Promised March 6, shipped March 5. Under the assumed date rule, label it on time and retain the source row references.
- Fictional order EX-102: Promised March 6, shipped March 9. Label it late under the same rule. Do not infer why it shipped late.
- Fictional order EX-103: Promised date missing. Mark it unresolved and send it to the coordinator; exclude it from on-time/late rates and disclose the exclusion.
- Conflicting or duplicate shipment records: Flag the affected order for review. Do not silently choose a record or count it twice.
The operations manager must approve those rules and add cases for partial shipments, date boundaries, cancellations, and any other applicable exception before testing business records. Each included input must be traceable to an output or a disclosed exception.
6. Measurement plan
Baseline: After agreeing on the manual template, the coordinator records preparation, checking, correction, and exception-handling time separately. Record included order count, source versions, unresolved records, reporting cutoff, and the person who checked the report. Retain the underlying log, not just a summary percentage.
Comparison: Use the same approved source snapshots for the manual and pilot methods. Include representative normal and exception cases. Record the order in which methods were tried, because familiarity can affect timing. Compare active staff effort separately from elapsed turnaround; include review, rework, maintenance, and any usage charges.
Observation window: Propose four weekly report cycles for an initial comparison, extending the trial if the cases are not representative. This is a planning assumption, not a statistical sample-size claim or a promised engagement duration. Do not extrapolate a short trial into annual savings without explaining workload and cost assumptions.
Acceptance: The reviewer must reconcile the included records and totals, confirm status rules, and resolve or visibly retain every exception before approving a report. A wrong total, silent omission, unauthorized disclosure, or unintended write blocks release. The business owner must set an acceptable net operating cost and minimum worthwhile effort reduction before evaluating the pilot; neither threshold has been approved in this fictional example.
7. Proceed, revise, or stop
- Proceed to a separate deployment decision only when access is approved, the agreed quality and cost criteria are met on representative cases, and a named human owner accepts support and maintenance. Pilot acceptance alone does not authorize release.
- Revise if inconsistent source data, unclear business rules, or review effort prevent a useful comparison. Narrow the scope or repair the inputs before adding AI.
- Stop or retain the manual improvement if existing reporting meets the need, the operating burden outweighs the benefit, or required access and ownership remain unavailable.
Before any rollout, record the approved connections, monitoring, escalation, manual fallback, recurring costs, and change-approval responsibilities. The current recommendation is a bounded feasibility test with unresolved prerequisites, not approval to buy, build, or deploy.
Adapt the brief to your own decision
Replace the fictional process and assumptions with information your owners can verify. Keep the decision, alternatives, exclusions, acceptance conditions, and unresolved questions visible. Use the AI readiness checklist to prepare, the pilot-planning guide to define evidence, and the workflow automation service when you already have a bounded implementation problem.
To scope an assessment, discuss your workflow. Begin with a description of the task and tools; leave confidential records out of the initial inquiry.