Skip to content

Manage people

A Person is the record an agent keeps for every human it talks to, and it is the single source of truth about that person for both your team and the agent.

This document describes working with People in the console: defining fields, managing the channel identities a person is reached on, importing a list, filtering and segmenting, recording consent, and merging records.

Who those people are depends on the agent: prospects who filled in a form, existing customers asking for support, guests making reservations, members of an audience. The record works the same way in every case: contact details, the custom facts you define, and the agent's accumulated memory of the relationship. A few built-in fields exist for use cases Anychat supports as first-class features, such as selling from a Things catalog and booking calls with representatives. Those are covered in Specialized fields and can be ignored by agents that do not need them.

None of this is required

An agent with no custom fields and no imported people works fine. It tracks the built-in fields and learns what it needs in conversation. Everything on this page is opt-in, for when you have structured data to bring.

The Person record

Every Person carries the core fields:

Field Notes
Name Full name, or first and last separately
Email Stored trimmed and in lower case
Phone Stored in international format when it reads as a phone number, else as typed. To message the person on this number, add it as a channel identity
Company
Title
Source Where the person came from (a referral, a form, an import)
Notes Free text, maintained by your team
Tags Free-form labels. Your team edits them; the agent may add (never remove) one when allowed to update People

These fields are information about the person. None of them identifies anyone: two records may share an email or a phone number, and changing a phone number here changes nothing about who the record reaches. A person is found and reached through their channel identities.

On top of these you can define People fields: the custom facts that matter to your business. For a sales agent that might be a buying timeline or a target market; for a support agent, a plan tier or an account number; for a reservations agent, a party size preference. Custom values appear on the person's record as tracked fields.

Each record also carries a memory journal: notes the agent writes as it learns, plus a one-line summary recorded when a conversation ends. The journal is the agent's own history of the relationship. It is visible on the person's record and is not directly editable.

Who set a value

Every field records who set its current value and when: your team, an import, an intake form, or the agent. The person's record shows this on each field. An agent write never replaces a value your team or an import set. To go further, lock a field on the record and the agent cannot change it at all.

Records also include specialized fields — product interest, funnel status, an assigned representative — that support specific use cases and sit dormant otherwise.

Defining People fields

Edit the agent's custom fields under Capabilities · People fields. Each field has:

  • Key. The stable identifier stored on the record, such as targetMarket. Letters, numbers, and underscores. Changing a key later orphans values stored under the old key, so choose it once.
  • Label. The human-readable name shown in the console and on forms.
  • Type. One of string, number, date, boolean, or enum. See Field types.
  • Allowed values. For an enum, the exact set a value must belong to.
  • Description. What the field means, written for the agent. The agent reads this to decide when a conversation has produced a value worth recording.
  • Examples. Optional sample values that help the agent recognize the field.
  • Intake aliases. Additional column headers an import or intake form may use for this field. See Importing people.
  • Required on intake. A hint that intake forms should ask for this field. It never blocks anything; the agent still fills a missing value from conversation.

The same page has the switch that controls agent writes: Allow the agent to update People with what it learns. With it on, the agent records declared fields, contact details, and journal notes as they come up in conversation. With it off, the agent reads the record for context but never writes to it.

Field types

Values are stored as text. The type controls how a value is validated and normalized when it arrives, whether from an import, a form, or the agent:

Type Accepted input Stored as
string Any text As entered, trimmed
number Anything that parses as a number The parsed number ("007" becomes "7")
boolean true/false, yes/no, y/n, 1/0 (any case) "true" or "false"
date Any common date format As entered, so no timezone is invented
enum One of the allowed values, matched case-insensitively The allowed value's exact spelling

A value that does not fit its type is rejected and reported; it is never stored in a mangled form.

Adding people one at a time

On the agent's People page, click Add Person, fill in what you know, and Save. Type phone numbers however you naturally write them: (555) 123-4567 works, and international numbers need their country code, such as +44. Custom People fields are edited on the person's record after it is created: open the person and edit the tracked fields inline.

To have the agent open the conversation, add the person's number as a channel identity, then continue with Outreach.

Channel identities

A channel identity is a person's address on one channel, such as their number on RCS. Messages from an identity belong to the record that holds it, and messages to the person go to one of its identities. Each identity belongs to at most one record. The Channel identities card on the person's record lists them, each with its channel, its address, when it was last seen, and whether it has opted out (STOP) or was found unable to receive on its channel.

Identities change only when your team changes them. Editing the person's phone or email never adds, moves, or removes one.

