Skip to main content

Customer Context

An agent that knows who it is talking to gives better answers. It can skip the sales pitch for a paying customer, look up the order a customer asks about, and remember what was discussed last week. An agent that thinks it knows who it is talking to is a risk. Anyone can type "I'm [email protected]" into a chat.

Customer context in SendSeven solves both sides. You decide which data an agent may see, and every value reaches the agent labelled as verified (a fact you or the channel can stand behind) or unverified (a claim). The agent personalises with both, but only acts on facts.

What you can build​

  • Support instead of a sales pitch for logged-in users. Your web app mints a contact token on your server with the user's plan, role and account status. The help bubble opens with a verified profile: a paying customer gets peer-level support, a trial user gets onboarding help, and a visitor on your marketing site still gets the neutral discovery conversation.
  • "Where is my parcel?" answered from your order system. A shop agent on WhatsApp calls your context endpoint with the customer's verified phone number. Your server returns the last order and its delivery state, and the agent answers with the real status instead of a generic "please check your email".
  • Identity confirmed before account-specific help. A live chat visitor says "I'm [email protected], I need to change the delivery address of my order". The agent offers contact verification and sends a one-time code to the address on file. Only after the code is approved does the agent treat Anna's profile and order data as hers.
  • Lead qualification that writes back to the contact. A sales agent on Instagram asks what the person needs and records the answer in a "Contact type" custom field set to fill_if_empty. Your team and your CRM see the value, marked as set by AI, and a later claim in the chat can't flip it.
  • Continuity for returning customers. A customer who wrote three times last month comes back. With earlier conversations turned on, the agent reads short summaries of the closed conversations and picks up where the last one ended, instead of asking for the order number again.
  • Data that stays where it belongs. Your CRM stays the source of truth. A context endpoint returns only the fields you map, the agent sees them for this conversation, and nothing is copied onto the contact unless you choose to save it.

Verified facts and unverified claims​

Every value the agent receives carries its origin. SendSeven sorts the values into two groups before the agent sees them.

Verified values come from a source the person chatting can't change:

  • Values from your server: the context and saved data of a contact token, and the mapped response of a context endpoint.
  • Values from the contact record (standard fields, custom fields set by your team, the API, an import or an integration) when the conversation is tied to that contact: the customer writes from their own WhatsApp number, SMS number, Telegram, Messenger or Instagram account, or the live chat is bound by a contact token, a signed identity or an approved verification code or PIN.

Unverified values are claims or guesses:

  • Anything a visitor typed in the chat or sent from the page, including SendSevenConfig custom data and pre-chat form answers.
  • Values the agent itself wrote earlier (marked set by AI).
  • Tags. Tags have no provenance, so they are always shown to the agent as labels, not facts.
  • Values written before provenance tracking existed (marked legacy).
  • Record values in an anonymous live chat. The record may be correct, but nothing ties it to the person typing.

What the agent never does on a claim​

The agent uses unverified values to personalise (greeting by name, answering in the right language, adjusting tone). It never uses them to:

  • grant access, discounts or account changes,
  • give plan-specific or account-specific help,
  • disclose account data,
  • confirm or unlock anything because of who the person says they are.

Without a verified section the agent treats the person as unknown: it does not assume their identity, account or history, and asks neutrally when it needs something. These rules are built into every agent. Your instructions don't need to repeat them, but they also can't switch them off.

Verified identifiers​

An email address or phone number is only an identifier SendSeven trusts when the contact method is marked verified. Phone numbers become verified when the customer messages you from them on WhatsApp or SMS. Telegram, Messenger and Instagram IDs are verified from the start. Your team, the API, CSV imports and contact tokens can mark methods as verified. An email address is never verified just because an email arrived from it, because sender addresses can be forged. Details: Verified identifiers.

Which mechanism when​

You want the agent to knowUseReaches the agent asSet up in
Account data of a user logged in to your site or app (plan, role, status)Contact token minted on your serverVerifiedYour backend + widget config
Which contact a logged-in website visitor is, so their record counts as theirsSigned identity verificationRecord values verifiedWidget settings + your backend
Page language, the product page the visitor is on, non-sensitive hintsSendSevenConfig custom dataUnverifiedYour web page
That an anonymous visitor really owns the email or phone number they claimContact verification (code or PIN)Record values verified after approvalWorkspace verification settings + agent settings.verification
That an email address or phone number you already trust belongs to the contactVerified contact methods via API, import or the appUsed as verified identifierContacts API, CSV import
Live data from your own systems (orders, balance, subscription state)Context endpointsVerified ("from your system")Settings and agent Context tab
Stored facts about the contact, and fields the agent may fill inCustom fields with AI accessDepends on who wrote the valueField AI access + agent Context tab
What happened in the customer's earlier conversationsEarlier conversations (summaries) in the agent's context sourcesSeparate section, never treated as current factsAgent Context tab
Tags and newsletter subscriptions of the contactTags and subscriptions in the agent's context sourcesTags unverified, subscriptions as record valuesAgent Context tab

Rules of thumb:

  • Anything the agent should trust comes from your server, never from the browser. A value set in page JavaScript can be changed by the visitor.
  • Use a contact token when the user is logged in and you want to share account data. Use signed identity when you only need to tie the chat to an existing contact.
  • Use a context endpoint for data that changes often or lives in another system. Use custom fields for data that belongs on the contact and should also be visible to your team, flows and segments.
  • Use contact verification when anonymous visitors ask about their own account. It turns a claim into a verified identity without a login.

Configure what each agent sees​

Each agent has a Context tab (API: settings.context). Data sources are chosen per agent, so a public pre-sales agent and a logged-in support agent in the same workspace can see very different things. See Agent context sources for every source, its defaults, limits and the API shape.

An agent only ever sees the contact of the conversation it is answering. The contact is resolved by SendSeven from the conversation, never from anything the customer or the model says.

Your team sees the same context​

In the conversation view, the contact panel has a Customer context section. It shows your team exactly the data an agent would see for that conversation, with the same labels:

  • Verified or Unverified on every value.
  • The origin of each value: On record, From token, Visitor-provided, Set by AI or Legacy.
  • How the conversation's identity was established, for example Verified by token, Signed, Verified by code, Channel or Unverified visitor.
  • Data shared by your website through a contact token, with its expiry.

The same view is available over the API: GET /api/v1/conversations/{conversation_id}/contact-context. See Context endpoints: see what an agent knows about a contact.