Field guide for Charlotte company leaders
How to choose a first AI project your team can operate.
Use this guide before buying a platform or announcing a transformation program. It turns a list of AI ideas into a small number of testable workflow decisions.
01 · Inventory work, not ideas
Follow a case from arrival to completion.
Collect ten to twenty representative cases from a workflow. Include routine work, missing information, exceptions, rework, and one case that caused a serious delay. Record each handoff, system, source, approval, and wait.
Ask operators where they copy information, search for an answer, compare documents, draft repeated language, check a rule, or route an exception. These actions create candidate steps. Keep the full workflow visible because speeding up one step can move delay to the next queue.
Inventory worksheet
- Trigger and definition of done
- Case volume and seasonal range
- Hands-on time, wait time, and rework
- Source systems and authoritative documents
- Decision owner, reviewer, and exception path
- Known privacy, security, contractual, or regulatory constraints
02 · Score the candidates
A high-value use case can still be a poor first build.
Score each candidate from one to five on the six dimensions below. Write one sentence of evidence for every score. A team should reject a candidate when critical data, permission, or review gaps have no owner, even if the value looks large.
| Dimension | Evidence to collect |
|---|---|
| Business value | Name the queue, delay, error, cost, or missed capacity. Record a baseline the team can reproduce. |
| Task stability | Separate routine steps from cases that depend on negotiation, ambiguity, or rare judgment. |
| Source evidence | Identify the documents, records, policies, and examples a reviewer trusts today. |
| Data access | Confirm that the project can access the source without bypassing permissions or contracts. |
| Review design | Name who checks an output, what they inspect, and which event stops the workflow. |
| Operating owner | Assign the person who handles source updates, evaluation failures, incidents, and vendor changes. |
Use estimated value to prioritize discovery, then replace estimates with a baseline before approving implementation. Vendor benchmarks and broad productivity percentages do not describe your workflow.
03 · Draw the control boundary
State what software may do.
List the system actions in plain language: retrieve a source, classify a case, extract fields, draft text, recommend a route, write to a system, or notify a person. For each action, name required evidence and the event that hands control to a person.
Customer communication, financial commitments, employment decisions, policy exceptions, and access changes often need stronger review. Company counsel, security, privacy, compliance, and process owners should define controls within their authority.
Minimum control questions
- Which data enters the model or vendor service?
- Can users see only the sources they already have permission to access?
- Does each consequential output show supporting evidence?
- Can a reviewer correct, reject, and explain the result?
- Do logs capture inputs, source references, versions, actions, and approvals?
- Can the team stop the system and complete the work another way?
04 · Measure the workflow and the answer
Quality needs a test set. Value needs a baseline.
Build an evaluation set from representative work before tuning prompts or choosing a model. For search and RAG, pair each question with approved source passages and expected refusal behavior. For workflow automation, pair cases with expected fields, routes, approvals, and exception handling.
System measures
- Source retrieval and citation support
- Task accuracy and reviewer agreement
- Permission and refusal behavior
- Latency, availability, and cost
Workflow measures
- Cycle time and wait time
- Human review time
- Rework and exception rate
- Cost per completed case
Record sample size, time window, exclusions, and known changes in volume or staffing. A result without that context cannot guide the next investment.
05 · Write the first-build brief
Give the project a decision date.
The brief should fit on a few pages. Name the workflow boundary, users, source systems, controls, test set, baseline, acceptance threshold, owner, budget boundary, and review date. State the conditions that stop the project or return it to discovery.
A first build should teach the company whether the workflow, sources, controls, and operating model work together. It does not need to prove every future use case.