Test the model against a real business workflow
A meaningful test starts with a real decision problem, not a feature checklist. Choose a communication where a wrong action has a measurable consequence: a change of supplier bank details, a payment instruction, a mandate, a critical contract instruction, a payroll change.
01
Start a test
-
Start with one narrow workflow
The strongest first test is a narrow, high-value workflow where an approval process already exists. Establish five things: what request is being protected, who is expected to issue it, who should receive it, what evidence is available, and what decision the recipient must make.
-
Keep the control you already have
Test alongside the controls already in use. If the current process has a finance employee call an existing supplier contact before changing bank details, that call stays in the test. The point is to find what evidence ADDS — which cannot be measured if the existing control is removed at the same time.
-
Measure the evidence, not the demo
Do not ask whether verification “worked”. Ask what A established, what B established, which later evidence was available, which claims stayed unproven, what decision the team took, and which control was still required. A test that shows a level does not establish a business fact has told you something useful.
-
A good test produces a decision, not a score
Record the outcome according to the evidence actually produced, and do not let the test manufacture a broader product claim than the tested workflow supports. The valuable outcome is a clearer control around one real high-risk event.
5 · Use a telephone channel that is genuinely independent
If a telephone confirmation is part of the scenario, write down where the number came from. A valid independent channel is a number you already had, never a number supplied by the request itself — and that sentence belongs in the test procedure, not in someone’s memory.