Practical guide

A booking collision test you can explain to the team

Last materially reviewed 2026-09-23

Quick answerTest the last available resource and a non-conflicting request; accepting everything and blocking everything are both failures.
What to know

Write the expected outcome first

Choose a fictional service with a deliberately scarce resource. Record the available staff, rooms and equipment, the occupied interval and the maximum acceptable simultaneous bookings. Write which request should succeed and which should fail before opening a test environment. Otherwise it is easy to reinterpret whatever the software does as the intended result. This is an original acceptance method, not a report that Trafft or another product has passed it.

What to know

Test two different kinds of conflict

The first case is a known overlap with an existing appointment. The second is two people requesting the last slot at nearly the same time. They test different failure modes. A calendar that hides an already booked interval may still need a controlled concurrency test. Do not manufacture real customer reservations or repeatedly submit public merchant forms. Use an authorized sandbox or vendor-assisted demonstration and preserve the actual result without claiming more than was observed.

What to know

Include a request that should remain possible

After reserving the scarce machine, try a service that uses a separate resource and an available qualified person. If it is blocked without a real shared constraint, investigate whether the resource pool is too broad. Overblocking wastes usable capacity even when it prevents collisions. A useful acceptance sheet therefore contains both expected rejection and expected acceptance, with enough detail that another team member can repeat the reasoning.

What to know

Record evidence and unresolved behavior

Save the configuration, fictional input, observed status and relevant time for each test. Distinguish the visible confirmation from the underlying resource release and staff notification. If the outcome is uncertain, do not submit the same request again blindly; first inspect whether an appointment was created. Keep the result as unresolved until the record is reconciled. That discipline avoids turning a verification exercise into the very duplicate booking it was meant to prevent.

Continue when useful

Next: Model staff, rooms and equipment together

List the resources required by one appointment, then find which requirement limits simultaneous bookings.

Open Model staff, rooms and equipment together →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Trafft resource allocation — Merchant documentation · trafft.com · Merchant-controlled · checked 2026-09-23
  2. Trafft appointment management — Merchant documentation · trafft.com · Merchant-controlled · checked 2026-09-23
FIELD NOTE 02 / ACCEPTANCE BOARD

Test the commitment, not just the calendar.

Fictional caseExpected boundaryInspect separately
Last shared machine is reservedReject another conflicting appointmentStaff time does not override equipment scarcity
Unrelated service uses another resourceKeep valid availabilityDo not block the whole business
Customer moves an appointmentSecure the new interval; reconcile the oldStatus, resource release and message
Submission outcome is uncertainInspect the record before repeatingA missing message is not proof of no booking

Our proposed acceptance cases—not observed merchant results. Use the complete test method →