Acuity Scheduling Zoho CRM integration: booking to follow-up

Define what a booking should become in CRM before connecting Acuity Scheduling. A person, an appointment and a sales opportunity are different things. Your integration needs to keep their identities clear when someone books again or changes a time.

Planning this work for your team? See our Zoho CRM integration service.

Start with a small booking lifecycle test. Verify the original appointment, reschedule and cancellation before using the connection for routine meeting preparation.

Choose the extension or middleware route

The Acuity Scheduling for Zoho CRM listing describes scheduling from Leads, Contacts, Deals and Accounts, with booking details available inside CRM. It also describes rescheduling and cancelling upcoming appointments.

That is a useful starting point for an in-CRM booking requirement. Verify the selected extension's actual configuration and supported lifecycle before promising a particular destination or synchronisation direction.

A middleware route needs its own specification. If you only need an eligible booking event delivered to CRM, define that narrower outcome and verify the chosen trigger and actions. Do not assume a one-way event delivery recipe reproduces interactive booking management.

Compare both routes against the same pilot. The Shopify integration guide uses the same principle for store records: select the route, define identities and verify outcomes before adding downstream work.

Verify vendor, accounts and actual costs

The Marketplace listing identifies Ulgebra as the developer. It also notes in-app pricing despite a Free pricing label. Treat the label as a reason to inspect the commercial details, rather than as a complete quote.

Ask for the cost of the intended extension use and any separately required Acuity account. Verify supported CRM editions, users, account requirements and vendor support against the current documentation. Keep unanswered questions visible until the responsible provider answers them.

Record who supports each part: the extension vendor, Acuity account owner and CRM administrator. A booking problem can cross those boundaries, so the team needs a clear first contact and a way to share the pilot evidence.

Do not publish a budget based on an installation label alone. Have the account owner confirm the actual package before planning a rollout.

Install and authenticate the chosen connector

Start from the named extension listing and its current vendor instructions. Confirm the intended CRM organisation and Acuity account before completing authorisation.

Have the account owners review requested access. Keep credentials out of screenshots and the mapping worksheet. Use the selected route's documented connection process rather than instructions written for a different connector.

Verify which CRM modules and calendar settings are actually available in your setup. The listing's scheduling locations do not establish every destination relationship or field mapping. Ask the vendor about any requirement you cannot find.

Restrict the pilot to recognisable records and an agreed calendar. Record the chosen configuration so another administrator can repeat the test. A successful sign-in is the beginning of validation, not evidence that bookings have reached the intended records.

Define matching, ownership and appointment fields

Should bookings create Leads, Contacts or Meetings? Decide from your process, then verify the chosen connector supports the intended behaviour. Do not create another person record merely because the same person books another appointment.

Define person identity separately from appointment identity:

Item	Decision to record
Person	Existing-record matching rule and ambiguous-match handling
Appointment	Stable booking reference and intended CRM destination
Time	Source timezone, stored meaning and displayed time to verify
Owner	Host, salesperson and fallback reviewer
Meeting link	Source and destination when supported
Status	Meaning of booked, rescheduled and cancelled in your process

An email address may help match a repeat booker, but a shared address or changed address needs review. Keep ambiguous matches out of automatic corrections until someone verifies the person.

Write the blank-value policy too. An omitted phone number should not accidentally become an instruction to erase a useful CRM value. Verify how the selected route handles that case.

Test the full booking lifecycle

Use a pilot person and appointment that the account owners can inspect on both sides. Write expected outcomes before generating the events.

Event	Check in the pilot
New booking	Intended person, booking reference, owner and time
Repeat booking	Same person identity with a distinct appointment
Reschedule	Correct existing appointment and new time
Cancellation	Clear cancelled outcome and appropriate follow-up state
Failed write	Visible exception and a documented recovery owner
Repeated event	Existing booking remains identifiable without unexplained duplication

For a reschedule, compare the appointment reference and displayed time directly. Seeing another appointment at the new time does not prove that the old one was handled correctly.

For a cancellation, check the CRM result and any planned preparation work. Define which tasks should be reviewed or withdrawn, and verify the selected setup's behaviour. Do not assume cancellation removes every downstream action automatically.

Before retrying a failed write, search for the original booking reference. An interrupted response is not proof that the appointment was absent.

Monitor exceptions and connector changes

Keep a runbook with the connection owner, calendar, matching policy, timezone agreement and pilot cases. Record unresolved bookings with their source and CRM references.

Investigate missing appointments by checking source state, authentication, selected configuration and destination records. Do not correct a displayed time until you know which timezone each value represents.

After a vendor update or account change, rerun the affected lifecycle cases. Include reschedule and cancellation rather than testing only a new booking.

If your team also handles phone enquiries, the CallRail guide provides a separate handoff checklist. Keep both channels accountable to the same goal: a correctly identified person and a clear next action in CRM.

Get help with this CRM task

For help with a reliable booking-to-CRM handoff, contact zsetup. Include your booking types, matching rule and reschedule/cancellation requirements. Share redacted examples rather than live customer details or credentials.

Our Zoho CRM integration service explains the scope we can discuss and how the work is checked.