Add an identity

  1. Open the person's record and, in the Channel identities card, click Add.
  2. Choose the channel and enter the number. The person's phone number is filled in for you when it is on file.
  3. Confirm that the person opted in to messages on that channel, and say how the opt-in was obtained. The confirmation is recorded in the person's journal, and when no consent is on file it also records consent as Granted, with your note as evidence. A person whose consent is recorded as Declined can't be given an identity until you change their consent.

If another record already holds the identity, the console says which one and offers to Move it. Moving takes the identity, with its opt-out state and message history, from that record to this one, and records the move in both journals. Move an identity when the other record is the wrong person; when the two records are the same person, merge them instead.

Remove an identity

Click Remove on the identity. The record no longer holds it, so messages from that address stop belonging to this person. The identity keeps its opt-out state and message history, and a later message from it starts a new record when inbound records are on.

Working with the list

The People page searches by name, email, phone, or company, filters by funnel status or channel, and loads long lists in pages, newest first. Export downloads the people in the current view as a CSV whose profile columns match the import template, ready to load into another tool. The export includes each person's core fields, custom fields, tags, and channel identities; it does not include conversation transcripts. Its channel and address columns name each person's default identity, so an edited export imports back onto the same people.

Filtering and segments

The filter bar narrows the list further: by tag, by source, by whether a phone number is on file, by the channels a person has an identity on, by reachability (whether the last outreach attempt found the person reachable over RCS), and by messaging consent. Filters combine, so one view can hold, say, everyone tagged from a webinar who has an RCS identity the agent can reach. Export honors the active filters, which makes a filtered view the natural way to pull a working list: filter, check the count, download.

A filter combination you return to is worth saving as a segment: a named filter stored on the agent. Save the current filters from the filter bar, then reapply them any time from the segment picker. A segment stores the filter, not a snapshot, so it always shows the people who match right now, including anyone added since it was saved. Segments are also available to the Agent API for pulling the same lists programmatically.

Each Person can carry a record of whether they agreed to receive messages. Automated Outreach fills it in from the lead sheet's consent column and only messages people whose consent is Granted, and a Campaign reaches only the same people. Everyone else is still imported, so the list shows why nothing went out: a person with no consent on file shows No consent in the Outreach column, and a person who said no shows Declined. Hover either badge for the explanation. The badge disappears once outreach has been sent, or once consent is recorded as granted.

Consent is separate from funnel status. A person can be New with consent granted, declined, or never recorded.

The manual Outreach button stays available in every state. A send you make by hand is your responsibility, so Anychat sends it when consent is missing: you may hold consent that never reached the platform. The button shows a warning icon and the send dialog repeats the warning above the template picker. When consent is recorded as Declined, the send is refused until you update the person's consent. Record consent you hold so the warning goes away and the grant is on file for Automated Outreach and Campaigns too: open the person, and in the Messaging consent card click Record consent, choose Granted or Declined, and write how consent was obtained (a signed form, a phone call). The note is kept verbatim as the evidence, alongside who recorded it and when. Consent imported from a lead sheet shows the sheet as its source and the form's disclosure text as evidence.

The Consent filter (Granted, No consent, Declined) lists everyone in a given state, and saved segments store it like any other filter, so "still needs consent" can be a standing view. The CSV export includes a consent column.

To bring in an existing list, use Import CSV/XLSX on the People page, or drag the file onto the list. Each row becomes a Person. Click Template first to download a CSV header row with exactly the columns this agent expects.

A common pattern: people already reach you through a form on a landing page or through a lead-gen tool, and that form asks the questions your process cares about. Define those questions as People fields, import the spreadsheet your tool exports, and the agent opens every conversation already knowing what each person submitted.

Importing people

Import people from a spreadsheet export or CSV. The sections below describe how columns are matched to fields, what the import reports, and how identities and update modes decide what changes.

How columns match fields

The header row names the columns. Matching is case-insensitive and ignores spacing (First Name, first_name, and firstname are the same header).

Built-in fields answer to these headers:

Field Recognized headers
Full name name, full name
First / last name first name, last name
Email email, email address
Phone phone, phone number, mobile
Company company, company name, practice, practice name
Title title, job title, role
Product interest product, product interest, interested product, interest
Source source, lead source
Notes notes, note
Funnel status status
Channel identity channel and address, together

Your custom People fields match on their key, their label, or any intake alias you have added. If your field is labeled "Buying timeline" but the spreadsheet column says "When", add when as an intake alias and the column lines up. Aliases are the way to adapt the import to a spreadsheet you cannot rename.

What the import reports

