Implementation Guide
Planning CRM and Calendar Integrations for Call Automation
An AI receptionist is only as useful as the records it leaves behind. This guide covers the integration decisions to settle before configuration: what writes where, which system is authoritative, and what happens when a connection fails.
Start with the system of record
Before discussing connections, name the single system that holds the truth for appointments and the single system that holds the truth for customer records. Everything else either reads from those systems or writes into them.
Most integration problems are really ownership problems. Two calendars that both accept bookings will eventually produce a double booking, and two customer databases will eventually disagree about a phone number. Decide the hierarchy first and the technical work becomes straightforward.
Then decide what a completed call must leave behind. A booking with no enquiry record, or an enquiry record with no owner, creates work rather than removing it.
Four ways systems connect
Connection type affects reliability, cost and how quickly changes can be made. Confirm which applies to each of your systems before assuming a workflow is possible.
| Connection | How it works | Best suited to | Watch for |
|---|---|---|---|
| Native | A supported, prebuilt connection to a common platform | Mainstream calendars and widely used CRMs | Feature coverage may not extend to every custom field |
| API | Direct connection built against the platform interface | Systems with documented, stable interfaces | Rate limits, authentication renewal and version changes |
| Automation platform | Middleware such as Zapier or Make passes data between systems | Quick connections and low volumes | Added latency, platform costs and an extra failure point |
| Custom | Bespoke integration built for your environment | Legacy, on-premise or in-house systems | Longer build, ongoing maintenance ownership |
We will confirm which category applies to your specific systems rather than assuming. If a connection is not available, the honest answer is a defined manual step, not a workflow that quietly fails.
Decisions to settle before the build
Field mapping
List every field a new record must contain and mark which are mandatory. If your CRM rejects records without a source or owner value, the receptionist must capture or set it during the call.
Duplicate handling
Decide how an existing customer is recognised, usually by mobile number, and whether a repeat caller updates the existing record or creates a new enquiry against it.
Booking rules
Appointment length by service, buffers between appointments, travel time, maximum bookings per slot and which staff members are bookable all need to be explicit before the calendar is connected.
Availability windows
Define how far ahead bookings may be made, the minimum notice required, and how public holidays and staff leave are reflected. Calendars that are not kept current will produce bookings nobody can honour.
Ownership and routing
Every created record needs an owner and a next action. Decide whether assignment is by service, by location, by round robin or by a single triage queue.
Access and permissions
Grant the narrowest access that supports the workflow, and record who authorised it. Review authentication renewal, because expired credentials are a common cause of silent integration failure.
Plan for the connection failing
Integrations fail occasionally: credentials expire, platforms have outages, and rate limits are reached during a busy hour. The important design question is what the caller experiences when that happens.
- Calendar unavailable: offer a callback to confirm timing rather than promising a slot that was never written
- CRM unavailable: capture the enquiry and deliver it by an alternative route your team monitors
- Partial write: define which system is retried and who checks for orphaned records
- Silent failure: agree who is alerted, and how quickly, when writes stop succeeding
- Recovery: decide whether queued records are written retrospectively or handled manually
Never let a failed write become a false confirmation. A caller told their appointment is booked will arrive whether or not the calendar received it. Where confirmation cannot be verified, the receptionist should say that the booking will be confirmed shortly and route it for human completion.
Questions to ask about data handling
Call automation moves personal data between systems, so treat integration planning as a data question as well as a technical one. Ask these of any provider, including us, and record the answers.
- What personal data is captured, and which fields are genuinely necessary
- Where recordings, transcripts and enquiry records are stored, and for how long
- Who inside your organisation can access them, and how access is reviewed
- What is shared with any middleware or automation platform in the chain
- How consent and notification are handled where calls are recorded
- How data is deleted on request, and how deletion propagates to connected systems
Your obligations under the Personal Data Protection Act depend on your own circumstances, and you should confirm them with your own advisers rather than relying on a supplier assurance. We describe how we handle data and what you control; we do not certify your compliance. Our guidance on PDPA and call recording covers the general position.
Frequently asked questions
Do we need a CRM to use an AI receptionist?
No. Enquiries can be delivered to a shared inbox or messaging channel. A CRM makes follow-up and reporting easier, but the receptionist can work without one provided somebody owns the follow-up.
Can the receptionist read our calendar as well as write to it?
Where the connection supports it, yes, which is what allows real availability to be offered rather than a request for a callback. Read access must be granted deliberately, so confirm it during setup.
What if our booking system has no integration option?
The practical alternatives are a structured message to whoever manages the diary, or a callback to confirm timing. We would rather define a clean manual step than pretend a connection exists.
Can bookings be made across multiple locations or practitioners?
Yes, provided the rules are explicit: who can be booked for what, at which location, and how the receptionist should choose when the caller has no preference.
How do we avoid duplicate customer records?
Match on a single reliable identifier, usually the mobile number, and decide in advance whether a match updates the existing record or attaches a new enquiry to it.
Who owns the integration once it is live?
Name someone on your side. Credentials expire and platforms change, so an integration with no internal owner will eventually fail quietly. See measuring call handling performance for the checks that catch it early.
Related reading
Related planning guides are indexed in the resources library.
Map your systems before you commit
Tell us which calendar and customer system you use. We will set out honestly what can be connected, what would need a manual step, and what we would not attempt.