Integrations
How integrations work: look up, write back, take action, notify
The four ways the agent works with your systems during and after a conversation, and what happens when a system does not respond.
On this page
- The four operations at a glance
- 1. Look up: facts from your systems, during the conversation
- The technical detail
- 2. Write back: the record ends up where your team works
- 3. Take action: the work gets done in your systems
- 4. Notify: telling your team when something needs it
- When one of your systems is slow or unavailable
- The technical detail
- In practice
- What your team controls
- Related
A customer judges an answer by whether it is true for them: their booking, their unit, their claim. The agent gets there by working with your systems in four ways. It looks up facts while the customer is talking, writes the outcome back when the conversation ends, takes action in your systems when the customer asks for something to be done, and notifies your team when something needs a person. This page explains each of the four, and how the connections behave when one of your systems is slow or unavailable.
The four operations at a glance
| Operation | When it happens | What it touches | Typical permission |
|---|---|---|---|
| 1. Look up | During the conversation | Your CRM (the system that holds your customer records), operational systems and approved documents | Read |
| 2. Write back | At the end of the conversation, and as details are confirmed | Your CRM and operational systems | Write, limited to named records and fields |
| 3. Take action | During the conversation, when the customer asks for something to be done | Calendars, service desk, booking, property or claims systems, payment provider | One permission per action |
| 4. Notify | When a trigger you set is met | Your team's messaging channels, and your customers | Post to named channels |
1. Look up: facts from your systems, during the conversation
The agent fetches real information from your systems while the conversation is happening. A buyer asking what they owe next hears their own schedule. A guest asking about their stay hears their own reservation. A policyholder asking where their claim has got to hears its actual status.
Anything that could create an obligation for you, such as a price, a date, an entitlement or a policy term, comes from your systems or your approved documents rather than from the language model (the AI component that understands the conversation and composes the reply). When the answer is not in those sources, the agent says so and offers a person. It does not fill the gap.
The technical detail
Lookups go through each system's API (application programming interface: the documented way other software exchanges data with it), using a read permission on the integration account for that system. Figures such as amounts and dates are inserted into the reply directly from the system record, not retyped by the model. Each lookup is logged with the system, the record it read and the conversation it served, so a reviewer can see where every fact in an answer came from.
2. Write back: the record ends up where your team works
When a conversation ends, the agent writes a structured record into your systems: a summary, the outcome (resolved, still open, or handed to your team), the details captured during the conversation, and the next steps. A lead is created or updated in your CRM. A booking change, a maintenance request or a claim note is written to the operational system where the work lives, often called the ERP (enterprise resource planning: the system that runs a business's core operations).
Your CRM stays the system of record for customer and account data. The Telonic customer record is the system of record for conversation history, and each conversation is linked to the right customer by verified identifiers: phone number, email address, customer ID, and booking or policy reference. Where a match is uncertain, it is suggested to a person on your team to confirm rather than written automatically. See The customer record.
3. Take action: the work gets done in your systems
When a customer asks for something to be done, the agent does it during the conversation, within the actions your team has granted. The common actions are below. Industry actions, such as changing a reservation or logging a claim, are set out on the Property, Travel and hospitality and Insurance pages.
| Action | What happens | Example |
|---|---|---|
| Book an appointment | The agent books directly into the right calendar, then confirms with the customer | A viewing booked into the sales team's calendar for Saturday at 11am |
| Open a ticket | A ticket is created in your service desk with the full conversation attached | A billing query raised with the finance team, with the guest's invoice reference |
| Send a payment link | A link from your payment provider is sent in the conversation. Configured during implementation with your provider | A buyer receives a link to pay a registration fee |
| Send a document | A quote, confirmation or statement is produced from your template and sent. Configured during implementation for the documents you choose | A booking confirmation sent by email after a change of dates |
Actions you mark as sensitive, such as a refund or a change to a payment plan within policy, are prepared by the agent and held until a person on your team approves them. Decisions that belong to your people, such as approving a claim, are not connected to the agent at all. See Permissions.
The agent never sees or handles card details. It sends a link from your payment provider, so card data stays with that provider. See Payments.
4. Notify: telling your team when something needs it
Some moments need a person to know straight away: a buyer who is ready to reserve, a policyholder who mentions an injury, a guest whose complaint is escalating. The agent posts an alert with a short summary into the channel your team already uses, such as Microsoft Teams or Slack. Notifications are configured during implementation for the triggers and channels your team chooses. See Team messaging.
Notifications to customers work through the same connections: a WhatsApp update when a claim moves stage, or a reminder the day before a viewing, sent within the consent and contact rules you set. See WhatsApp: message templates and outbound messages.
When one of your systems is slow or unavailable
Every write is designed to complete in full or not at all, so a customer record is never left half updated. If a system does not respond, the agent tries again a set number of times. If it still cannot complete the task, it tells the customer plainly what happens next, and the failed task is shown to your team with everything needed to finish it.
The customer is not left waiting on a system that is down. Where the task matters to them, such as a rebooking during delays and cancellations, the agent hands the conversation to a person with a brief, as it would for any request it cannot complete.
The technical detail
| Behaviour | How it works |
|---|---|
| Retries | Failed calls are retried automatically, with a growing interval between attempts, so a busy system is not overloaded |
| No partial writes | Writes are idempotent (repeating the same request produces the same result, never a duplicate), and a write that involves several records either completes for all of them or for none |
| Failures surfaced | A task that cannot complete is recorded against the conversation and shown to the people you name, with the request, the error returned and the customer's details |
| Monitoring | Telonic monitors every connection and is alerted to repeated failures, so a problem is usually found before your team reports it |
| Logging | Every call, successful or not, is logged in the audit trail with its result. See Audit trail and decision records |
In practice
Sahel Crest Properties, a Dubai developer, connects its CRM, its handover calendar and its maintenance system.
- Rania, a buyer, calls about her unit. The agent confirms her identity with the checks the developer has set, then looks up her payment schedule in the CRM and reads her the next instalment and its due date.
- She asks to book her handover inspection. The agent checks the handover team's calendar and books her into Tuesday at 10am.
- She mentions a crack in a bathroom tile noticed on a previous visit. The agent creates a maintenance request against unit C-0807, with her description.
- When the call ends, the summary, the booking and the maintenance reference are written to her record in the CRM.
- The maintenance system is briefly unavailable when the request is sent. The agent retries, the request goes through on the second attempt, and the audit trail shows both calls.
What your team controls
- Which systems the agent reads from, and which it writes to.
- Which actions it can take in each system, and which need a person's approval.
- Which triggers send a notification, and to which channel.
- Who is shown a task that could not be completed.
Related
- Integrations overviewIntegrations
- PermissionsIntegrations
- How an agent worksAgents
- The customer recordCustomer record
- Audit trail and decision recordsGovernance and control
Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.