# Voice profiles A profile is a saved set of voice settings with a name. It can sit on the workspace, on a purpose, on a particular line, or on one contact, and `voice_style.resolve` walks those from broad to narrow with the narrowest winning. Whatever it lands on is snapshotted onto the call, so a review months later judges the settings that actually ran. - **Status:** Available - **Audience:** both - **Channels:** phone - **In the app:** #/phone - **Last verified:** 2026-09-10 - **Canonical:** https://connectbyjbrh.com/docs/phone/voice-profile/ ## The order, narrowest last 1. The **workspace** settings — the floor everything else is built on. 2. The **default profile**, if one is nominated. 3. A profile attached to a **purpose**: `inbound`, `service`, `transactional` or `promotional`. 4. A profile attached to a **line number**. 5. A profile on the **contact** (`contact.facts.voice_profile`). 6. The **Lab's draft**, on a test call only. Each step overrides the one before it, so a contact-level choice beats a line-level one and both beat the workspace. The draft sits at the end deliberately: it is how a change can be heard before it is saved, and it applies to test calls rather than to live traffic. > **Note** There is no campaign object anywhere in this system, and "per campaign" here means **per purpose**. Four purposes exist and they are the axis a profile can be attached along — inventing a fifth grouping is not a configuration option. ## What a profile actually contains Two kinds of setting, and the difference decides what you should expect from each. **Engine** settings become session parameters in `voice_style.session_options` and take effect exactly — the model, the voice, a pinned language code, temperature, reply length, the end-of-speech silence, the interruption thresholds, noise cancellation, the silence and hang-up timers. **Steering** settings become lines in the instructions through `style_block` — speed, energy, warmth, formality, pauses, fillers, accent, pronunciation — and the model interprets them. The behaviour texts sit alongside: role, goal, tone, style, knowledge, rules, what to ask and never ask, objections, escalation, opening, closing, proactiveness, language switching and memory use, all from `behaviour_block`. [The Voice Lab](/docs/phone/voice-lab/) is where both are edited and where the distinction is labelled on every control. ## Assigning one, and proving which one ran 1. Decide the scope first — most lines need nothing narrower than a purpose. - Result: Fewer profiles at broader scopes means fewer surprises about which one applied. 2. Attach it, then place a test call from the Lab before saving anything as the default. - Result: The draft applies to that test call, so you hear the change without exposing a live caller to it. 3. After a real call, read the resolved settings on `call.quality`. - Result: That snapshot, not the current configuration, is what the review judges — settings changed since do not rewrite what happened. The snapshot is the part worth internalising. Without it, a review of a call from last week would be scored against settings somebody adjusted yesterday, and every conclusion drawn from it would be quietly wrong. ## What is verified today The resolution order and the two kinds of setting were reconciled on 2026-09-10 against `backend/app/voice_region.plan` at `f5ea518` and are unchanged, contact-level attachment included. One interaction is worth holding in mind: a pinned language code beats every piece of evidence on the call, so a profile that pins one also switches off the regional following described in [detecting the caller's language](/docs/phone/language-detection/). If a decision depends on which profile resolved, the snapshot on the call is the authority, not this page. ## Questions ### Two profiles could apply. Which one does? The narrower. The order is workspace, default profile, purpose, line number, contact, then a Lab draft on a test call — each overriding the one before. If the result surprises you, the snapshot on the call is the authority on what actually resolved. ### Can a profile change the language of a call? It can carry a pinned language code, which is an engine setting. With the line's switching behaviour set to anything other than `follow`, the call is held there: any language is understood, the replies stay pinned, and no evidence steers them unless the caller asks outright. That is a deliberate, heavy-handed control — appropriate for a single-purpose line, and usually wrong for a line that meets a mixed audience. ### Do profiles apply to the carrier turn-based engine? The engine settings are realtime-session parameters, so much of a profile has nothing to act on there. What the turn-based path does carry is [Connect's own voice](/docs/phone/connect-voice-tts/) for the spoken sentence and the behaviour texts that shape what is written. ## Related - [The Voice Lab](https://connectbyjbrh.com/docs/phone/voice-lab/) - [Human voice profiles](https://connectbyjbrh.com/docs/phone/human-voice-profiles/) - [Telling the voice how to speak](https://connectbyjbrh.com/docs/phone/speaking-guide/) - [Call quality review](https://connectbyjbrh.com/docs/phone/voice-lab-review/) - [What a setting cannot change](https://connectbyjbrh.com/docs/phone/model-limits/) ## What this page is based on - Reconciled 2026-09-10 against `f5ea518` — `backend/app/voice_region.plan`, read from the code rather than its docstring - Connect phone source pack — `docs-source/sources/PHONE.md` §6, resolution order and the two kinds of knob - Connect capability registry — `docs-source/facts.py` (`voice_lab`, `human_voice_profiles`)