Contact Management

Contacts are the customer identity layer in RapiDesq. Every person who interacts with your organization — whether they chat, email, submit a form, or are imported from an external system — is represented by a contact record. Contacts aggregate all interactions across every channel into a single, unified profile, giving your users complete context for every conversation.

Overview

A contact record is the central identity for a customer within your RapiDesq tenant. Rather than treating each conversation or ticket as an isolated event, RapiDesq links them all back to a single contact. This means:

Contact records are automatically created and matched as interactions arrive. RapiDesq uses email address as the primary deduplication key, so when the same person reaches out through different channels using the same email, everything is linked to one contact. For logged-in users on your website, identity verification provides even stronger matching by verifying the visitor's identity with a signed token.

Key concept — Contacts are scoped to your tenant. Email-based deduplication, custom fields, and all contact data are isolated to your organization. No contact data is shared between tenants.

How Contacts Are Created

Contacts enter RapiDesq through several sources. Each contact record tracks its origin, so you always know how a customer first reached you. The contact source is set automatically at creation and preserved for reporting and auditing.

Chat Widget (Anonymous)

When an anonymous visitor starts a chat on your website through the RapiDesq chat widget, a contact record is created once they provide identifying information. This typically happens in one of two ways:

Contacts created this way have the chat widget source. Until the visitor provides an email address, they exist as an anonymous session without a linked contact record.

Authenticated Chat Widget

If your website uses identity verification on the chat widget, the visitor's identity is verified via a signed token generated by your backend. RapiDesq reads the verified claims (email, name) from the token and either matches an existing contact by email or creates a new one automatically. No pre-chat form is needed because the identity is already known.

Contacts created or matched this way carry the authenticated widget source and are marked as Verified in the user's view, providing a higher level of trust. See Identity Verification for setup details.

Inbound Email

When an email arrives at one of your connected email channels, RapiDesq extracts the sender's email address and display name. If a contact with that email address already exists, the inbound email (and its resulting ticket) is linked to that contact. If no match is found, a new contact is created with the email source.

This means a customer who first chatted with you and later sends an email using the same address will see both interactions on the same contact record — no manual linking required.

Web Form Submissions

When a visitor submits a web form, RapiDesq uses the email field from the submission to match or create a contact. If the email matches an existing contact, the form submission and resulting ticket are linked to that contact. Otherwise, a new contact is created with the web form source.

Custom data fields included on the form flow into the resulting record, so information like account number or product type is captured at the point of entry.

API and Webhook

Contacts can be created programmatically through the RapiDesq API or from inbound webhook events. This is useful for:

Contacts created via the REST API carry the API source; contacts created from inbound webhook events carry the webhook source. In both cases, email-based deduplication applies — if the email already exists on a contact, the existing contact is used rather than creating a duplicate.

Bulk Import

You can import contacts in bulk. Open the Contacts page and click Import to upload a file. Imported rows are matched by email address, and rows without a match create new contacts with the import source.

This is the fastest way to populate RapiDesq with your existing customer base when you first set up the platform.

Manual Creation

Contact records can also be created directly by your team — for example, to record a customer ahead of any digital interaction. Contacts created this way carry the manual source.

Source tracking — The contact source is set at creation and does not change, even if the customer later interacts through other channels. This gives you an accurate picture of how contacts originally entered your system. All subsequent interactions are tracked in the contact's journey timeline regardless of channel.

Email-Based Deduplication

Email address is the primary deduplication key for contacts within a tenant. Whenever an interaction arrives that includes an email address — whether from an inbound email, a chat widget pre-chat form, a web form submission, an API call, or an import — RapiDesq checks whether an active contact with that email already exists.

This automatic matching is the foundation of the unified contact profile. Consider this scenario:

  1. A customer named Sarah visits your website and starts a chat. The pre-chat form collects her email: sarah@example.com. A contact is created with the chat widget source.
  2. Two days later, Sarah sends an email to your support address from sarah@example.com. RapiDesq matches the sender to the existing contact. The email ticket is linked to Sarah's record.
  3. A week later, Sarah submits a web form using the same email. Again, the form submission is linked to her existing contact.

