Karla Sellers@ 9:05 AM
Text SentSMSShow
The conversation-led view of Contacts. One place to triage the thread list, read the full activity feed, reply across every channel, and see who you are talking to — without opening a second tab.
The Inbox exists to kill the context-switching between list, timeline and compose. It is the first real View; the others follow it. The feed inside it is the same feed as the customer profile, repackaged rather than forked, so a message looks and behaves identically wherever you read it.
Two failures it is deliberately built to prevent: missing an incoming message, and a human and DAISI replying to the same customer at the same time.
SourceLoom walkthroughPRD
| Date | Ruling |
|---|---|
| 08-06 | Nothing is pre-selected when the Inbox opens — the detail side holds an empty select-a-customer state until a row is chosen, so the first thing a rep reads is their own triage decision, not an arbitrary thread. |
| 08-06 | The unread badge counts incoming call, SMS and email only — logs and other non-incoming types never count, because the badge answers "who is waiting on me", not "what happened". |
| 08-06 | The unread dot is visually distinct from the customer-status colors — two signals that mean different things must never be read as one. |
| 08-06 | The row timestamp is the last call, text or email in either direction — not the last activity of any kind, so a system update never makes a cold thread look warm. |
| 08-06 | The row shows a generalized actor — Customer, Dealer, DAISI or Automation rather than a proper name, because at list density the class of sender is what triages the row. |
| 08-06 | The mobile row opens a quick view inside the Sales tab (now CRM) — only View Customer leaves for the full profile, keeping the triage loop intact on a phone. |
| 08-06 | Customer Details opens by default on desktop when width allows, and is a closed drawer on mobile — context is free where there is room and on demand where there is not. |
| 08-06 | Task creation is not in this composer — tasks live in the Agenda flow; the composer sends messages. |
| 08-06 | Switching DAISI from Agent to Assistant or Off cancels the autoresponder and any active run — the anti-double-talk rule, and the reason the control exists at all. |
| 08-06 | When an Assistant pause expires the autoresponder wakes again — a pause is a pause, not a silent mode change. |
| 08-06 | Every outbound path respects the customer's opt-out flags — DAISI Agent mode does not bypass them. |
| 08-06 | Vehicle of interest is the primary deal, defined as the most recently updated deal — one rule, so the panel and the row never disagree. |
| 09-02 | Opening a conversation marks it read (the mail-client model), and unread stays dealership-wide — one shared timestamp on the customer; the first opener clears it for the whole team, no per-user tracking. |
| 09-02 | View Customer lands on the customer's activity feed, not the profile — the customer name in the conversation header performs the same action; the vehicle/deal reference opens the deal; collapsed details sections toggle from the whole header row. |
| 09-02 | The customer Activity section adopts the Inbox pattern — canonical screen: comp-activity-feed-shell.html. The activity filter strip never hides on scroll; the fade-out treatment is retired. |
| 09-02 | DAISI Mode menu cleanup — equal row anatomy specced on the atom, Reset-to-Default retired for an X close, pause options visible in all modes, enabled only in Agent (a pause = a timed demotion to Assistant that auto-reverts), and the light-mode yellow ruling: dark ink on any yellow fill (≈10.2:1 AAA vs white's ≈1.5:1 fail). |
| 09-02 | Email subject is required on send — the composer draws the Subject row already; validation blocks a subject-less send. |
| 10-08 | Scheduled messages return to the composer (CPO) — a caret beside send on Text and Email; the scheduling logic is unchanged. |
| 10-09 | The Schedule message menu follows the time of day (CPO) — the same every day of the week, with Tomorrow always offered; dealers are always on the clock. |
What a row carries, and how an unread thread announces itself.
The same feature at two densities. Desktop is a tri-pane — views, the conversation list, and the activity feed with the composer, plus Customer Details alongside when width allows. Mobile is progressive disclosure — the list first, then a quick view of the conversation, with details arriving as a drawer. Both are live, interactive screens; open them rather than reading a squashed copy here.
The shared feed and the strip that sits above it.
How a reply gets written, and what happens when a channel is unavailable.
Calls start from the composer's Call mode — one green button — and run in the floating call card; Log records calls made off the system.
The mode control that keeps a human and the AI from talking over each other.
The context panel beside the conversation.
Where View Customer lands: the customer's Activity section rebuilt on the Inbox pattern — the same feed, composer and details panel, under the unchanged profile header. Canonical screen: comp-activity-feed-shell.html.
What the Inbox needs from the backend, and what it already has.
Open questions. What is the exact Inbox inclusion predicate? Do the other Views ship disabled, or wired with real counts? Is the next-step directive AI-generated or rules-derived? Does an Assistant pause persist per user and device, or on the customer record? And at what breakpoint does the composer collapse?