The appointment engine is xMatix's general booking system: one appointment record for demos, test drives, service visits, deliveries and consultations, booked against branch capacity that the platform releases from templates, with people, vehicles and facilities claimed per booking. Appointment scheduling is in preview. Its setting governs automatic slot-materialization and maintenance sweeps; it is not, by itself, a universal server-side block on every manual appointment surface. Confirm both the tenant setting and the enabled UI/action paths in your environment. The demo booking flow described under product demos is the generally available path today.
Prerequisites
- The appointment scheduling switch enabled when you rely on automatic slot generation, plus confirmation that the intended manual booking surface is enabled for your organization (see the configuration reference).
- At least one active appointment type, and per branch a slot template so bookable slots exist.
- Optionally, bookable resources registered where appointment types require them.
Procedure
Step 1 — Define appointment types (admin)
An appointment type is the policy for one flavor of booking — Product Demo, Test Drive, Service Visit, Delivery, Consultation. It sets the default duration and setup/teardown buffers, the booking policy (minimum lead time, how far ahead booking is allowed, cancellation cutoff, maximum reschedules, overbooking allowance), which location modes are allowed (branch, onsite, virtual), reminder offsets, whether customer confirmation is required, and the resources a booking of this type must claim (for example one salesperson and one demo vehicle). New appointment flavors are configuration, not code. Save it inactive first, reread every time and capacity boundary in the branch's timezone, then activate it. Verify the type appears in the booking selector only where its location mode and effective configuration allow it.
Step 2 — Create slot templates per branch (admin)
A slot template is a recurring capacity pattern: a daily window in the branch's local time, cut into slots of a set duration, with a capacity per weekday (a weekday set to 0 is closed; a weekday without its own number uses the template's default capacity). Capacity can be fixed numbers, derived from available bookable resources, or the lower of the two. The platform materializes templates into concrete, bookable slots over a rolling horizon automatically, skipping the branch's non-working days and holidays. Templates can be scoped to one appointment type and to specific items or item groups. After saving, inspect one ordinary weekday, one closed day and one holiday inside the rolling horizon. Confirm the generated start/end times, capacity and type/item scope match the template rather than trusting the recurrence summary alone.
Step 3 — Register bookable resources (admin)
A bookable resource is one schedulable unit — a person, an asset such as a demo vehicle, or a facility such as a service bay (exactly one of the three). Each has a home branch, working hours (falling back to the person's or the branch's hours), an effective window, and a concurrent capacity — how many overlapping appointments it can serve (advisors may take several; a vehicle or bay takes one). Choose exactly one resource kind, validate its effective dates and local working hours, and use capacity 1 for indivisible assets unless parallel use is genuinely possible. Verify it contributes capacity to a future slot and disappears outside its effective or working window.
Step 4 — Book the appointment
Book from the record the appointment is about — a lead, opportunity, service order or delivery — choosing the appointment type and an available slot. Confirm the partner account, branch, customer context, location mode and required resource before saving. The booking is enforced server-side: a slot's capacity is claimed atomically, so a full slot refuses the booking rather than overbooking silently, and the type's resource requirements claim free resources at the same time. While a booking is being completed, the chosen slot can be held briefly; unfinished holds expire on their own. After saving, reopen the appointment from its source record and verify the displayed local time, slot usage and resource assignment.
Step 5 — Run the day
An appointment moves through a controlled lifecycle: Requested → Scheduled → Confirmed → CheckedIn → InProgress → Completed, with Cancelled, NoShow and Rescheduled as terminal states. At each hand-off, confirm the current status and customer identity before taking the next action; record operational notes where the transition depends on a real-world event. Illegal jumps are refused, terminal appointments are immutable, and cancelling inside the type's cutoff window is blocked. Rescheduling creates a linked replacement and consumes the reschedule allowance. After completion, cancellation or rescheduling, verify the old slot and resources were released and the audit trail shows who made the transition.
Expected result
The booking reserves one valid slot and every required resource without exceeding capacity. Its times display correctly in the branch timezone, its linked customer or work record opens from the appointment, and each tested lifecycle transition updates status, reminders and released capacity exactly once.
Common problems
No slots are offered — the scheduling switch is off, the branch has no active template covering that date (check the template's effective window and that the weekday's capacity isn't 0), or the date is a holiday or non-working day. The slot is full — capacity including any overbooking allowance is consumed; pick another slot or have an administrator raise capacity. A slot shows as overcommitted — a capacity recompute found more bookings than the slot now allows (for example approved leave removed a resource); a dispatcher needs to move bookings. A status change is refused — the transition isn't legal from the current state, or the appointment is already terminal.
Common questions
What can an appointment be about?
Any record — appointments attach to the record they concern (lead, opportunity, case, service order, delivery order, account) and additionally carry the customer, contact, item and asset involved, so both the deal and the customer see the booking.
How do onsite appointments meet field plans?
An onsite appointment can be marked field-serviceable and folded into a field rep's day as an anchored visit — see visit plans.
How does this relate to demo bookings on opportunities?
The Book Appointment demo flow on opportunities (product demos) is the generally available booking path and creates a product demo record. The appointment engine on this page is its successor-in-preview: one booking model for all appointment flavors, with server-enforced capacity and resource claims. A demo can link to the appointment that hosts it.