Přeskočit obsah

How Customer Data Works

Daktela keeps what it knows about your customers in a small set of linked objects: contacts (people), accounts (companies), CRM records (deals, contracts, cases), tickets (requests) and campaign records (rows in an outbound calling list). Every call, email or chat is an activity that links back to them, so an agent who opens a customer sees the whole history in one place.

This page explains the model, untangles the different things Daktela calls a "database", and ends with a setup path for a new instance.

The Building Blocks

Object What it is Example Belongs to Where you set it up
Contact A person you talk to. Daktela matches calls, emails and messages to contacts by their phone numbers and email addresses. Jane Novak, +420 777 123 456 One CRM database; optionally one account Contact form in Settings → CRM → Databases
Account A company or organisation. Several contacts can belong to one account. An account can carry its own SLA, which overrides the ticket category SLA for tickets of its contacts. ACME Ltd. One CRM database Account form in Settings → CRM → Databases
CRM record A piece of business information that outlives a single conversation, such as a deal, contract, order or complaint. It has a status and a stage (Open or Close). "ACME — 2027 service contract" One CRM record type; optionally linked to a contact, an account and a ticket CRM Record Types in Settings → CRM → Records
Ticket A customer request tracked until it is solved, usually created from an email. "Invoice 1042 is wrong" One ticket category; linked to a contact How the Helpdesk Works
Campaign record One row in an outbound calling list: who to call, when, and the answers the agent saved. It has an action (Ready, Rescheduled, Done…) and a next call time. "Call Jane about her renewal" One call script; optionally one campaign database; optionally linked to a contact Call Scripts in Settings → Call Scripts
Activity One call, email, chat, SMS or message handled in a queue. Jane's call on Monday at 10:02 A queue; linked to the contact, the ticket and the campaign record it belongs to Queues

How They Fit Together