The result is a single contact for Sarah with a complete timeline of all three interactions across three different channels. Her user can see the full picture without any manual effort.

Best practice — To maximize the effectiveness of automatic deduplication, always collect an email address as early as possible. Configure pre-chat forms on your chat widget and include an email field as required on your web forms. The sooner RapiDesq has an email address, the sooner it can link interactions to the right contact.

Contact Profiles

Every contact has a profile that serves as the central record for that customer. The profile contains:

Field Description
Name The customer's name, collected from any channel.
Email address The primary identifier, used for deduplication. Required for automatic cross-channel matching. A contact can carry additional email and phone identities beyond the primary one.
Phone number Optional phone number for the contact.
External IDs Identifiers from external systems (for example, your CRM record ID), so integrations can link records both ways.
Source How the contact was originally created: chat widget, authenticated widget, email, web form, API, webhook, import, or manual.
Status Current state: Active, Merged, or Deleted. See Contact Statuses.
Verification Whether the contact's identity has been verified via identity verification with a signed token.
Tags & notes Free-form tags for segmentation and a user notes thread on the contact.
Custom fields Tenant-defined fields scoped to contacts. See Custom Fields.
Activity First seen, last seen, conversation count, and the full interaction journey across every channel.
Created / Updated Timestamps for creation and the most recent change (stored in UTC, displayed in your timezone).

Users see the contact's details in a panel alongside the ticket when handling a conversation. This gives them immediate access to the customer's identity, history, and any custom data your team has captured — without leaving the conversation view.

The Contacts page showing the searchable contact list with name, email, phone, status, and source columns The Contacts page: search the directory, open a profile, import in bulk, or select rows for bulk actions.
Tip — Encourage users to verify and update contact details during interactions. A customer may have changed their phone number or name since their last interaction. Keeping profiles current improves the quality of your customer data and makes future interactions smoother.

Custom Fields

Custom fields extend contact profiles with data specific to your business. Fields are defined centrally in Admin > Custom Data and can be scoped to contacts, tickets, or both. Contact-scoped fields appear in the Custom Fields section of the contact profile, where users can view and edit them during conversations.

Defining Custom Fields

Eight field types are available — Text, Email, Phone, Select from List, Number, Text Area, Checkbox, and File Upload — each with optional validation rules and a required flag. See Custom Fields & Custom Data for the full reference.

Populating Custom Fields

Custom fields can be populated through several mechanisms:

Example Custom Fields

Identity Verification

Identity verification lets you confirm the identity of visitors who use the chat widget on your website. When a logged-in user on your site opens the chat widget, your backend generates a signed token (a JWT) containing the user's identity claims. RapiDesq verifies the token's signature and links the chat session to the verified contact. This eliminates the need for a pre-chat form for known users and provides a strong guarantee of the visitor's identity.

How It Works

  1. Create an identity verification profile in the admin area under Identity Verification Profiles. A profile names a signing algorithm (RSA, ECDSA, or EdDSA) and holds the public key used to verify tokens. Profiles are managed at the tenant level so the same signing material can be reused across many widgets and rotated in one place.
  2. Assign the profile to your chat widget. In the widget's configuration, select the identity verification profile. Visitors must then present a valid identity token signed with the matching private key; leaving the widget on "None" allows anonymous visitors.
  3. Sign tokens on your backend. When a user is logged in to your website, your server signs a token containing the user's identity claims (email, name) with your private key and passes it to the widget when initializing it on the page.
  4. RapiDesq verifies the token against the profile's public key. If the token is valid, RapiDesq reads the claims and either matches an existing contact by email or creates a new verified contact.
  5. The chat session is linked to the verified contact, and the user sees the contact marked as Verified.

Claim Mappings

Beyond the core identity claims, you can map additional token claims onto the contact: a claim can populate a standard contact field, a custom field, or select a rate-limit tier for the session. Nested claims are supported with dot notation (for example, metadata.plan). This lets your application pass rich, verified context — plan level, account ID, region — straight into the contact profile with no form-filling.

