People¶
People is the built-in CRM. Each agent keeps one Person record for every human it talks to, and that record is the single source of truth about that person for both your team and the agent. Your team creates and edits records in the console; the agent reads the record during every conversation and, when you allow it, writes back what it learns. There is no external system to connect. For the conceptual overview, see the Agent Framework.
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 product 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 |
| Used to de-duplicate imports | |
| Phone | Stored in international format; required to reach out on phone-based channels |
| Company | |
| Title | |
| Source | Where the person came from (a campaign, a referral, 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 |
| External ID | Optional correlation id from an outside system, such as a CRM row id. Matched exactly on import |
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. Contact details the agent learned in conversation are marked unverified; saving an edit yourself is what verifies them. 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 Settings · 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, orenum. 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 and tester 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, continue with Reaching Out to People.
Working with the list¶
The People page searches by name, email, phone, or company, filters by funnel status or flagged duplicates, and loads long lists in pages, newest first. Export downloads the people in the current view as a CSV whose columns match the import template, so the file can be edited and re-imported, or loaded into another tool. The export includes each person's core fields, custom fields, tags, and identifiers; it does not include conversation transcripts.
Filtering and segments¶
The filter bar narrows the list further: by tag, by source, by whether a phone number is on file, and by reachability (whether the last outreach attempt found the person reachable over RCS). Filters combine, so one view can hold, say, everyone tagged from a webinar who has a phone number 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.
Importing people¶
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.
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 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, campaign |
| Notes | notes, note |
| Funnel status | status |
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
numberfield, a value outside anenum's allowed set) is reported with its row and reason. The rest of the row still imports.
Matching and update modes¶
A row that matches an existing person by External ID or by email updates that person instead of creating a duplicate, so importing the same list twice is safe. 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.
- Update matched records: the row's non-empty values overwrite the record's. Locked fields are never overwritten in either mode.
A row that matches another record only by phone number is imported as a new person and the pair is flagged for review (see Duplicates).
Duplicates and merging¶
The same human can enter the CRM twice: once from a spreadsheet and once from a form, or under two email addresses. Anychat flags likely pairs as records arrive, matching on External ID, email, or a phone number your team entered. A flagged row shows a warning badge.
Open the badge to review the pair side by side and choose, field by field, which values survive. Merge combines the two into one record: conversation identities, tags, and journals are combined, and the other record is retired. Merging is permanent. If the two are different people, choose Not duplicates and the pair is never flagged again.
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 lead 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.
Anychat never merges records on its own. The one exception is safe by construction: when your team adds a person whose phone number matches someone who already messaged in on that number and whose record has never been edited, the empty inbound record folds into yours.
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 Settings · People fields:
- Phone-verified channels (recommended): someone who messages in over RCS, SMS, WhatsApp, or Apple Messages gets a record immediately, identified by their carrier-verified number. Webchat visitors get one once the agent learns a first fact about them, so drive-by visits do not pile up empty records.
- All channels: every new conversation creates a record right away.
If the number matches a person your team already entered, the conversation attaches to that record instead of creating a new one. Test traffic from the emulator and invited testers never creates records.
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 product 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 product exactly, by close match, or by a keyword in the product's details surfaces as the canonical product 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 product the person never chose, and an outreach greeting that would have named the product drops that clause instead.
Because reconciliation happens at use time, renaming or adding products 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).
The tester form mirrors real intake¶
When you invite a tester (Settings · Testers), the form they fill in is generated from this same configuration: the agent's People fields plus the core contact fields. A tester therefore submits exactly what a real intake form would carry, and the agent behaves the same way it will in production, including the handling of a vague product interest.