Mission Control

For: Everyone except consumers

Work arrives in a dozen places — an offer waiting on a decision, a closing step past its SLA, a follow-up you promised on Tuesday, a buyer circling a truck nobody is selling to. Mission Control is the one screen that asks every one of those queues the same question: what needs a person, and which person.

Nothing lives here. Every row is derived at read time from the record it is about, so the board can never disagree with the page it points at — close a task in CRM and it leaves the board, because the board was only ever reading the task.

How the board is organised

Rows are grouped by lifecycle phase — pre-listing, sale, post-sale, relationship — and ordered within a phase by what a person actually triages first:

1. Decisions — money is waiting on someone's answer
2. Overdue — a date has already passed
3. Due soon — today
4. Attention — worth this week
5. FYI — worth knowing, needs nobody

Bigger money breaks ties, then whatever has been waiting longest.

Whose work it is

Every row names who owes it, as a chip: you, someone else by name, a standing role like Fleet manager or Cypress, or Unassigned in amber — because work nobody owns is what quietly rots in a shared queue.

Three filters sit above the board:

The board is deliberately not mine-only. A queue you cannot see the whole of is a queue you cannot manage — the counts on each chip stay visible whichever one you are reading, so "nine unassigned" is a fact you notice rather than one you have to go looking for.

Giving work to an agent

When your organisation has connected an agent, a row about one thing (an offer, a closing, a vehicle, a contact, a company or a deal) or a task carries Delegate. Pick the agent and:

• a task becomes the agent's: the same task, now held by it;
• anything else becomes a task for the agent on that record (an offer's or a closing's on its vehicle), titled as the row and due when it is due.

Delegating the same row again while its task is open does not make a second one: you are told the agent already has it. A summary row ("4 deals gone quiet") cannot be delegated as a whole: open it and give its parts out one by one. The agent's work then shows on the CRM's Tasks tab under Made by agents, and an integration can do the same through the API (Mission Control for developers).

What it draws from

Summaries are still accounts

A triage board should not list next month as rows — but it must never be silent about work that exists. So each section closes its own books:

• "4 tasks scheduled — Next due Aug 27. 1 with no date set."
• "9 closings in progress — Next step due Aug 27. 2 with no due date."
• "6 more tasks due today or earlier" when the per-section cap trimmed the list

Undated work is always counted separately. A task nobody dated is not "later", it is unplanned — and it will never appear in any due-date filter on any screen, which makes it the easiest kind of work to lose.

This matters for reading the board honestly: an empty Mission Control means there is nothing, not that nothing was asked.

The Cypress-handled lane

The second lane is a receipt, not a queue. It shows what the platform did on its own overnight — automation runs, auto-processed offers, campaign sends — each marked with what Cedar did and when. These are excluded from the open-work count, and they are mirrored onto the record's own timeline so a vehicle's history reads the same whether a human or a rule moved it.

Trust in automation is built by showing the work, not by hiding it.

Acting for an organisation

A Cypress Manager using the acting-for lens sees that organisation's board — their tasks, their closings, their offers. Both halves of the screen move together: the vehicles and the CRM work belong to the same org, always.

Acting for an organisation, staff work its book as it does: Delegate offers its agents, and a task can be given to its people and agents as well as to Cypress colleagues (marked "(Cypress)" in the picker). With no organisation chosen, staff work Cypress's own book, which has no agents.

Business rules

• Rows are derived, never stored. There is no separate board to fall out of sync.
• A row you cannot action does not appear — the board is scoped exactly like the pages it links to.
• Aggregates say what they count: 34 contacts, 9 closings, 4 tasks — never a generic total.

Under the hood

Each source is an independent adapter, and they are gathered with Promise.allSettled — one failing queue reports itself as unavailable rather than emptying the board, because a board silently missing a source looks identical to a board with nothing to show.