Skip to main content

Agents

Welcome messages

Dynamic versus defined openings, and when each is required.

What the welcome message is

The welcome message is what plays the moment the call connects, before the caller has said anything. You set it per Finn under the Behavior section of the Create Finn wizard. Two modes exist.

ModeWhat happensWhere the text comes from
DynamicThe Finn generates an opener at call timeIdentity text, style and guardrails, call context
DefinedThe Finn speaks a fixed script verbatimThe exact string you type

There is no third mode. If you leave the defined field empty, the Finn falls back to dynamic.

Dynamic openings

Dynamic means the model writes the first line itself, using the same identity and style fields that drive the rest of the call. See agents-identity and agents-prompting for what feeds it.

Use dynamic when:

  • The call is inbound and the caller already chose to dial you.
  • The opener should vary with context (returning caller, time of day, dialed number).
  • Nothing legally required has to be said in the first turn.

What goes wrong with dynamic:

  • Drift. A weak identity text produces a weak opener. If your identity says only "you are a helpful assistant," the first line will be generic and callers disengage.
  • Length. The model sometimes opens with two or three sentences. Callers interrupt. Constrain it in Response Guidelines ("open with one sentence, then stop").
  • Non-reproducibility. Two calls with the same config produce different first lines. That makes regression testing harder. See agents-testing.

Defined openings

Defined means you type the exact words. Nothing is generated. The Finn says the string and then hands control to the model.

Use defined when the first line has to be predictable. Concretely:

  • Outbound calls. The recipient did not ask for the call. They need to know who is calling and why in the first line. Dynamic openers on outbound cost you answer-through rate.
  • Recording disclosure. In two-party-consent jurisdictions, all parties must consent to recording. The disclosure has to be in the first turn, worded the same way every time. See recording-consent and compliance.
  • Regulated scripts. Anywhere a legal or clinical review has signed off on specific wording, that wording cannot be regenerated per call.

A minimal compliant outbound opener:

Hi, this is Maya calling from Acme Dental Clinic. This call may be recorded for quality purposes. I'm calling about your appointment tomorrow.

When defined is required, not just preferred

Defined is the only correct choice when a regulator, a contract, or your own legal review specifies wording. Dynamic generation cannot guarantee a specific sentence appears. Prompting for it ("always say the call may be recorded") raises the probability but does not make it certain, and a missed disclosure in a two-party-consent state is a compliance failure, not a quality issue.

Two-party-consent recording rules apply in California, Florida, Illinois, Massachusetts, Maryland, Montana, New Hampshire, Pennsylvania, and Washington, among others. If you call into any of them, put the disclosure in a defined welcome message, or enable the platform's disclosure injection under Settings → Compliance → Recording Disclosure in the dashboard.

Variables in the opener

A defined message is fixed text, but it can carry contact fields from your audience so the same script personalizes per call. See agents-variables for the syntax and for what happens when a field is missing on a contact. A defined opener that references a field no contact has will read the placeholder out loud or drop it, depending on configuration. Test against real audience rows, not a hand-typed sample.

Setting it

Welcome message mode is set in the dashboard, in the Create Finn wizard under Behavior, not through a dedicated API endpoint. The field is part of the Finn configuration, so it moves with the Finn through agents-versioning and is included when you read or write a Finn via api-finns.

Changes apply to new calls only. Calls already in progress finish under the configuration they started with.

Practical defaults

DirectionDefault modeReason
InboundDynamicCaller initiated, no disclosure obligation in the first turn by default
Inbound, two-party-consent regionDefinedRecording disclosure must be first and verbatim
OutboundDefinedRecipient did not initiate, identification and purpose belong up front
Outbound, regulated scriptDefinedWording is signed off and cannot vary

Test both modes on a real call before deploying. agents-testing covers Test on Call and Test on Chat. Chat testing shows the text of the opener but not its pacing, so confirm the timing on a call.