Inbox UX comparison — current state vs. three proposed directions. Real data from the live system: Tammy (general inquiry), Philippe (booking ask), Yvonne & Jennifer (already-converted).
Single inbox, all messages mixed together regardless of intent. "Booking Requests" page title, "Convert to Booking" shown on every card.
Same data path. UI auto-classifies each item as 📅 Booking ask (has dates + service) or 💬 Inquiry, shows different actions per type. Page renamed to "Customer Inbox".
💬 Inquiry. Primary action is "📧 Reply" (mailto:) — what you actually want to do.
📅 Booking ask with full date/service details. Different action set on those cards (Convert primary).
start + service present and service ≠ "Other / General Inquiry" → it's a booking ask. Otherwise → inquiry. Rule is simple, explainable, and editable later if edge cases emerge.
Same data path, but the inbox UI has tabs at the top: Inquiries, Booking Requests, Booked, Archive. Each tab has its own appropriate actions. Active inbox = unread items only.
📅 Bookings tab:Customer-facing form gets a leading "What can we help with?" branch. Two separate RTDB paths, two separate inboxes. Different lifecycle for each.
What can we help with today?
/bookingRequests, inquiries in /inquiries.
| Feature | Current | A — Light | B — Tabs | C — Heavy |
|---|---|---|---|---|
| Page name | Booking Requests | Customer Inbox | Customer Inbox | Inquiries / Booking Requests (split) |
| Inquiries clearly distinct from booking asks? | No — same UI | Yes (badge on each card) | Yes (separate tabs) | Yes (separate pages + RTDB) |
| Wrong "Convert to Booking" on inquiries? | Yes — shown anyway | Hidden on inquiries | Hidden on inquiries | N/A — lives elsewhere |
| Active inbox stays uncluttered? | Filter chip needed | Filter chip needed | Done items in separate tab | Done in archive page |
| Customer form change required? | No | No | No | Yes — "What can we help with?" branch |
| Data migration? | — | No | No | Yes — split existing /bookingRequests |
| Effort | — | ~1 hr | ~2-3 hrs | ~half day |
| Reversible if you don't like it | — | Yes — pure render change | Yes — pure render change | Partial — form change needs revert |
| Status word: "converted" | "converted" | "booked" | "booked" | N/A (booking has its own lifecycle) |
| Auto-classification rule used? | — | Yes (could miss edge cases) | Yes (could miss edge cases) | No — customer chose intent |
| Different push priority for inquiries vs bookings? | No | Same priority | Possible | Trivially separable |
Direction A is high-leverage low-risk. Costs ~1 hour, fully reversible if you change your mind. Closes the most embarrassing UX issues (Convert button on inquiries, misleading page name) without committing to a structural change. After living with it for a week or two of real customer messages, you'll know whether Direction B's tabs would actually help or whether classify-at-render is enough.
Skip Direction C unless real-world friction surfaces. The form-side branching sounds clean but adds friction for the customer ("I just wanted to send a message, why do I have to pick a category?"). Most modern intake forms accept everything and classify on the back end.