A lead conversation went quiet and nothing flagged it: the three things that catch a reply you owe

Modified on Tue, 4 Aug at 3:45 PM

You opened your email for something else and found a live lead thread sitting there, waiting on you. BSOS has been managing an email conversation with a lead through several back-and-forths, reporting each time a response came in, and then it stopped reporting. You noticed on your own that that conversation had fallen by the wayside, that the ball is in my court, and I need to respond, and that you got no indication of that from Otto. No card, no ping, no needs you notification. The performer who first raised this put the stake better than we could: It makes me uneasy to have the conversation fall through the cracks. He was right to be uneasy. This article explains why a conversation went cold without anything flagging it, and the three separate things that now catch a reply you owe.

The three nets, in one paragraph

First, the Inbox digest sets a conversation's status from the message itself the moment it arrives, so an owed reply is on the list whether or not Otto ever writes a draft. Second, the Handle the Reply play, once you switch it on, creates a durable job at the moment a reply is detected, so a run that fails to produce a draft becomes a card you can see instead of silence. Third, from version 1.11.13 onwards, a quiet sweep flags any managed conversation that nothing else has already flagged and that has sat three or more days with the ball in your court. Each one works without the other two.

Why a thread could go silent at all

If you are running an adopted terminal Booking HQ, the older setup driven from a terminal rather than from the desktop app, the diagnosis is real and worth understanding, because it explains exactly why nothing warned you.

In that setup the "needs human" notice lives in queue/needs-human.md, and every entry in that file is a gate block hung on an artifact Otto had already staged: send this draft, set this fee, approve this reply. A gate is opened as the last step of producing something. There is no gate for "nothing was produced, but a response is owed". So when a template gap stalled the draft before anything was produced, the chain broke at the first link: no artifact, therefore no gate, therefore no durable notice. What was left was one prose line in that day's briefing, and a briefing is a snapshot you have to open and read, not an alarm that keeps ringing until you clear it.

That is the real defect, and it is specific to the terminal version. The alarm sat downstream of the drafting, so the one case where you most needed to be told, drafting getting stuck, was the one case that produced silence. The desktop app is wired the other way round.

The dead end: reading the Today briefing harder

Almost everyone tries this first, and it is a dead end. The instinct is to read the Today briefing more carefully each morning, or to ask Otto for a rundown of open threads. Skip that. A briefing line is a snapshot of a moment and it is replaced by the next one; it cannot hold an item until you clear it, which is the entire job here. Three surfaces persist and are worth your attention instead: the Inbox digest, the card on your Activity board, and the three-day sweep. They are the three nets below.

Net 1: the Inbox digest sets the status from the message, not from the draft

When a reply comes in, the app pulls it into an always-on list, the digest, and sets its status from the message itself the moment it lands, into one of six groups: Needs you, Reply ready, Waiting on them, Follow ups, Handled or All good. That happens before, and regardless of, whether Otto ever drafts anything. This is the sentence that matters: the status does not depend on a draft existing. If drafting stalls, the conversation still sits in the list as owed.

  1. In the right pane, click Inbox in the tab row.
  2. Click Refresh in the top corner to pull in the latest conversations.
  3. Read the Needs you group first, then Follow ups. Those two are where a reply you owe shows up.

The full walk-through of all six groups, and of reviewing and sending a draft, is in "The Inbox: review drafted replies and send them yourself" in this same folder.

Net 2: switch on Handle the Reply so the to-do outlives a failed run

The digest tells you a reply is owed. The Handle the Reply play goes one step further and makes Otto's own work on it durable, so a failed run leaves a mark rather than nothing.

  1. Open Settings in the right pane tab row.
  2. Find the card called Plays that may start themselves.
  3. Find the Handle the Reply row and switch on its toggle, labeled Allow Handle the Reply to queue itself.

With it on, an incoming reply creates a durable job at detection time, not when a draft finishes. That job is a card on your Activity board from the moment it is queued, so a run that fails to produce anything leaves a mark instead of nothing. It retries, and once it has stopped trying it sits under Needs you reading Needs a look before it runs again. The signal is born with the reply.

Two things worth knowing. Every toggle in that card starts off, so this is opt-in and most people have never switched it on. And this job is raised for a reply on a conversation that is linked to a lead in your pipeline; anything not linked to a lead is still covered by the digest in Net 1, which is why the Inbox stays the first place to look.

Net 3: the quiet sweep, version 1.11.13 or newer

The ticket behind this article changed the product. Every managed conversation now gets a quiet-check on top of the arrival-time status. Any conversation that nothing else has already flagged, and that has gone three or more days with the ball in your court, is escalated to Needs you and carries its reason in plain words on the card: Went quiet with the ball in your court. That reason line is the sweep talking rather than the message itself, and it is the net that catches a thread that went quiet with the ball in your court for a reason nobody anticipated.

Be exact about the version: this net exists from 1.11.13 onwards. On any build older than that it does not exist and there is nothing to look for. To update, click Check for updates in the top bar, and when it tells you the newer version is ready, click Restart & install.

The quiet-check is done every time the digest is read, so opening the Inbox tab or pressing Refresh always gives you a current answer. As with everything else in the app, it happens while Booked Solid is open; nothing is being watched while the app is closed.

Updating never touches your Booking HQ

If you have hand-fixed your terminal setup, you may keep it. It is safe. The desktop updater only ever replaces the app itself and never touches your Booking HQ workspace, so hand edits survive every update. The wipe-on-update fear going around comes from the old terminal updater and does not apply to this app. There is more detail in "How updates work: the update badge and Restart & install" in the Installing & updating folder.

The one edge we know about

Here is the honest limit. A reply that comes in reading as routine, with no next action the app can pull out of it, lands in the All good group at arrival rather than in Needs you. On 1.11.13 and newer the three-day sweep is what catches that case, so it is a delay of up to three days rather than a hole. On older builds it genuinely is a hole. And a conversation the app holds no last-activity date for is never swept at all, deliberately, because we would rather miss a flag than raise one on a guess.

If you find a thread that stays silent past three days on a current version, that is a defect and we want to see it. Tell us the lead's name.

If it still does not surface

Open a ticket with four things: the lead's name, roughly when their last reply landed, which version of the app you are running, and whether Allow Handle the Reply to queue itself is switched on. That tells us which of the three nets should have caught it, which is the fastest route from your report to a fix.

Still stuck? Submit a ticket from this help center and we'll take it from there.

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article