Needs You is empty and something is wrong
Needs You raises what something knew to raise: actions held for a decision, questions Connect could not settle, and operational faults it can detect. It does not raise work that never began, a limit that is a number rather than a fault, or a judgement about something already sent. An empty list means no open item, not that the business is being served.
What the symptom looks like#
The queue is clear and something is still wrong: a customer says they never got an answer, a week has passed with no outbound activity, or a channel has been quiet longer than the business is. Nothing is flagged, so there is nothing to click, and the natural conclusion — that Connect thinks everything is fine — is the wrong one to act on.
The queue is a list of open items, not a monitor. It answers 'what needs a person', and it is exact about that. It does not answer 'is everything working', and treating it as though it did is the mistake this page exists for.
What Needs You covers#
- Held actions: anything
ask_before_sendstopped, with the conversation it belongs to. - Questions the engine could not settle from knowledge or memory, phrased as the decision they want.
- Operational faults it can detect — a mailbox that stopped fetching, a line whose health has fallen, an integration that disconnected. Voice line health is read live rather than stored, so its entries appear and drain on their own.
- Follow-ups on the
taskchannel, which are work for a person because no drain will ever send them.
What it deliberately does not cover#
| Situation | Why the queue is quiet | Where it does show |
|---|---|---|
A channel set to off | No work is prepared, so nothing can be held | What Connect May Do — the mode is the whole story |
A channel set to draft_only | The mode prepares and stops without asking, by design | The conversation itself, and the decision log |
| A spent daily allowance | A limit reached is a number, not a fault | Plan & Usage, against the day's figures |
| A lapsed plan | The workspace's commercial state is not an operational item | Plan & Usage, and the plan pages |
| Nobody wrote to you | Nothing arrived, so nothing was missed | Conversations — an absence of inbound is visible there, not here |
| A poor answer that was sent | It succeeded; nothing detected a problem with it | The conversation and the decision log; quality is a human judgement |
What Connect did complete#
- It fetched, canonicalised and filed everything that arrived on a connected channel, whatever the outbound mode was.
- It recorded every decision it made in the period, including refusals and including actions it took without asking.
- It drained the operational entries whose causes had cleared, which is why an earlier item may be gone rather than lost.
- It ranked what remained by the cost of delay, so an empty list is genuinely empty rather than filtered.
What Connect did not complete#
- It did not raise an item for a channel it was told not to work on.
offanddraft_onlyare instructions, not faults, and a queue that argued with them would be useless. - It did not detect a provider that is accepting mail and delivering it nowhere; a mailbox can be healthy by every check available and still be in trouble at the far end.
- It did not judge the quality of anything already sent. Nothing re-reads a sent reply and decides it was wrong.
- It did not raise the absence of inbound work. Nothing knows how much mail you should have received.
Where to look instead, and when to escalate#
Open the decision log for the quiet period.
Result Refusals and held actions are both recorded there. A period with no entries at all is a much stronger signal than an empty queue.
Open What Connect May Do and read the mode per channel.
Result Most extended silences are a mode somebody set deliberately and nobody remembers.
Open Plan & Usage.
Result A spent allowance or a lapsed plan explains outbound silence without producing a single queue item.
Open the mailbox and phone screens and read health directly.
Result Health is shown there in full; the queue only escalates what crosses a threshold.
Escalate when the decision log is empty for a period in which mail demonstrably arrived. That combination — inbound present, decisions absent — is the one shape here that configuration does not explain.
Questions#
Should the queue ever be empty?
Often, yes. A workspace running autonomous on channels that are working well produces very few items, and that is the intended state rather than a warning sign. The reading only becomes unsafe when it is used as proof that nothing is wrong anywhere.
Can I make the queue raise more?
Indirectly: narrowing autonomy to ask_before_send puts more decisions in front of a person. That is a real trade — more oversight, slower replies — rather than a monitoring setting, and it is worth making on purpose.
Does an operational item come back if I fix the cause badly?
Yes. Those entries are derived from the underlying health rather than stored, so a mailbox that reconnects and fails again raises the item again. A recurring entry is a signal about the fix, not about the queue.