Why It Matters

Configuration details — For step-by-step widget setup, see the Chat Widget documentation. Identity verification profiles are managed centrally, so rotating a key updates every widget that references the profile.
Security — Profiles use asymmetric signing: your private key stays on your servers and only the public key is stored in RapiDesq. Never expose the private key in client-side code — tokens must be generated on your backend. To rotate keys, paste the new public key into the profile and every linked widget picks up the change.

Merging Contacts

Despite automatic deduplication, duplicate contacts can still occur. For example, a customer may have chatted anonymously (without providing an email) and later sent an email, resulting in two separate contact records. Contact merging lets you unify these duplicates into a single record.

When to Merge

Common scenarios where merging is needed:

Merge Process

  1. Open the contact you want to keep — this is the target, whose profile details (name, email, phone) will remain.
  2. Choose Merge Contacts from the contact's actions.
  3. Search for the duplicate contact — the source — that will be merged in.
  4. Review the side-by-side comparison of the two records, labeled Source (will be merged) and Target (will remain), including each record's conversation count.
  5. Confirm the merge. All identities, tags, and conversation history from the source are transferred to the target, and the source's status is set to Merged.

What Happens After a Merge

Warning — Contact merging cannot be undone. Always verify that you are merging the correct records before confirming. Double-check that the target contact is the one you want to keep, as its profile details (name, email, phone) are preserved while the source's profile details do not carry over.

Contact Statuses

Every contact has a status that reflects its current state in the system:

Status Meaning
Active The normal operational state. The contact is visible in search results, can receive new interactions, and appears in all standard views. All contacts start in this state when created.
Merged The contact has been merged into another record. Its tickets and conversations have been transferred, and the record is preserved for audit purposes with a reference to the surviving contact. New interactions will not be linked to a merged contact.
Deleted The contact has been deleted. The record is removed from normal views and search results. See Deletion and Data Retention below.

Deletion and Data Retention

When you delete a contact, the record is immediately removed from all normal views and search results, but the deletion is recorded with a timestamp so it remains auditable. Permanent erasure of personal data is handled through the platform's privacy request workflow, which supports data subject requests such as export and erasure — see the Privacy Requests area in Admin for details.

Note — Deleted contacts cannot be matched by the deduplication system. If a new interaction arrives with the same email address as a deleted contact, a new contact will be created. This ensures that deletion is respected while still allowing new interactions from the same email address.

Interaction Journey

Each contact profile includes a Journey tab — a unified, chronological timeline of everything that has happened with that customer, across all channels.

What the Timeline Shows

Journey events are categorized so you can see at a glance what each entry represents:

The journey can be viewed as a flat list of all events or grouped into interaction sessions, each with its own duration and expandable timeline — useful for contacts with a long history.

Using History During Conversations

When a user is handling a live conversation or working on a ticket, the contact's details and history are available in the side panel. This gives the user immediate context:

This context helps users provide faster, more personalized support without asking the customer to repeat information from previous interactions.

Tip — When handling a conversation with a returning customer, take 10 seconds to scan their recent journey. Acknowledging their previous issue ("I see you contacted us last week about X — was that resolved?") makes a significant difference in customer satisfaction and demonstrates that your team values their time.

The Contacts Page

The Contacts page is the directory of every contact in your tenant. It is available to any user with the contacts view permission.

The search bar matches contacts by name or email address, with results updating as you type. Each row shows the contact's name, email, phone, status, source, and creation date; clicking a row opens the full profile.

Bulk Operations

Select multiple contacts to act on them together:

Import

The Import button on the Contacts page starts a bulk import, the fastest way to bring an existing customer base into RapiDesq (see Bulk Import).

Tips & Best Practices

Maximize Deduplication Accuracy

Maintain Data Quality

Make the Most of Custom Fields

Optimize User Workflow

The payoff — Clean, well-maintained contact data is the foundation of effective customer support. When every interaction is linked to the right contact, users have complete context, reporting is accurate, deduplication works reliably, and customers never have to repeat themselves. Investing in contact data quality pays dividends across your entire support operation.