What does it take to connect an AI voice agent to our scheduling software?

The pieces, in the order they usually bite

• Scopes. Read availability, read customers, write customer, write job or booking request. Many teams discover mid-project that their plan tier does not include a write scope they assumed.
• Entity mapping. Job types, business units, campaigns, call reasons, tag conventions. This is a spreadsheet exercise and it is where the real project time goes.
• Identity resolution. Phone number and address matching against existing customers, with a rule for what to do on a near match.
• Idempotency. A stable key per call so a network retry cannot create a second job.
• Rate limits. Voice traffic is bursty. Storm days generate exactly the call volume that trips API throttling.

Booking request versus direct write

There are two shapes for the write, and choosing wrong causes months of friction. A direct write creates a real job on the board immediately — fast and clean when your constraints are well encoded, dangerous when they are not. A booking request creates a pending record that dispatch confirms.

Requests are the right starting point for most companies. They keep a human in the loop while you learn what the agent gets wrong, and they let you graduate specific job types to direct writes once the correction rate on those types is boring. Both patterns are ordinary field service integration work; the choice is operational, not technical.

What happens when the API is down mid-call

This is the case that separates a demo from a system. The caller is on the line, the scheduling system is not responding, and the agent has to say something true.

The right behavior is to keep talking, finish the intake, tell the caller the appointment will be confirmed shortly, and queue the write for retry. The wrong behaviors are to hang up, to invent a confirmation, or to silently drop the call record. Building that queue with retry and a dead-letter path is unglamorous and it is what makes the difference between an agent you can trust overnight and one you cannot.

Test against a sandbox with your real data shape

Vendor sandboxes are usually populated with tidy demo data that does not resemble a ten-year-old production tenant. Test with a copy of your actual job type list, your actual duplicate customers, your actual business unit structure. Most integration surprises are data surprises. That is true whether the target is Jobber, a field service platform or a CRM.