Context, not a placeholder
A CRM field is context the agent reasons with, not a slot it reads out. Even when you want the field mentioned in the opening line, you do not write the token into the spoken line. You put the token in the# Context section, and
then write the step as an instruction about behaviour.
Missing values
Blank,(not on file), and an unresolved {{field_name}} all mean the same
thing: missing. Every step that uses a field needs the other branch written.
And when a value is missing, the agent should just ask, the way a person would.
Not “I don’t have your weight goal on file”, not “the form didn’t capture that”,
not “the CRM says nothing here”. Those phrases tell the lead they are a row in a
database. “What result were you hoping for?” gets the same answer and sounds like
a conversation.
Custom fields versus custom values
Two different things with confusingly similar names.
Custom values are constants, so use them for stable facts: the office name, a
standing policy, a pricing note, a link. They are not per lead answers and will
be identical on every call.
Take the exact token from the variables list rather than guessing at the spelling,
because a token that does not resolve is a token the agent may say out loud.
When you select a linked project under a master agent, the chatbot reads that
project’s CRM fields and custom values. The script remains shared across the
linked projects, so adding a context field changes the shared script. Keep the
missing-value instructions above for projects where that field is unavailable.
Where this sits
Pulling a person’s details into the opening is covered on What your agent says. This page is about the fields underneath it: choosing which ones travel with the call, and writing steps that survive an empty one.In the API
- Update agent sets
contextFields, the CRM fields the agent reasons with - Get agent reads the current list
- The field ids come from your CRM; see CRM resources