Checklist · 9 min read
AI workflow design & QA checklist
A pre-flight checklist for workflows that use models to research, classify, draft, recommend, or take action in GTM.
Key idea
Treat every AI workflow as a product: define its job, input contract, human control, failure behavior, and evidence of value.
1. Write the workflow brief
| Prompt | A good answer |
|---|---|
| What is the job? | Summarize verified account context for a rep before a first call |
| What does success look like? | A rep can identify one relevant hypothesis in under two minutes |
| What is out of bounds? | No invented facts, no sensitive data, no automatic customer contact |
| Who owns the outcome? | Outbound operations lead, with Sales leadership as approver |
| What happens when uncertain? | Cite missing evidence and route to a human review queue |
2. Check the input contract
- Every important input has a named source and freshness expectation.
- The workflow can distinguish missing data from a negative signal.
- Restricted, personal, or customer-confidential data is excluded by policy—not by prompt wording alone.
- The model receives the minimum context needed for the job.
- The output includes source links or evidence whenever it makes a factual claim.
3. Build quality assurance into the flow
- Create a test set
Use 20–50 representative records, including messy inputs, missing data, edge cases, and known failures.
- Define a rubric
Score factual grounding, relevance, policy compliance, usefulness, and correct escalation—not just whether the prose sounds good.
- Review before activation
Start with a human approval queue. Only automate an action after the workflow proves reliable in that context.
- Log the evidence
Store workflow version, input references, output, reviewer action, and final outcome so you can investigate and improve.
4. Measure the outcome, not the novelty
- Adoption: Are intended users choosing to use it?
- Quality: Is the output grounded, relevant, and accepted by reviewers?
- Speed: Does it reduce time to a useful action?
- Business result: Does it improve the downstream result it was designed to influence?
- Risk: How often does it require correction, create an exception, or cross a policy boundary?