Reading the demo
A quiet thread is a reason to look.
Open the Follow-up Radar and compare the threads near the top. The prototype calculates a score from elapsed days and fixed weights for the thread category, contact and message count. These weights are design choices in the example, not a model validated against customer outcomes.
A long gap might mean a missed reply. It could also mean the customer asked to wait, the conversation moved to a call, or no answer was expected. A production tool would need that context before treating silence as a problem.
The useful test is whether the view helps a person find a thread they would otherwise overlook. The demo does not measure triage time, hours saved or changes in client retention.
Interface decisions
What the prototype lets you inspect
The demo makes several design choices visible. None establishes that the same approach would work unchanged in a real inbox.
Follow-up Radar
Start with threads worth reviewing
The radar puts a shortlist ahead of the normal message stream. Inspect the subject, contact and elapsed time to understand why an item is present. A useful next step would be a link to the actual conversation, with permissions checked for the person opening it.
Ranking
Make the score challengeable
The example multiplies elapsed days by several fixed weights and assigns priority bands. A large score means the thread matches those assumptions. It does not establish urgency, customer dissatisfaction or lost revenue.
For a real team, test false alarms as well as missed threads. People need a way to mark a conversation as waiting deliberately or already handled elsewhere.
Draft action
Separate a clicked button from a created draft
The artifact calls a host sendPrompt function when one exists. Without that host function, the button still shows temporary drafting feedback, but it does not create a mailbox draft. The public demo therefore cannot demonstrate a working email drafting integration.
A production version would need a confirmed draft location and a clear failure state. Sending would require its own deliberate action and permissions.
Decision
Keep the conversation available
The person reviewing the thread needs enough context to decide whether a reply is appropriate. A ranking can help choose where to look; it cannot replace reading the conversation or checking who owns the next action.
Testing the idea
A higher score should prompt a review of the thread.
Before building a connector, watch a team use the shortlist with representative sample threads. Record useful finds, false alarms and missed conversations. Measure any time saving rather than borrowing the numbers shown in the demo.
Measure the existing follow-up workload before assigning a value to the idea.
What manual follow-up costs each week ->Before real mailbox use
The connector is only part of the work.
Real email introduces access controls, sensitive correspondence and shared ownership. The demo does not establish how any of these would be handled.
For Gmail, Google documents separate permission scopes for reading mail and other actions. Choose only the access the product needs; a read view does not justify requesting permission to send.
Production requirements
Decisions to make with the team
Access: define which mailboxes and threads each person can see, and how access is revoked.
Data handling: agree what is retained, where it is processed and how deletion works before connecting a mailbox.
Ranking: test the weights against real follow-up expectations, including planned waiting and conversations completed elsewhere.
Drafts: confirm whether a draft was created, show where it lives, and handle connector failure without implying success.
Ownership: show who is responsible for the next action so a shared shortlist does not produce duplicate replies.
