How QCMM Prevents Same-Customer Meeting Conflicts

QCMM blocks overlapping appointments for the same signed-in customer across Plans and Hosts, including protected checkout holds and confirmed bookings.

Conflict Protection Is Customer-Wide

QCMM prevents one Joomla user from holding or confirming overlapping Meeting Times even when the appointments belong to different Plans or different Hosts. Conflict checks use the authoritative UTC start and end values.

What Counts as a Conflict

A confirmed booking conflicts when its time range overlaps the proposed Meeting Time. Protected checkout inventory also counts: active held reservations and payment-processing or paid-protected holds block another overlapping selection.

Exact back-to-back boundaries are allowed. For example, an appointment ending at 10:00 does not conflict with one beginning at 10:00.

During Selection and Rescheduling

Customer availability marks or excludes conflicting Meeting Times, and QCMM repeats the conflict check inside the transaction that creates a hold or moves an existing booking. During a reschedule, the current booking is excluded from its own conflict test while other confirmed bookings and protected holds still count.

Concurrent Requests

QCMM serializes customer scheduling writes by locking the same Joomla user record before the final conflict check. This prevents two simultaneous requests for different Meeting Times from bypassing customer-level overlap protection.

Community Discussion

Want to compare scheduling workflows or share practical QCMM tips? Visit the QC Memberships & Meetings Community. For private support, bug reports, account-specific entitlement or billing problems, or feature requests, use the QuantaCade support system.