The import reports everything it could not place instead of dropping it silently:

  • Unmatched columns. A header that matched no field is listed in the result. Fix the header, or add a People field (or an alias), and import again. Unmatched values are not stored.
  • Invalid values. A value that fails its field's type check (a non-number in a number field, a value outside an enum's allowed set) is reported with its row and reason. The rest of the row still imports.

Identities and update modes

A row that names a channel identity in its channel and address columns, such as rcs and +15551234567, updates the person who holds that identity, or creates a person who holds it. Importing the same list twice is safe for those rows. Rows that name the same identity apply to one person, in order. A row without an identity always creates a new person, who can't be messaged until you add an identity. Email, phone and the other profile columns never find an existing person.

When an import contains rows to update, the console asks which mode to use:

  • Fill empty fields only (default): the row writes only fields the record does not already have.
  • Overwrite: the row's values replace the record's where they differ. Locked fields are never overwritten in either mode.

A row whose identity can't be used is reported with its reason: an address that is not valid on its channel, a channel that has no addresses you can name (use rcs, sms, whatsapp or amb), or one of channel and address without the other. An import takes no opt-in confirmation per identity: consent comes from the row's consent columns.

Leads from a spreadsheet

If your leads land in a Google Sheet, Automated Outreach watches it for you: every new row becomes a Person, ready or not, and the ones that qualify and have recorded consent are sent an Outreach. Rows the run could not use are reported with the reason, so a mistyped number or a missing column is visible rather than silent.

Similar people and merging

The same human can enter the CRM twice: once from a spreadsheet and once from a form, or on two channels. The person's record lists Similar people: other records with the same email or phone number. The list is a suggestion, worked out when you open the record, and nothing is ever merged on its own.

Open a similar person to review the pair side by side and choose, field by field, which values survive. Merge combines the two into one record: channel identities, tags, and journals are combined, so every conversation either record had continues on the one you keep, and the other record is retired. Merging is permanent.

Progress is never lost in a merge. If the record you keep is still New and the other one has already been contacted, the kept record takes on the other's status, its outreach history, and any follow-up that was pending, so a person who reached out twice (say, once through Meta and once through your website) shows the message you already sent and stays in the follow-up cadence. Its "added" date becomes the earlier of the two, so the conversation view spans the whole relationship.

Automatic records for inbound conversations

By default, a Person record exists only when your team creates or imports one. The agent still answers unknown callers, but nothing it learns is kept. To give every inbound conversation a record, turn on Create records for inbound conversations under Capabilities · People fields:

  • Phone-verified channels (recommended): someone who messages in over RCS, SMS, WhatsApp, or Apple Messages gets a record immediately, holding the channel identity they wrote from. People on other channels get one once the agent learns a first fact about them, so drive-by conversations do not pile up empty records.
  • All channels: every new conversation creates a record right away.

A message from an identity a record already holds always goes to that record. A phone number on a profile never attaches a conversation: to connect a person your team entered with the number they message from, add that number as an identity on their record, or merge the inbound record into theirs. Sandbox conversations never create records; a persona is the Person record in those conversations.

Specialized fields

Anychat has first-class support for certain agent applications, and a few built-in Person fields exist to serve them. They are always present on the record, cost nothing to ignore, and never need to be configured for agents that do not use them.

Product interest

For agents that sell from a Things catalog: what the person said they are interested in. The value is stored as the person said it, whether typed on a form, picked from a list, or mentioned in chat, and is reconciled against the catalog at the moment it is used rather than at import time:

  • A value that matches a Thing exactly, by close match, or by a keyword in the Thing's details surfaces as the canonical Thing name everywhere, never the person's typo.
  • A vague or empty value ("not sure yet", "just looking", "n/a") is treated as interest not yet known. The agent does not assert a Thing the person never chose, and an Outreach opener that would have named the Thing drops that clause instead.

Because reconciliation happens at use time, renaming or adding Things takes effect immediately. There is nothing to re-import.

Funnel status

For agents that qualify: each person's position in a sales funnel, new, contacted, qualified, converted, or lost. The status advances automatically as the agent works (outreach marks a person contacted; qualification and booking move it further). Agents that are not qualifying anyone can leave every person at new; nothing else depends on it.

Assigned representative and scheduled calls

For agents that book calls with a team: each person can be assigned to one of the agent's representatives, and their record shows the calls the agent has scheduled. Both come from the scheduling feature, which also handles notifications, reminders, and calendar sync.

In the People list, the Scheduled Call column shows the person's next upcoming call; after that call's time passes, the most recent past call stays visible in gray. For the agent-wide list of every booking — including past and cancelled calls — see the Calls page in the sidebar (details).

What's next