One Inbox for the Whole Shop: Why Four Message Screens Is the Actual Bug

A tuning shop does not have a chat problem. It has a four-inboxes problem: job threads in one place, support chats in another, tickets in a third, sales leads in a fourth. The Messages Center collapses those into one list that is ordered by who is waiting on you.

Why four inboxes is the actual bug

Picture a normal Tuesday. A dealer sends a read at 09:14 and asks a question inside the job. A retail customer opens a support chat at 09:20 because the download link expired. Somebody raises a ticket about an invoice at 09:31. A form fill lands at 09:40 from a shop that wants pricing.

Four people are waiting. In a portal with four separate screens, the only way to know that is to open four screens and read them all — and then do it again twenty minutes later, because there is no single place that can tell you whether anything changed. The cost is not the clicking. The cost is that the 09:20 customer waits until somebody happens to look at the right tab.

That is the problem the Messages Center exists to remove.

One list, ordered by who is waiting

Open /messages and the first tab is All. It is a single stream that weaves together every band the portal carries: job conversations, support chats, tickets, and leads. It is not a new query bolted on top — it interleaves the pages each band has already loaded, so the list costs no more to produce than the four screens it replaces.

The ordering is the part that matters. Anything that needs a human sorts first — an unanswered customer message, a ticket with no reply, a lead nobody has touched. Everything else falls in behind it, most recent first. The top of the list is therefore a work queue, not a timeline.

The tabs across the top are All · Needs you · Jobs · Support chats · Leads · Tickets. Each one is the complete archive for its band. That distinction is deliberate: the unified stream is for working, and the per-band tabs are for finding. A conversation from March is not in the stream any more, but it is exactly where you would expect it under its own tab.

Three columns, and why

The workspace is a rail, a conversation, and a context panel.

• Rail (left) — the stream and its tabs. Filters and unread counts live here.
• Conversation (centre) — the thread itself, with the compose box pinned at the bottom.
• Context (right) — who you are talking to and what about: the vehicle, the ECU, the job status, the credit balance, the previous work.

The third column is the one that changes how the day feels. Answering “can you do a Stage 1 on this?” well requires knowing the ECU family, whether you have tuned that calibration before, and whether the customer’s balance covers it. In a plain chat screen that is three lookups in three other tabs. Here it is already on screen, next to the sentence you are answering.

Unread is personal

This sounds like a detail and is not. In a shop with three technicians, “read” cannot be a property of the conversation — it has to be a property of the person. If a tuner opens a thread, that must not clear the badge for the two colleagues who have not seen it.

Each person carries their own read state. Your unread count is yours. It means the number in the sidebar is a real statement about your own work, which is the only version of that number anyone can act on.

A worked example

A dealer uploads an EDC17C64 read at 14:02 and writes “Stage 1 + DPF off, same as the last one”. Here is what the workspace does with that:

1. The job conversation enters the stream under Needs you, because the last message is inbound and unanswered.
2. The context panel shows the vehicle, the ECU family, and — because the file matched work already on the network — the last one they are referring to, with its modification list.
3. The tuner answers in the centre column, applies the tune, and the job moves out of “needs you” the moment it is answered.
4. The second technician’s badge still shows the thread as unread until they open it themselves.

No tab switching, no “which car was this again”, no reading the whole history to find what “the last one” meant.

The classic view is still there

The old single-column table did not get deleted. It answers at /messages/classic and reads from the same service as the new workspace, so nothing diverges between them. It is a safety net, and it is the honest kind: not a screenshot of an old design, but the same data rendered the old way, one route line apart.

What it does not do

It is not a CRM and does not try to be. It does not score leads, run sequences, or manage a pipeline. It is the place where the messages your shop already receives stop being scattered across four screens.

It is also not a replacement for your phone. Plenty of tuning happens over WhatsApp and always will. What the workspace does is make sure the things that arrive through the portal are in one place and ordered by urgency, so nothing sits unanswered because it landed in the tab nobody opened.

Frequently asked

Does everyone in the shop see the same inbox?

They see the same conversations, filtered by what their role allows. Read state is per person, so opening a thread clears your badge and nobody else’s.

Can I still get to old conversations?

Yes. The unified stream is for current work; each band keeps its own tab as a complete archive. Jobs, support chats, leads and tickets are each one click away, in full.

What happens to my existing threads?

Nothing. The workspace is a different view over the same data — no migration, no export, no re-import. Everything that existed before is there, ordered differently.

Does it work on a laptop screen?

Yes. The three columns collapse on narrower screens: the rail becomes a drawer and the context panel moves under the conversation, so the compose box stays reachable without horizontal scrolling.

Is there a way back if my team prefers the old layout?

The classic table is live at /messages/classic and reads the same service. Nothing is lost by trying the new one.