# Handle website enquiries

**Console: Guests → Enquiries.** For the person handling contact, private-hire,
catering, general, or large-group requests from the restaurant website. The
inbox requires a created site and the relevant Sites Advanced access.

1. Choose the intended business and status filter. Review the enquiry type,
   requested date (including flexible dates), message, and contact details.
2. Select **Mark read** after reviewing it. Check availability and the
   restaurant's enquiry-handling process before promising a booking or event.
3. Use the email or call link to open the appropriate contact application. Check
   the recipient and message before actually sending or calling.
4. Select **Mark responded** after the response has been made. This updates the
   inbox status; it does not itself send a message.
5. Use **Archive** for completed requests, or **Mark as spam** for genuine spam.
   Verify the resulting status and leave a clear handover for unresolved work.

| Status    | Meaning for the team                    |
| --------- | --------------------------------------- |
| New       | Awaiting review                         |
| Read      | Reviewed, response may still be needed  |
| Responded | Staff recorded that a response was made |
| Archived  | Removed from the working queue          |
| Spam      | Classified as unwanted enquiry          |

## Find the request and hand it over

The inbox shows the newest submissions first, with up to 25 requests per page.
Use **Previous** and **Next** to inspect additional pages. Changing the status
filter returns to the first page. If the last page becomes empty after requests
move to another status, **No more enquiries** offers **Previous**; it does not
mean the whole inbox is empty.

Check the **Party**, requested **Date** and **Time**, **Event**, **Budget**, and
**Area** details where supplied. The timestamp beside the guest identifies when
the enquiry was submitted; it is separate from the guest's requested event
date. **No message provided** means the message is absent, so review the other
request details before deciding what information to ask for.

A status change can remove the request from the current filtered view. Change
to its new status or **All** and verify the same guest/request before handing it
over. Keep response commitments in the restaurant's agreed handover process;
**Responded** does not establish that an event is booked or that a deposit was
collected.

## Resolve a missing request or incorrect status

| What you see | What to check |
| ------------ | ------------- |
| **No business selected** | Select the intended business in the sidebar. |
| **No enquiries yet** | Check the restaurant's actual site and enquiry form. A site must have been created; this view alone does not prove a guest submitted a request. |
| No requests with the selected status | Use **Show all** or **All**, and check other pages. |
| **Couldn't load enquiries** | Use **Try again** after checking the connection. A failed load is not evidence of an empty inbox. |
| Sites Advanced access is unavailable | Ask the authorised account owner to check this business's feature access. If the gate is unexpected, verify access and connection before starting an upgrade. |
| A request was archived or marked as spam by mistake | Open **Archived** or **Spam**, find the same request, and use **Mark read** to return it to a reviewed state. Verify it under **Read** and arrange any response still needed. |

Changing a status does not delete the enquiry or cancel a booking. The inbox
does not offer a **Mark new** action; use the available reviewed state and a
clear handover when correcting an accidental classification. Do not use another
business's context to work around missing access.

If a status save fails, reopen the same enquiry before repeating it. If an email
or call outcome is uncertain, check the contact application's record before
contacting the guest again. Escalate with the enquiry reference, status,
intended response, and error. Keep guest details within authorised channels.