Scope, screens and permissions
Inbox is a separately entitled work area at /app/<orgSlug>/inbox.
It combines email conversations and structured form submissions and works
independently of CRM or Bookings. Those products contribute capabilities only
when both their entitlement and the person's source permissions allow them.
| Surface or action | Authority/boundary |
|---|---|
| Read conversations | inbox.view and current mailbox access |
| Manage conversations or personal mailbox connection | inbox.manage, with personal ownership retained |
| Approve and send a reply | inbox.reply.send plus exact conversation, sender and current provider readiness |
| Publish an Inbox Booking draft | inbox.booking.publish plus the owning Bookings capabilities and live validation |
| Read/change module settings | inbox.settings.view / inbox.settings.manage at the supported scope |
| Independent historical classifier review | Inbox source access; platform access alone cannot read mail |
The default Unified queue interleaves open email and active forms by latest activity. Email and Form submissions retain their source-specific controls. Desktop has independently scrolling queue and reader panes; narrow screens stack them. URL filters preserve Back/Forward navigation. Switching between focused source views preserves the selected item and its draft while authority remains. A workplace or signed-in account change clears private view state.
Email queue and mailbox identity
The mailbox menu offers All my inboxes and individual authorized accounts. Shared and Personal labels and full addresses remain visible alongside mailbox colours. All my inboxes includes shared mail plus only the signed-in person's own personal mail. Selecting an inaccessible mailbox never broadens to another queue.
Personal mailbox ownership differs from conversation assignment. Administrators do not automatically gain personal email access. Personal conversations cannot be assigned to teammates, converted into shared enquiries or saved as shared responses. Private uploads remain outside the shared communication-file library.
Email filters include open/closed, unread, ownership and category, with paginated chronological results. Loaded counts are not full mailbox totals. Opening a conversation marks unread state; it does not declare reply work complete. Changing category does not assign, close or move the email.
Mailbox controls expose sync status, manual refresh and management. Routine account details stay in that control; failures show a recovery notice. Gmail history sync is bounded and preserves the last successful cursor on ordinary failure. Reconnect must use the same verified Google identity and mailbox; a different Google account requires a separate connection.
Reading and replying
The reader shows the three most recent emails, a Booking proposal when relevant, and the reply composer. Older history remains accessible. Received/sent direction, sender, recipient, timestamp and attachments remain identifiable. Recovered quoted history is labelled; unknown provider quote text remains a safe plain-text expansion rather than a claimed standalone email.
- Read the exchange and check the exact source mailbox.
- Write a reply, choose an approved saved response, or request optional AI wording.
- Edit the wording and inspect any proposed supporting facts.
- Select eligible files from the private communication library or permitted source.
- Review the From/Reply-To identity, personal signature and attachments.
- Explicitly approve send and inspect its resulting state.
All three writing paths use one editable composer. AI never sends automatically. Manual and saved-response replies remain usable without an AI key. Refreshing availability or receiving a newer email does not intentionally discard an edited reply; stale or failed sends remain available for recovery.
Replies use their originating Gmail account and Sent mailbox. Verified Gmail aliases can change the guest-facing From/Reply-To identity while retaining that account and privacy boundary. Each Soupy person has their own workplace signature, including on a shared mailbox. HTML signatures can contain links and hosted logos; the preview shows the exact approved identity. Saved responses remain unsigned. Queued delivery freezes the approved sender, signature and attachment revisions. Provider acceptance is separate from confirmed delivery.
Booking and other source contributions
A sufficiently complete table request can reveal an inline, availability-backed Booking draft. Review guest details, date/time, party, venue, Space and payment terms. A guest-named Space constrains the final allocation. Recheck availability without losing guest edits, then publish through Bookings' canonical command. The source email remains linked to the Booking under Inbox and mailbox authority.
After placement, the draft collapses to its result. A blank reply may receive editable wording based on actual Booking/Order state; existing wording is preserved with an insertion option. A reservation awaiting payment must not be worded as confirmed. Booking state is checked again before reply sending and provider delivery. Creating the conversational reply does not itself send it.
Ticketing and Sport can contribute current event facts when authorized. CRM can contribute relationship/consent context when authorized. A service reply creates no marketing consent. Unsupported calendar or external effects are unavailable; a suggested next step does not execute another product's command.
Reply work, internal work and follow-ups
When the business's optional outstanding-work control is enabled, each email has two separate obligations: reply work and internal work. Each can be unassessed, needed, waiting or resolved.
| View or send choice | Meaning |
|---|---|
| Needs attention | Outstanding work, including unassessed mail |
| Needs reply | Reply work explicitly needed |
| Needs action | Internal work explicitly needed |
| Waiting | Work depends on the customer or team |
| Updates | Both obligations resolved |
| Send | Preserve the recorded work state |
| Send and wait | Set reply work waiting after successful provider acceptance |
| Send and resolve | Resolve reply work only after successful provider acceptance |
Internal work survives reply sending. New inbound mail requires reassessment and preserves unresolved internal work and ownership. Closing outstanding work needs an explicit resolution choice. The conversation's eligible assignee owns a manual follow-up date/time in Europe/London; ambiguous clock changes need a choice.
Follow-ups appear in Inbox and My Work. They do not create reminder notifications, customer follow-up messages or an independently completable generic Task. Disabling the control hides those views/projections while retaining decisions and ordinary Inbox use. The control is separate from AI classifier rollout.
Forms and submission review
Use Manage forms from Form submissions to create or edit an intake form. Configure its internal name, public title, description, confirmation message and privacy notice. Fields can be reordered, required and given help text/placeholders. Supported types are short/long text, email, phone, number, date, single/multiple choice, checkbox and consent. Optional contact mappings identify name/email/phone.
Save the draft, preview it and explicitly publish a version before embedding. The builder provides public preview plus copyable inline or button embed code. Enable/disable controls govern availability. Draft changes do not alter the live schema until publication; old submissions retain their exact published version.
Submission stages are New, Reviewing, Qualified, Closed and Spam. Read every answer against that version, contact the mapped address/phone where appropriate and choose the stage. A mapped contact does not automatically create a CRM customer or marketing permission. Supported private-event intake can hand a reviewed request to Bookings without turning the form into a Booking itself.
Optional classifier and historical review
Rules-based current-message triage always remains available. Optional Jev classification is governed per business as off, shadow, suggestions or automatic labels. Suggestions disclose provenance and can be accepted or corrected. Corrections remain attributable and survive another classification of the same message. Labels do not send mail, create Bookings, move/close mail or confer consent.
Current policy and source authority are checked immediately before each provider attempt, including retries. Withdrawal prevents a later send; it cannot recall data already transmitted under valid authority. Historical classification keeps its original platform approval and selected-message scope.
/app/<orgSlug>/inbox/review is an independent historical-review surface, not the
ordinary category picker. Reviewers label selected evidence before seeing model
answers; held-out answers remain sealed until formal evaluation. Eligible label
correction preserves an audit trail. Formal evaluation locks the cohort.
Historical batches, model policy and activation are governed platform operations;
a batch's existence or confidence score does not establish measured accuracy.