erDiagram
    CRM_DATABASE ||--o{ CONTACT : holds
    CRM_DATABASE ||--o{ ACCOUNT : holds
    ACCOUNT |o--o{ CONTACT : "has people"
    CRM_RECORD_TYPE ||--o{ CRM_RECORD : "defines form of"
    CONTACT |o--o{ CRM_RECORD : "linked to"
    ACCOUNT |o--o{ CRM_RECORD : "linked to"
    TICKET |o--o{ CRM_RECORD : "linked to"
    TICKET_CATEGORY ||--o{ TICKET : holds
    CONTACT |o--o{ TICKET : raises
    CALL_SCRIPT ||--o{ CAMPAIGN_DATABASE : contains
    CALL_SCRIPT ||--o{ CAMPAIGN_RECORD : "defines form of"
    CAMPAIGN_DATABASE |o--o{ CAMPAIGN_RECORD : groups
    CONTACT |o--o{ CAMPAIGN_RECORD : "linked to"
    CONTACT |o--o{ ACTIVITY : "takes part in"
    TICKET |o--o{ ACTIVITY : contains
    CAMPAIGN_RECORD |o--o{ ACTIVITY : "called in"

Read it like this:

  • Contacts and accounts always live in a CRM database. The database decides which form they use, which agents can see them and which queues look them up.
  • CRM records hang off contacts, accounts or tickets. Their CRM record type defines their form, statuses and tabs.
  • Tickets belong to a category and point to a contact. The contact's account is reached through the contact.
  • Campaign records belong to a call script (their form) and can be grouped into campaign databases inside that call script. They can point to a CRM contact.
  • Activities tie it all together: a call is linked to the contact it was matched to, the ticket it was merged into and the campaign record it was dialled for.

Four Things Called "Database"

The word "database" means different things in different parts of Daktela. They are not connected to each other.

What you see What it holds Where Used for
CRM database Contacts and accounts Settings → CRM → Databases — see Databases Separating customer groups (brands, countries, teams), choosing the contact and account forms, deciding who sees which customers and which queues recognise them.
Campaign database (inside a call script) Campaign records Settings → Call Scripts, Databases relation — see Call Scripts – Databases Splitting one calling list into batches you can switch on and off, prioritise and mix.
Blacklist database Rules for banning customers (how long a ban lasts, how web chat bans work) Settings → CRM → Blacklist database — see Blacklist Database Letting agents ban abusive callers or chatters, and blocking banned customers from your queues.
Knowledge base folders Articles, not customer data Settings → Knowledge base → Folders — see Knowledge Base Settings Organising internal articles and deciding who can read and edit them. Listed here only because the docs group it with the databases.

Tip

When a colleague says "add it to the database", ask which one. Importing customers into a CRM database does not make them callable in a campaign — for that they must become campaign records (see Export from CRM to Records).

Two Pools of Custom Fields

The forms above are built from custom fields, and there are two separate pools of them:

  • Tickets and CRM — ticket category forms, contact forms, account forms and CRM record type forms all share one set of fields. A Customer ID field you create for contacts can also be placed on a ticket form, and editing the field changes it everywhere.
  • Call scripts — call scripts (including custom call scripts) have their own set. A field you need on both a contact and a campaign record has to be created twice, once in each pool. When you export contacts into campaign records, you pair the fields of the two pools.

The form builder works the same in both pools — see Custom Fields & Forms.

Warning

Daktela recognises customers by the Phone and Email type fields on the contact form. A contact without a value in a field of those types cannot be matched to an incoming call or email.

What Agents See

  • During an activity, Daktela looks for a contact whose phone number or email address matches the customer — but only among the CRM databases linked to the activity's queue. If one contact matches, it opens in the activity; if several match, the agent can switch between the suggestions; if none matches, the agent can create a new contact or link an existing one.
  • In the CRM module (CRM → Contacts, Accounts, Records), agents browse and edit customers. A contact's detail shows its activities, tickets, records and attachments, and the customer journey. See CRM.
  • On campaign queues, agents fill in the call script form for each campaign record they call.
  • Visibility follows user rights. An agent sees only the contacts and accounts in the CRM databases their user rights grant (the CRM database tab), and only the CRM records of the CRM record types they grant (the CRM record types tab). What the agent may do with them — open, create, edit, delete — is set by their access. A user who has access to Contacts uses a CRM licence.

Set Up Your Customer Data

Minimum Path

This gets caller recognition and a basic contact list working.

  1. Check your CRM database. Go to Settings → CRM → Databases. Contacts and accounts must belong to a database, so you need at least one. If one exists, open it and tick Default; otherwise click Add new, give it a Title and tick Default. The default database is pre-selected when agents create contacts, and every queue you create after setting it is linked to it automatically.
  2. Build the contact form. In the Form column, click Contacts and add at least one Phone field and one Email field, plus anything your agents need on every call. See Contacts Database Form Settings. If you serve companies, build the account form too.
  3. Link the database to your queues. Queues created before the database became the default are not linked. In the database list, click Queues in the Relations column and tick every queue that should recognise these customers (or use the CRM databases relation in the queue list).
  4. Give agents access. In each agent's access, grant the CRM permissions on Contacts (and Accounts if you use them), and add the database to the CRM database tab of their user rights.
  5. Load your customers. Import an existing list with Import in CRM → Contacts, or let agents create contacts as customers get in touch.
  6. Test. Create a test contact with your mobile number, log in to an inbound queue and call in. The contact should open in the activity.

Recommended starting point

One CRM database marked Default, linked to all your queues; a contact form with Phone and Email fields; Contacts permissions in every agent access and the database in every agent's user rights. Add the rest only when you need it.

When to Add More

You need… Add See
To serve companies with several people each The account form, and link contacts to accounts Accounts Database Form Settings
To keep two customer groups apart (brands, countries, partners) A second CRM database, linked to its own queues and user rights Contacts Database Form Settings
To track deals, contracts, orders or complaints over time A CRM record type with its own form and statuses CRM Record Types
To filter, report or route by customer information Custom fields in the Tickets and CRM pool Custom Fields & Forms
To call a list of customers A call script and a campaign queue Set Up Campaigns
To stop abusive callers or chatters A blacklist database, linked to your queues and allowed in user rights Blacklist Database
To push work items from your own systems to agents A custom call script and a custom queue How Custom Queues Work
A web page from your own system inside a contact, account or record A tab Tabs

Go Further