A successful demo is one test case
Before launching an AI workflow, require evidence that it performs the agreed job on normal inputs, exceptions and failures. Inspect the actual CRM record, message or report it produces. A green execution screen or an assistant saying “done” does not prove that the business action succeeded.
Start by defining a small unit of work. For a sales workflow, that could be one eligible enquiry recorded once, assigned to the correct person and given the agreed next step. Establish who verifies it and which actions still need approval. The checklist below is a proposed acceptance process, not a certification or proof that a system cannot fail.
Write the expected result before running the test
Use a test account and synthetic examples that resemble the work. Where real records are necessary, restrict access and remove unnecessary identifying information from shared evidence. Record the input, expected output, actual output and downstream receipt for each case.
Keep some cases out of the builder’s prompt-tuning examples and use them for the final check. Test the workflow after meaningful model, prompt, tool or business-rule changes. n8n’s evaluation documentation describes comparing AI workflow outputs against known test cases; passing a fixed set still leaves uncertainty about unseen inputs.
Test the customer journey and the failure paths
Adapt these cases to the actual scope. Ten labels are not a statistically sufficient sample; repeat the relevant cases across realistic input variations and volumes.
| Case | Expected behavior | What to inspect |
|---|---|---|
| Normal enquiry | One record and the agreed next step | Destination ID, owner and action receipt |
| Missing information | Ask a relevant question or route to a person | No invented budget, location or commitment |
| Ambiguous request | Flag uncertainty and avoid an unsupported decision | Review queue with useful context |
| Duplicate event | Avoid a second business action for the same event | Stable identifier and destination readback |
| Service timeout | Record uncertainty before retrying an external action | Check whether the first action already occurred |
| Invalid or expired access | Stop the affected action and alert its owner | No silent success; recovery instructions |
| Customer opts out | Stop the applicable follow-up path | Suppression state and any queued sends |
| Human rejects a draft | Do not execute the rejected action | Approval decision and tool receipt |
| Cancellation or reschedule | Use the latest authoritative state | No stale reminder or duplicate booking |
| Untrusted text gives instructions | Treat it as customer content, not workflow authority | No unauthorized tool action or data disclosure |
Inspect the destination, not just the model answer
A response can be well written while the wrong customer record is updated. Verify field mapping, owner, timezone, currency and the destination’s success response. For a booking, inspect the confirmed appointment identifier; a calendar-link click is not a confirmed appointment.
Retries deserve their own check. A provider may accept a message before the connection times out. Resending blindly can contact the customer twice. The implementation needs a way to identify the business action and reconcile uncertain outcomes. Ask the builder to demonstrate this with a harmless test destination.
Put approval at the action that needs it
A person reviewing text after it was sent cannot prevent that send. If approval is required, check that it happens before the relevant tool changes a record, sends a message or makes another consequential change. Official n8n documentation supports approval or denial for selected agent tool calls.
Test approval, denial and no response. Name a backup reviewer and agree what expires. A workflow that waits safely forever can still fail the business if customers never receive an answer. The approval mechanism and a monitored escalation path solve different problems.
Use a clear release decision
Set blocking conditions before the test: for example, no sends after opt-out, no duplicate customer action in the retry cases and no unauthorized changes. These are requirements to demonstrate, not an assertion that a small test proves a zero production failure rate.
Record successes and failures with denominators. “18 of 20 classification cases correct; two routed incorrectly” is more informative than “90% reliable” without saying what was tested. Review the impact of each failure: a wrong internal label and an unauthorized quote are not interchangeable.
Do not hide unresolved high-impact failures inside an average score. Decide whether to fix them, narrow the workflow to drafting only or delay launch. A smaller workflow with a clear owner can be preferable to a larger one whose failures cannot be detected.
Launch narrowly and prove recovery
Start with a limited eligible group or a draft-only phase. Avoid two live systems replying to the same enquiry. Monitor completion quality, exceptions, handling time and the downstream business outcome. The pilot should tell you whether the system helps the team, not just whether it runs.
Demonstrate how to pause new actions, identify work already in flight, hand pending items to a person and reconcile the affected records. Turning off a trigger does not necessarily cancel actions already accepted by another service. Keep the previous working process available until the owner accepts the replacement.
Use the worksheet to capture the evidence with your builder. If your bottleneck is between interest and an attended call, Rainlight’s pipeline review can help define the next step and what evidence should count as completion.