Connecting an AI agent to a CRM starts with rules for data and operations. A persuasive conversation does not establish a reliable customer record. You need to identify the person or organisation, determine which information is current and decide when an employee must review a proposed change. This guide helps define the assignment before granting extensive system access.
The examples describe a fictional service business preparing incoming enquiries. The agent gathers information and suggests next steps; the application controls the connection and checks actual processing. This is a design example rather than a working integration or customer result. Available operations depend on the API, subscription and configuration of the specific CRM you use.
Choose one business event
Start with a recognisable event: a new enquiry, a rescheduling request or a completed customer conversation. Describe what happens before and after it. “Keep the CRM updated” contains too many different decisions. A useful first release might simply create a draft task against an existing customer record after somebody has reviewed the enquiry.
Record the source of each event and assign responsibility for follow-up. Creating a task does not mean the agent has resolved the customer’s request. Employees need to see ownership, missing information and the expected next step. Use understandable states that fit the existing process rather than creating a second administration hidden inside a conversational interface or an integration dashboard.
Identify the correct customer
Matching by name alone is not enough to merge customer records. Different organisations may use the same trading name, employees change employers and email addresses can have several contact roles. Prefer established identifiers, such as a customer number from an authenticated environment. Without them, the application can present candidates for review rather than choosing one automatically.
Define when creation of a new record is permitted. An unfamiliar email address does not necessarily represent a new customer; the organisation may already exist with a different contact. Distinguish no match, one confirmed match and several possible matches. Each state needs its own next step. The model must not fill a gap in certainty with a name that merely seems plausible.
Define the contract for each field
Create a compact specification for fields such as customer number, contact person, enquiry type, preferred date and summary. Record the source, meaning, accepted values and whether the field is required. Explain how missing and conflicting information is handled. An absent preferred date, for example, must not silently become today’s date simply to satisfy a required field.
Decide which system is authoritative for each field. The CRM may own the official customer number while a scheduling system owns the current appointment status. Do not let an agent treat a cached copy as definitive. When information conflicts, consult the authoritative source again or ask an employee. A polished summary should never make an outdated arrangement appear settled or newly confirmed.
An agent does not remove the need for clear identity and data ownership. This integration guide covers that foundation: Connect CRM and accounting: agree customers, orders and invoice boundaries.
Separate suggestions from writes
Let the agent prepare a structured proposal containing explicit fields. The application then validates completeness, data types, record access and the permitted operation. Function calling supports this division: the model requests a tool while application code carries out the actual processing. Using a model does not eliminate the need for ordinary API validation or business-rule checks.
A draft must remain visibly provisional until the change is confirmed. Show which record will change and the proposed values. Immediately before writing, check whether the relevant record version still matches. If a colleague has made an update, another review may be preferable to committing the older suggestion. Approval should not silently extend to other records or subsequent changes outside the reviewed proposal.
Handle repeats and uncertain results
The same enquiry can arrive again after a double click or lost connection. Give the business event a stable reference and track processing against it. Following an uncertain API response, check whether the task already exists before attempting another write. Blind retries can produce duplicate follow-up work and inconsistent messages from different employees to the same customer.
Distinguish received, proposed, approved, processed and under investigation. During a failure this reveals whether an employee still needs to act. Show “completed” only when there is enough evidence of the intended CRM change. If the connected product provides limited confirmation, document that constraint and create a manual check employees can realistically perform using their available access and operational screens.
Illustrative enquiry with an awkward exception
A fictional customer emails an equipment-maintenance request and includes an old site address. The agent identifies the maintenance task and retrieves possible customer records. There are two locations. Instead of creating another customer or changing an address, it asks which location is intended. An employee then reviews the evidence and links the enquiry to the correct existing record.
Once confirmed, a draft task contains the original question, selected location and the still-missing preferred date. The employee can inspect both the source and its summary. Saving assigns an enquiry reference. If the connection fails, the integration searches for that reference before another attempt. Recovery therefore does not automatically create a second task assigned to a different colleague.
Test more than successful data entry
Use test records for an existing customer, an unknown organisation and two almost identical names. Include revoked access, missing required fields and a record changed after the suggestion was prepared. Check what employees see and what is actually stored in the CRM. An elegant chat response is insufficient if the wrong contact record has changed behind the interface.
Test repeated requests and a failure after the write may already have succeeded. Ask somebody without development expertise to investigate using the available screens and logs. If they cannot determine the actual outcome, an operating capability is missing. Retain these cases so that CRM upgrades and changed agent instructions can later be checked against the same expectations.
Agree operational ownership and handover
Assign ownership for field mappings, access and failure notifications. Describe who reviews outstanding cases and how that fits normal working arrangements. A technical alert alone cannot resolve an incomplete customer request. Employees should be able to recover the original information without copying entire confidential conversations into every log or dashboard for convenience.
At handover, record the API functions in use, how credentials are renewed and how processing is paused. Have an operator recover a fictional stuck request and verify that the ordinary enquiry route remains available. Extend the connection to new record types or external messaging only once the current data flow can be understood, investigated and maintained by the responsible people.
Turn the explanation into a project decision
Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.
Open the preparation tool ↗Questions about this topic
Can the agent create customers automatically?
The CRM may support it, but the process needs explicit rules for identity, duplicates and required information. Starting with an employee-reviewed proposal can be useful. Available functions and limitations must be investigated for the actual CRM and subscription.
Does the model need the entire CRM?
No. Select information needed for the bounded task. Classifying an enquiry usually requires less than investigating a complete case. Record which fields are shared, with which service and for what purpose, then check the implementation against that specification.
What if our CRM lacks a suitable API?
Investigate supported imports, existing connectors or a different process design first. Avoid assuming every system is straightforward to connect. Preparing a reviewed draft outside the CRM may be the better initial step until a dependable input route is available.
Continue with a related question
Which permissions should an AI agent receive?
Design bounded AI-agent permissions for reading, proposing and executing, with approval boundaries, practical access checks and recovery examples.
AI agents & chatbotsFrom AI agent to employee: design a useful handover
Make AI-agent handover work by recognising boundaries, preserving context, assigning ownership and preventing duplicate follow-up.
AI agents & chatbotsOperating an AI agent: monitoring, changes and recovery
Plan AI-agent operation with useful alerts, usage limits, source ownership, regression checks, pausing and a workable recovery route.
APIs & integrationsConnect CRM and accounting: agree customers, orders and invoice boundaries
Design a CRM-accounting integration with stable identity, field ownership, clear invoice actions and controlled introduction.
Sources and technical background
- OpenAI: Function calling ↗
Tool calls are proposals processed by application code; the application remains responsible for actual execution.