Preparing Your Calendar and CRM for AI

1. Calendar and service data cleanup

• ✓One unambiguous name per service, written the way a customer would say it — no internal codes or abbreviations.
• ✓One correct duration per service, reflecting reality rather than the optimistic version.
• ✓Retire services you no longer offer instead of leaving them bookable.
• ✓Note which services require a specific room, chair, vehicle, or qualified person.
• ✓Confirm published prices match what the calendar and website say; fix disagreements at the source.
• ✓Ensure each service has a one-line plain description the assistant can read aloud.
• ✓Confirm time zones and location addresses on every calendar you will connect.

Pick one system as the single source of truth for availability. If two calendars can both create bookings, decide which one wins and how the other stays in sync before you connect anything.

2. Availability and buffer rules

• ✓Working hours per person and per location, including lunch and admin blocks.
• ✓Minimum notice before a bookable slot — the assistant should not offer something in twenty minutes.
• ✓Maximum booking horizon, so people cannot book eleven months out.
• ✓Buffer before and after each service type, including cleanup or setup time.
• ✓Travel time and service-area rules for anything mobile or dispatched.
• ✓Daily capacity limits per service type where they exist.
• ✓Holidays, closures, and known absences entered in advance, not remembered on the day.
• ✓Which slots are reserved for urgent work and therefore not offered for routine bookings.

3. Cancellation and rescheduling rules

• ✓How much notice is required to cancel or move, per service type.
• ✓What the assistant may do inside that window, and what needs a person.
• ✓Whether a cancelled slot automatically returns to availability — it should.
• ✓Whether a waitlist exists and how a freed slot is offered.
• ✓Any deposit or late-cancellation policy, stated in your published wording and nowhere improvised.
• ✓How a reschedule is recorded so history is not lost.
• ✓The exact confirmation message sent after any change.

4. Required customer fields

Decide the minimum set of fields required to book, and stop there. Every extra required field is another chance for a conversation to stall, and collecting information you do not need creates work and exposure.

• ✓Required: name, a contactable phone or email, service, location, and preferred time window.
• ✓Conditional: address for anything mobile, referral source if you actually use it.
• ✓Optional: the customer's own description of what they need, captured verbatim.
• ✓Deliberately excluded: sensitive detail that should not be gathered in an unverified channel.
• ✓Consistent formats for phone numbers and dates, so records stay searchable.
• ✓One field — not three — recording how the contact reached you.

5. Duplicate handling

• ✓Choose the matching key: usually phone number, with email as a secondary.
• ✓Merge obvious existing duplicates before connecting anything, keeping the fuller record.
• ✓Define what happens on a partial match — update, or create and flag for review.
• ✓Never let an automation silently merge two records; flag ambiguity for a person.
• ✓Keep a review queue for suspected duplicates and check it weekly at first.
• ✓Decide whether household or company members share one record or several.

6. Pipeline stages and ownership

• ✓A short stage list where each stage means one unambiguous thing.
• ✓One written definition of what must be true to enter each stage.
• ✓A named owner for every stage — including new inbound contacts created out of hours.
• ✓A rule for what happens when nobody acts on a new contact within your target window.
• ✓Retire stages nobody uses rather than leaving records stranded in them.
• ✓Decide which stage an assistant-created contact starts in, and who is notified.

7. Integration, permissions, and privacy

• ✓Connect the fewest systems the first workflow needs, and nothing more.
• ✓Grant the narrowest permissions that allow the workflow — read-only where writing is not required.
• ✓Use a dedicated account or key rather than an individual employee's login.
• ✓Confirm which direction data flows for each field, so nothing overwrites your source of truth.
• ✓Check that records show what was created automatically, so an audit is possible later.
• ✓Confirm retention: how long transcripts and contact data are kept, and where.
• ✓Have your own advisors confirm privacy and consent obligations before launch — this is not legal advice.

8. End-to-end test checklist

1. 1.Book a test appointment through the assistant and confirm it appears once, in the right calendar, with the right duration.
2. 2.Confirm buffers and travel time were respected and no adjacent slot was double-booked.
3. 3.Check the contact record: correct fields, correct format, correct owner, correct stage.
4. 4.Re-book with the same phone number and confirm no duplicate contact was created.
5. 5.Reschedule the test appointment and confirm history is preserved and confirmations are sent.
6. 6.Cancel it and confirm the slot returns to availability.
7. 7.Request a slot outside notice or capacity rules and confirm it is not offered.
8. 8.Request an unavailable time and confirm real alternatives are offered.
9. 9.Trigger an exception and confirm it reaches a human with full context.
10. 10.Delete every test record before go-live, and confirm the off switch works.

9. Common mistakes

• ✓Connecting a calendar whose availability was never accurate to begin with.
• ✓Two systems both allowed to create bookings, with no agreed source of truth.
• ✓Duplicate service names, so the assistant books the wrong thing correctly.
• ✓No buffers, producing back-to-back appointments nobody can actually keep.
• ✓Requiring six fields to book and losing conversations at field four.
• ✓Letting automations merge contacts silently and corrupting history.
• ✓Broad admin permissions granted because it was quicker than scoping them.
• ✓Skipping the end-to-end test, so the first real customer finds the fault.

Pre-launch data checklist

• One source of truth chosen for availability and for contacts.
• Service names, durations, descriptions, and prices cleaned and consistent.
• Working hours, notice, horizon, buffers, travel, and capacity rules written down.
• Holidays and known absences entered in advance.
• Cancellation and reschedule rules defined, including slot release and waitlist.
• Minimum required booking fields agreed, with sensitive fields excluded.
• Duplicate matching key chosen and existing duplicates merged.
• Pipeline stages trimmed, defined, and owned — including out-of-hours inbound.
• Narrowest permissions granted via a dedicated account, with retention confirmed.
• All ten end-to-end tests passed and test records deleted.
• Advisors have confirmed privacy and consent obligations.

Key takeaways

• ★Automation reproduces your data problems faithfully and quickly — fix them first.
• ★Choose one source of truth for availability and one for contacts.
• ★Honest availability, with buffers and notice rules, prevents most booking failures.
• ★Require the fewest fields that let you act; exclude anything sensitive.
• ★Decide duplicate handling before connecting, and never merge silently.
• ★Grant the narrowest permissions through a dedicated account, not a personal login.
• ★Run the full end-to-end test yourself before a customer does it for you.