Diary and appointment scheduling
Detail
Real availability lookup, creating, changing and cancelling appointments under your rules: clinician, test type, room, duration and overlaps. It is the integration on almost every healthcare project.
Integrations
A call that is not recorded in your system has resolved nothing
The value is not in the conversation: it is in the appointment being booked, the ticket opened and the metric updated without anyone on your team copying it across by hand. That is why integration is not an extra on the project — it is the project.
- Read and write, not just lookup
- A route when there is no API
- Verified before signing
What we connect
The systems the agent works with
By category, not by brand: what matters is what your tool exposes, not what it is called.
Bookings and floor management
Detail
Creating and changing bookings against real sittings, tables and capacity, with waiting lists and automatic release of unconfirmed ones.
CRM and customer databases
Detail
Identifying the caller, reading their record to give the agent context, and logging the interaction and its outcome where your team will look for it.
ITSM and ticketing
Detail
Opening tickets with structured fields — affected service, symptom, verbatim message, steps already tried — applying your category taxonomy and your priority matrix, not a generic one.
Calendars
Detail
Google Calendar and Microsoft 365, for flows where the diary lives in the practitioner’s calendar rather than in scheduling software.
Messaging
Detail
SMS, WhatsApp Business and email for confirmations and reminders after the call, when the caller would rather have it in writing.
Telephony
Detail
We work with your existing numbers and carrier, or provide them. Failover to your switchboard is part of this layer.
Directory and identity
Detail
Verifying the user against your directory in support flows, before touching anything on their account.
Mechanisms
Four ways to connect, in order of preference
We use the highest one your system allows. The fourth exists because a lot of scheduling software still ships without a public API.
- 01
REST API
The ideal: the agent reads and writes in real time during the call. The availability it offers is what exists at that moment, and the confirmation exists before hanging up.
- 02
Webhooks
Your system tells us about a change and we fire the matching flow: a cancellation that activates the waiting list, a ticket closing that triggers the survey.
- 03
Custom middleware
Where an API exists but does not cover what is needed, we build a layer that translates between your data model and ours.
- 04
Scheduled files
No API: the agent works from a periodically refreshed export and leaves its actions in a file your system imports. Less immediate, but it covers most confirmation and reminder flows.
If your software has no API
The most common case, and not a blocker
A good share of installed scheduling software exposes no public API. We run into it constantly and there is a route through, but it is worth knowing what you gain and lose before deciding.
We check this in the technical session, before you sign anything. If your specific case cannot be solved with confidence, we will say so then — not after the pilot.
Ask us about your caseWhat changes versus an API
- Availability can lag by minutes rather than seconds
- A buffer is advisable to avoid double bookings
- Outbound flows (reminders, reactivation) work just as well
- Inbound flows needing an instant answer lose precision
- Sync frequency is agreed against your volume
- You can start this way and move to an API if your vendor publishes one
What it costs
How much of your technical team’s time
We do the integration. This is what we need from your side.
- 1-2 h
Technical session
With whoever administers the system, to see what it exposes and how access works.
- Access
Test credentials
A sandbox if one exists; if not, scoped credentials in production.
- API
What sets the timeline
How long it takes depends on how documented it is. Runs in parallel with script design.
- 0
Changes to your system
We do not ask you to modify your software or migrate data anywhere.
Questions about integration
What the technical lead asks in the first session.
Do you work with the software we use?
We would rather not publish a list of brands, because it ages badly and because "compatible" means different things depending on the flow. Tell us what you run and in the technical session we will tell you exactly what can and cannot be done with it.
Do you need access to our whole system?
No. We ask for the minimum access the flow needs, and prefer credentials with scoped permissions. An appointment-confirmation flow does not need to see clinical records, so it is not given access to them.
What happens if your integration fails?
The agent does not improvise: if it cannot confirm against your system, it does not confirm. It takes the request, tells the caller confirmation will follow shortly, and leaves the task recorded for your team. And if the whole service fails, calls fall back to your existing number.
Can you write to several systems on the same call?
Yes. A flow can check the diary, update the CRM record and fire a confirmation text within one conversation. Each step is logged separately so you know which one failed if something does.
Does data pass through your servers?
Only what the flow needs, for the agreed period, processed in the EU. Exactly which fields are sent is documented in the DPA before the first call.
What if we change software later?
The integration layer is rebuilt, not the flow. The script, the rules and the metrics stay; what changes is how it connects. It is bounded work and quoted separately.
Tell us what software you run
In a one-hour session we will tell you what can be integrated, how, and with what limitations. Before you sign anything, at no cost.