Front shared inbox command center for support leads

I want an app my support lead opens every morning to run our shared Front queue. It is a manager's console for a multi inbox setup: one screen that answers who is buried, what has been waiting longest, and what still needs an owner, with every fix available from that same screen. Front is the only integration, no second system is needed.

The main screen lists every inbox side by side, one card or row per inbox, from List Inboxes. For each inbox show the number of open conversations, the number that are still unassigned, and the age of the oldest conversation still waiting on us. Build those numbers by paging List Inbox Conversations filtered to open status and counting the results, and cache the counts when the screen loads with a manual refresh button, rather than recomputing them per row.

Next to the inbox summary, show a per teammate workload column built from List Teammates plus List Assigned Conversations. For each active teammate show how many open conversations they are currently carrying and the age of their oldest one, sorted most loaded first, so the lead can see instantly who is buried and who is free. Clicking a teammate filters the queue below to just their conversations.

Clicking an inbox opens the queue itself. Sort it oldest first by the time of the last inbound customer message, and put a running waiting clock on every row that ticks live in the browser. Each row expands inline to show the full thread from List Conversation Messages, along with any private notes already on it from List Conversation Comments, so the lead can read the whole context without switching to Front. Use Search Conversations only to power the search box at the top of the queue, never once per row.

The queue must only show what is genuinely waiting on us. Exclude any conversation that is both already assigned and whose most recent message is an outbound reply from a teammate. Keep everything unassigned, plus anything where the customer sent the last message, since those are still on our side of the court. Bake in a configurable waiting time threshold, saved in the app and editable from a settings panel, that turns a row red once the wait passes it, with an amber state as it approaches. Default it to four working hours.

Let the lead flip between all inboxes and a single inbox from the queue view without losing the sort. All inboxes reads from List Conversations, a single inbox reads from List Inbox Conversations, and the oldest first order, the search text, the teammate filter and the red threshold all survive the switch.

From any row the lead can act without leaving the queue: assign it to a teammate with Assign Conversation, using a picker populated from List Teammates; tag it with Add Tags to Conversation, using a picker populated from List Tags so only real existing tags are offered; leave a private note for whoever picks it up with Add Comment; and archive it with Update Conversation by setting the status to archived. Every action should update the row optimistically and then refresh it from Front, so the inbox counts and the workload column stay honest as the lead works.

Add a Triage the backlog button that kicks off a background agent over the unassigned conversations in whatever scope is currently on screen. For each conversation the agent reads the message history with List Conversation Messages, classifies it by topic and by urgency, applies the matching tag with Add Tags to Conversation, and leaves a private note with Add Comment naming a recommended owner and a suggested first move. Where the right owner is clear cut, for example an obvious billing question when one teammate owns billing, it assigns the conversation with Assign Conversation. Where it is ambiguous it leaves the conversation unassigned with the note in place, so the lead only arbitrates the rest. When the run finishes, show a summary inside the app listing every conversation it touched, the tag it applied, whether it assigned it and to whom, and its reasoning, so the lead can review the whole batch in one place.

Two constraints to build around. Front has no documented contact lookup operation, so identify the customer from the conversation recipients and the message history rather than expecting a contacts endpoint. Front rate limits are per company, between 50 and 200 requests per minute depending on plan, and Search Conversations costs about 2.5 times a normal call, so page through the queue with cursor pagination, cache the inbox and workload counts, and never fire a search or a per row message fetch for every visible row.