Important limitations

Prepare a booking fallback before an outage

Last materially reviewed 2026-09-23

Quick answerA fallback should preserve known appointments and avoid accepting uncertain capacity, not create a second uncontrolled booking source.
Likely to work well when

✓ Teams sharing rooms or equipment

✓ Operators evaluating a concrete collision constraint

✓ Readers planning acceptance tests before migration

Important limitations

— Lodging inventory and enterprise dispatch

— Medical or legal compliance recommendations

— Generic solo calendars without a resource problem

What to know

Decide what must continue

During an outage, staff need to know which appointments are already committed and how customers can contact the business. They may not need to keep accepting instant bookings. Separate those needs before selecting a fallback. This guide does not promise offline access, backups or restoration features for any particular merchant. Verify available controls through the actual account and current documentation rather than assuming every hosted service supplies them.

What to know

Use a request route honestly

If live capacity cannot be checked, an inquiry or callback request may be safer than a confirmed appointment. Label it as a request and explain that the time is not reserved until the team confirms it. Do not publish a second calendar that guesses availability from stale information. Keep any temporary customer data within the authorized, privacy-appropriate process, and avoid collecting more than is needed to reconcile the request later.

What to know

Plan the recovery reconciliation

When access returns, compare accepted appointments, pending requests and any manual commitments made during the interruption. Resolve conflicts before reopening unrestricted self-service booking. A restored website is not proof that every booking record is complete. Assign an owner to reconcile uncertain submissions, especially where a customer may have seen an error after the system accepted the request. Do not instruct customers to retry blindly without checking whether their appointment already exists.

What to know

Practice a narrow tabletop case

Walk through a fictional thirty-minute outage with one known appointment, one uncertain submission and one new inquiry. State who checks the records, who communicates and when public booking can resume. This exercise requires no live disruption and makes missing responsibilities visible. Review the fallback when the booking platform, staff process or public entry points change. The objective is a controlled interruption with accurate commitments, not an unsupported promise that outages can never affect the business.

Source boundary

Where the safety evidence stops

This guide draws on Trafft administrative calendar, Trafft appointment management. Merchant-controlled records describe the provider’s own capabilities, terms or standards; they do not independently validate those claims. These records do not establish independent confirmation of the product claims.

Verify any current price, plan limit, label direction, compatibility rule, or commercial term that would materially change the decision. The dated source ledger shows the underlying records so this conclusion can be checked and updated.

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 administrative calendar — Merchant documentation · trafft.com · Merchant-controlled · checked 2026-09-23
  2. Trafft appointment management — Merchant documentation · trafft.com · Merchant-controlled · checked 2026-09-23