Troubleshooting

Troubleshoot bookings, messaging and AI responses using observable results

A calm recovery path that starts with the exact record and stops before an unsafe duplicate or unsupported claim.

8 min readReviewed 2026-09-12

Key takeaways

• Start with an observable symptom and exact record, not a guessed cause.
• Search, refresh and inspect before creating a duplicate or retrying an unknown delivery.
• Support requests should preserve safe, reproducible context.

Name the symptom precisely

Start with what you can observe: a service is absent, a slot is unavailable, an appointment appears twice, a message is delayed, a call is partial or an answer differs from its source. Note the account area, language, approximate time and safe record reference. Avoid starting with a provider or code assumption that the screen does not support.

• Capture expected result and actual result in separate words.
• Keep the customer, service, conversation or source reference specific.
• Do not include passwords, tokens or full payment-card data.

Recover a booking safely

For a missing appointment, search by customer and date before creating anything. For a duplicate suspicion, open each matching row and compare service, time and status. For an unavailable slot, review business hours, closures, service duration and overlapping records. Use Reschedule or Cancel only from the intended saved record and verify the result afterward.

• Refresh once and inspect before repeating a save.
• Use the public booking view to check availability, not to infer why a slot is absent.
• Record the final row and status after the supported action.

Recover messaging and AI responses

For a missing WhatsApp message, check the displayed connection state, number and correct inbox before resending. For a wrong AI response, compare the answer with the current Knowledge Base source, look for stale or conflicting material and retest the same controlled question after processing. For a partial voice call, inspect the Voice Agent call row, transcript and issue details before changing provider settings.

• Treat upload, processing and retrieval as separate Knowledge Base states.
• Do not treat a connected label as delivery proof.
• Keep the first failed or delayed record available for Support.

Escalate with a reproducible account

If the supported recovery path does not resolve the issue, open Support with the page or tab, the expected and actual result, time, safe record reference and the recovery step already tried. Explain whether the issue is still pending, failed or unknown. This helps the next operator investigate without repeating a chargeable, customer-facing or data-changing action.

• Attach only supported, non-sensitive evidence.
• Keep one ticket for one observable issue when possible.
• Wait for an authoritative result before closing or retrying the action.

Examples

Example: two appointments share a customer and date. Compare service, time and status before using Cancel on only the confirmed duplicate.
Example: a Knowledge Base answer is wrong after an upload. Check processing and conflicting sources, repeat the same question and record the observed answer before escalating.