# Change how Connect sounds on the phone

Open the Voice Lab from the Phone screen's setup area, change one control, then place a test call and read its review. The realtime path is speech-to-speech, so there is no synthesiser with a pitch dial: half the controls become real session parameters and the other half become lines of instruction the model is asked to follow. The Lab labels which is which, and the distinction decides how reliably your change lands.

- **Status:** Available
- **Audience:** both
- **Channels:** phone
- **In the app:** #/calls, #/phone-advanced
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/how-to/change-the-voice/

## Two kinds of control, and why it matters

An engine setting is enforced. It becomes a session parameter before the call starts, and the model has no say in it: the model and voice identifiers, a pinned language code, temperature, reply length, the model's end-of-speech silence, pre-emptive generation, the interruption thresholds in seconds and words, false-interruption resume, noise cancellation, and the silence and hang-up timers.

A steering direction is a request. Speed, pitch, energy, warmth, emotion, pauses, fillers, formality, humanness, accent and pronunciation all become lines in the instructions, alongside the behaviour texts for role, goal, tone, knowledge, rules, what to ask and never ask, objections, escalation, opening, closing and language switching. The model usually follows them and sometimes does not, particularly late in a long call.

> **Careful** Do not treat a steering direction as a guarantee. If a call must never run past a length or must never leave a language, the enforceable control is the engine setting — a pinned language code, a hang-up timer — not a sentence asking the model nicely.

## Changing one thing and proving it

1. Decide what you want to be different and which kind of control owns it. "Stop cutting callers off" is an interruption threshold, an engine setting. "Sound less brisk" is steering.
   - Result: You know before you start whether you are configuring behaviour or requesting it.
2. Change exactly one control in the Lab and keep the draft.
   - Result: The Lab's draft applies to a test call, which is the last and narrowest step in the resolution order — workspace, then the default profile, then a profile by purpose, then by line number, then one set on the contact, then the Lab's draft.
3. Place a test call and hold a normal conversation on it, including one interruption and one pause where you say nothing.
   - Result: You have exercised the parts a scripted read-through never touches: barge-in, silence handling, and the model's end-of-turn detection.
4. Open the call's review rather than judging by memory of how it felt.
   - Result: The review reports slow replies, long gaps, ignored interruptions, false stops, repetition, stock phrases, wrong script and unheard caller, each paired with the setting that addresses it, plus the model's opinion on delivery marked as the model's own.
5. If the review is good, promote the draft to the profile it belongs to — the default, a purpose, or one line.
   - Result: The settings that actually ran are snapshotted on the call record, so a later review judges what was in force rather than what is in force now.

## Reading the review honestly

**A reply under 2.5 seconds** — Inside target. Nothing to change.
**A reply over 4 seconds** — Slow, and the review names the control that addresses it.
**A finding marked as model-limited** — The model's own first token was 60% or more of the wait. There is no knob for this, so the review offers none, lists it, counts it, and does not lower the score for it.
**An interruption logged as ignored** — The voice kept talking after you spoke over it. Past two seconds of that, the barge-in is recorded as ignored rather than late.
**Latency numbers that disagree with your ear** — Trust the review. Timing is taken on the wire — from the caller's last word to the first audio back — not from transcript rows, which arrive only when a sentence is complete.

The measured floor on the realtime path is the model's first token plus its end-of-turn detection, and on the best call measured that was a 3.3 second median reply. Tuning moves a call towards that floor; it does not move the floor. A target of one to two seconds cannot be reached by changing settings and chasing it wastes an afternoon.

## What to change when a call sounded wrong

| What you heard | Kind | What to reach for |
|---|---|---|
| It talked over me | Engine | The interruption thresholds in seconds and words |
| It stopped when I paused mid-sentence | Engine | The model's end-of-speech silence, and false-interruption resume |
| Replies were too long | Engine | The reply-length setting, not a request to be brief |
| It switched language when I did not want it to | Engine | Pin the language code; a pinned language is never steered |
| It sounded flat, or too eager | Steering | Energy, warmth and emotion lines |
| It mispronounced a product name | Steering | A pronunciation line, checked on a test call |
| Every call opens the same stiff way | Steering | The opening text in the behaviour block |

> **Note** There is no campaign model. "A different voice per campaign" is a profile by purpose — inbound, service, transactional or promotional — or a profile pinned to one line number.

## Questions

### Why is there no pitch slider that actually changes the pitch?

Because the realtime engine is speech-to-speech: the model produces the audio directly, so there is no separate synthesiser to retune. A pitch direction is therefore a request in the instructions, and the Lab says so rather than presenting it as a dial that guarantees an outcome.

### Can one customer get a different voice?

Yes. A profile set on the contact beats one set on the line, which beats one set by purpose, which beats the default. Only the Lab's draft on a test call is narrower.

### How many test calls does a change need?

One is enough to tell whether the change did what you asked; the review is deterministic about timing and interruptions, so it does not need repeating to average out an impression. Change a second control only after the first one's review is clean, or you cannot attribute the difference.

### Do the Lab's settings apply to a call already in progress?

No. Session parameters are set when the session starts, so a change takes effect from the next call. The settings that were in force are snapshotted on the call record for exactly this reason.

## Related

- [The Voice Lab](https://connectbyjbrh.com/docs/phone/voice-lab/)
- [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/)
- [What a setting cannot change](https://connectbyjbrh.com/docs/phone/model-limits/)
- [Review a call properly](https://connectbyjbrh.com/docs/how-to/review-a-call/)
- [Measuring conversational latency correctly](https://connectbyjbrh.com/research/measuring-voice-latency/)
- [Findings a setting cannot fix](https://connectbyjbrh.com/research/model-limited-findings/)

## What this page is based on

- docs-source/sources/PHONE.md §6 — the Voice Lab, resolution order and review
- docs-source/sources/PHONE.md §12 — the measured floor on the realtime path
- docs-source/facts.py `MEASURED` — response targets and barge-in window
- Connect capability registry (docs-source/facts.py) — `voice_lab`