TIATDC Intelligent Assistant
Sign In

Contacts

A contact is one person, as your workspace knows them. It's the join key that connects a lead form filled in last Tuesday, a ticket raised this morning, and the anonymous browser session both came from.

Conversation inbox

See every conversation and handoff in context

Open Conversations and filter the queue

Each agent keeps its traffic in Conversations. Filter between all conversations, waiting visitors, and active handoffs.

Open the conversation you need

Choose a thread from the inbox to read the visitor’s messages and the agent’s response in context.

Without it, every surface answers "who is this?" separately and none of them can answer "what else do we know about them?"

Contacts are on every plan. They're created automatically — there's nothing to enable.

How a contact gets created

Any identity that arrives with a valid email resolves to a contact:

  • A visitor submits the in-chat lead form.
  • A visitor submits a custom form containing an email field.
  • The agent raises a ticket with a requester email.
  • Something pushes a lead or ticket in through the Integration API.

Every one of those paths goes through the same resolver, so normalization and merge behaviour are identical no matter where the identity came from.

No email, no contact. A contact keyed on nothing is indistinguishable from every other anonymous visitor, and creating one per session would fill your workspace with rows that can never be joined to anything. Leads and tickets work fine without a contact — the link is simply absent.

Merge rules

These are deliberate, and worth understanding before you're surprised by one.

Contacts are per-workspace. They're keyed on (organization, email). One customer's history can never appear in another organization's dashboard.

Plus-tags and dots stay distinct. jo+shop@gmail.com and jo@gmail.com are two contacts. Gmail would deliver both to the same inbox, so merging them is usually right — but under-merging is recoverable with a manual merge, while a wrong merge shows one customer another customer's ticket history. That's not a mistake worth risking to save a click.

Details are filled in, never blanked. If a lead form gave you a name and a later ticket omits it, the name survives. A submission that knows less can't erase what an earlier one told you.

A returning visitor re-points, it doesn't duplicate. If a shared browser later identifies as a different person, the browser session attaches to the newer contact.

Anonymous sessions

Conversations don't carry a contact id — they're logged before anyone identifies themselves. So the link runs the other way: a visitor id (the anonymous browser identifier) is mapped to a contact the moment that browser hands over an email.

The practical effect: someone browses anonymously, chats with the agent, then fills in a lead form. That whole earlier session becomes attributable to them retroactively.

Where contacts show up

On a ticket. The detail view shows the requester's contact and their previous tickets. Previous tickets key on contact id, with an email fallback for tickets raised before contacts existed — so history isn't missing for older rows.

On a lead. Leads carry a contactId and expose it through the Integration API, so a Zap can key on the person rather than the submission.

Best practices

  • Ask for email early in the lead form. It's the only field that creates a contact, and everything downstream keys on it.
  • Turn on "Require an email" in the Helpdesk module if you intend to reply to tickets — it's both the reply address and the join key.
  • Use contactId, not email, in downstream automations where you have it. It survives the address changing.

Limits & notes

  • A dedicated contacts browser UI, custom attribute editing, and CSV import aren't shipped yet. Contacts are visible today in the surfaces that reference them (tickets, leads).
  • There's no public contacts endpoint yet. contactId is returned on leads and tickets through the Integration API.

Next steps