Work every cold outbound reply from one shared queue

Build me a morning triage app where my sales reps work every reply our cold outbound gets in LeadsForge, so they stop living in a shared mailbox. This is a human working surface, not a notifier. It is for the replies that need judgement, and a rep is always the one who presses send.

The app opens on a single queue of LeadsForge inbox threads, loaded with List Threads using its sentiment, label and search filters. Positive replies and direct questions float to the top of the queue and everything else sits below. Each row shows the prospect's name and email, the campaign or mailbox the reply came from, a one line preview of their last message, and how long they have been waiting since that message arrived. Show the waiting time prominently and flag anything past a configurable threshold, for example twenty four hours, as overdue. Give the rep filter controls at the top of the queue for sentiment, label and a free text search, passed straight through to List Threads, plus a toggle between the whole team's queue and just the threads that rep has claimed.

Clicking a row opens a two panel detail view. On the left, the full conversation rendered from Get Thread, oldest message first, so the rep can read the entire back and forth including what our sequence originally sent. On the right, a CRM panel that runs HubSpot Search Contacts and Search Deals on the prospect's email address. Show whether this person already exists as a contact, with their lifecycle stage, company and owner if they do, and list any open deals with stage and amount. Make the empty states explicit: "Not in HubSpot yet" and "No open deals" are useful answers, so the rep instantly knows whether this is a fresh prospect or someone the team is already working.

From the detail view the rep has three actions. The first is Draft reply, which kicks off a background agent inside the app. The agent reads the whole thread from Get Thread plus the CRM context already fetched for that prospect, works out what the prospect is actually asking, and writes a proposed reply in the rep's voice: answer the question, address the objection, or propose next steps and times if they are asking to talk. The agent writes its draft back into the app's database against that thread, and the app shows it in an editable text box next to the conversation, labelled clearly as a suggestion. Show a pending state on the row and in the detail view while the agent is running. The agent must never send anything itself.

The second action is Send. The rep edits the draft, or writes their own text from scratch, and presses send. Only then does the app call LeadsForge Reply To Email to post the reply into the thread. Sending marks the thread handled for the team and records who sent it and when. Never wire Reply To Email to the agent or to any automatic path. The send button is the only thing in the app that calls it.

The third action is Qualify, for when the reply is genuinely interested. It opens a small form prefilled from the thread and the CRM lookup, and on submit creates the person with HubSpot Create Contact and the opportunity with HubSpot Create Deal, associating the deal to the contact. If Search Contacts already found the person, skip the contact create and just open the deal against the existing contact. Let the rep set the deal name, pipeline, stage and amount before submitting, and refresh the CRM panel afterwards so the new records show.

Keep all triage state in the General Input Database, keyed by thread and by rep, because LeadsForge has nowhere to store it. Store a claim, so a rep can take a thread, it shows as theirs with their name on the row, and two reps never answer the same prospect. Warn before opening a thread someone else has claimed, and let a claim be released. Store snoozed, with a wake time, so a maybe later reply drops out of the queue and comes back on the chosen date. Store handled, set when a reply is sent or when the rep dismisses a thread as done, for example a hard no or an out of office. Handled and snoozed threads leave the main queue so it empties as the team works it, and give the rep separate views for snoozed and recently handled threads. Also store the agent's drafts and the sent history per thread.

Two rules to bake in throughout. The agent proposes and a human disposes: nothing reaches a prospect without a rep pressing send. And every piece of triage state lives in the app's own database rather than in LeadsForge, so the app is the single source of truth for who is working what.