# Test a change before trusting it

Every channel has a way to see what Connect would do without anyone receiving it. On mail that is `draft_only`, which writes and stops without even asking for approval. On the phone it is a test call with the Voice Lab's draft settings, judged by the call's review rather than by ear. Use one change at a time, or the result cannot be attributed.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy, #/test-maya, #/calls, #/needs-you
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/test-before-trusting/

## The safe surface on each channel

| Channel | Safe test | What it costs |
|---|---|---|
| Email | `draft_only` at the scope you are changing | Drafts are written and nothing is queued for approval — you read them and nobody receives them |
| Email, narrower | `draft_only` on one contact or one mailbox | The rest of the workspace carries on normally |
| Phone | A test call from the Voice Lab with the draft settings | One call's worth of usage, and a review that names what to change |
| Phone, from your desk | The browser-based line, which is a routing row like any other number | The same, without needing a handset |
| WhatsApp and SMS | `draft_only`, plus a message from a number you control | Provider rules still apply — session windows and templates are the provider's, not Connect's |
| The record side | A small import, twenty rows before two thousand | Twenty records to merge if the mapping was wrong |

> **Note** `draft_only` is the one people get wrong. It writes a reply and stops on purpose, without putting anything in front of anybody — which is exactly what you want while evaluating, and exactly what you do not want if a colleague is supposed to act. If you need approval rather than observation, that is `ask_before_send`.

## A test that proves something

1. Write down what you expect to change, in one sentence, before you test. "Replies should stop offering a firm delivery date and offer to confirm after despatch" is checkable.
   - Result: You have a criterion. Without one, every output looks like evidence for whatever you already believed.
2. Change exactly one thing.
   - Result: Whatever the result is, it is attributable. Two changes tested together produce a result neither of them explains.
3. Exercise the awkward path, not the easy one. On the phone that means interrupting, and staying silent for a few seconds; in mail it means the message that mixes a routine question with a commercial one.
   - Result: You have tested the part that actually fails. A scripted, polite test call proves the greeting works.
4. Use obviously fictional details for anything you invent — a made-up company, a number you control.
   - Result: Nothing in the test can be mistaken later for a real record or a real commitment.
5. Read the deterministic evidence before forming an impression: the call review for a call, the drafted text for mail, the record for an import.
   - Result: The review reports slow replies, long gaps, ignored interruptions, false stops, repetition, stock phrases, wrong script and unheard caller, each with the setting that addresses it — and marks the model's opinion on delivery as the model's.

## What a test cannot tell you

A test call runs with the Lab's draft settings, which sit at the narrowest point of the resolution order — below the workspace, the default profile, a profile by purpose, one by line number and one on the contact. That is what makes it safe, and it is also the limit: a good test call proves the draft is good, not that it is what a real caller will meet. Promote the draft to the profile it belongs to and the promotion is the change.

**Drafts look right, real replies do not** — Something narrower is in force for the real correspondents — a contact-tier rule or memory that the test did not exercise.
**The test call was fine and real calls are slower** — Load. A busy fleet refuses new calls as not-ready rather than degrading them, but a call placed at a quiet moment is not a measurement of a busy one.
**You cannot reproduce the fault** — Look at the decision log for the real occurrence rather than trying to recreate it. The rule in force at the time is recorded; guessing at it is slower and often wrong.
**Everything passed and production broke anyway** — Check whether the test ran as the same audience. A change that works for the operator and fails for a customer is nearly always a routing or permission difference rather than the feature.

## Turning a test into a rollout

Widen deliberately rather than all at once. A change proved on one contact goes to one mailbox, then to the channel, and the queue is watched at each step — the point of the middle steps is that a problem shows up while it is still small enough to be a nuisance rather than an incident. When the change is finally in force everywhere, put the reason in writing at the tier it lives on, so the next person to read it knows it was tested rather than assumed.

Do not re-run a passed check because unrelated things have moved since. Re-testing is for when the behaviour changed, not for reassurance; the decision log tells you whether anything relevant actually changed.

## Questions

### Is there a separate test workspace?

For application use, no — the safe surfaces are the modes and the test call, which is why they exist. Developers integrating against Connect have their own guidance on testing safely, which is a different question from trying a behaviour change.

### Does a test call cost anything?

It uses the same engine as a real call, so it consumes the same usage, and the budget check that runs before any call runs before this one too. One call to prove a change is cheap; twenty to build confidence is not, and the review makes twenty unnecessary.

### Can I test without any risk of a message reaching a customer?

`draft_only` does not hand anything to a provider, so nothing can leave. The risk to manage is the opposite one: replies that should have gone out are not going out while the mode is on, and the customer experiences that as silence.

### How many test calls should a voice change get?

One, if you exercise the awkward path on it. The review's timing and interruption findings are measured on the wire rather than impressionistic, so they do not need averaging across attempts.

## Related

- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Change how Connect sounds on the phone](https://connectbyjbrh.com/docs/how-to/change-the-voice/)
- [Make a test call](https://connectbyjbrh.com/docs/getting-started/make-a-test-call/)
- [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/)
- [Testing against Connect safely](https://connectbyjbrh.com/developers/sandbox/)
- [Check a phone number before you go live](https://connectbyjbrh.com/docs/how-to/check-a-number-before-going-live/)

## What this page is based on

- docs-source/sources/GENERAL.md §5 — `draft_only` and the other modes
- docs-source/sources/PHONE.md §6 — the Lab draft, resolution order and the review
- docs-source/sources/PHONE.md §5 — capacity refusals under load
- docs-source/sources/GENERAL.md §1 — audience differences show up as routing