The Digital Workers Pool

The Digital Workers pool (the Digital Workers tab in the top navigation) is where every conversation your workers are handling shows up — across portal, in-app, email, Slack, and Microsoft Teams. Open it to read threads, review and send drafts a worker held for approval, and approve or reject actions a worker proposed. You can view the pool two ways, switched with the Board and List buttons in the header:

• Board — a column per status; drag a conversation between columns to change its status.
• List — a status-tabbed list with an inline detail pane on the right.

​

Scoping which workers you see

Use the worker scope selector in the header:

• All workers — conversations from every worker in the workspace.
• My workers — only the workers you belong to (you’re in the worker’s reviewer pool, or you own an account it handles).

Admins and builders default to All workers; everyone else defaults to My workers. When the scope is My workers, a Refresh My workers button appears next to the selector. Click it after CSM-pool or account-owner changes to recompute which workers are “yours” and reload the threads.

​

Filtering by assignee

The assignee chips narrow the list by who owns each conversation (pick one; click it again to clear): You can further narrow the list with the standard filter bar (by account, channel, and more).

​

Conversation statuses

Each conversation has a status: In Progress, Needs Response (a reply is waiting on a human), On Hold, or Closed. Some workspaces also have Waiting on Customer and Waiting on Us. In Board view each status is a column; in List view it’s a tab.

​

Proactive outreach

When a worker sends a proactive email, Statisfy opens the email’s conversation right away instead of waiting for the customer’s reply. The conversation belongs to the worker and the email’s account, has no human assignee, and starts in Waiting on Customer (or In Progress if your workspace doesn’t have that status). If the email is a follow-up on a thread that already has a conversation, the email is added to that conversation and its status doesn’t change. An email an approver sends from their own mailbox (send as yourself) doesn’t open a conversation at send. The customer’s reply opens it, as before. Most proactive emails never get a reply, so the Conversations tab leaves out a proactive email’s conversation until the customer replies. It still shows there if a person is assigned to it or has taken it over. When the customer replies, the conversation moves to In Progress and appears on the Conversations tab. Auto-replies (such as out-of-office messages) and bounces don’t count as replies.

​

The Proactive Outreach tab

The Proactive Outreach tab, next to Conversations at the top of the page, lists every conversation a worker’s proactive email went out on, replied to or not. Use it to follow up on outreach that’s still waiting on the customer, or to see which emails got answers.

• All, Awaiting reply, and Replied buttons narrow the list. The tab opens on All.
• The number of matching conversations shows on the right of the header.
• Each card carries a Replied or Awaiting reply badge.
• The filter bar works as on the Conversations tab, and the worker scope selector applies to both tabs. The assignee filter isn’t carried over, since nobody is assigned to a worker’s email.

Click a conversation to open it in the detail pane, as in List view.

​

Opening a conversation

Click a conversation to open its detail. The Details tab shows:

• Status — change it here (or, in Board view, by dragging the card).
• Assignee — assign the conversation to a person from the worker’s reviewer pool. Leaving it unassigned means the worker manages it.
• Digital owner — the worker responsible, with Take over below it (see Taking a conversation over).
• AI details — for a held draft, what the worker did to produce it.

Below that, collapsible panels show the customer context (with an Open account link) and recent activity.

​

Taking a conversation over

To handle a conversation yourself, click Take over under the worker’s name. The worker then stays out of it: it doesn’t reply or draft, sends no acknowledgement on email, Slack or Teams, and doesn’t send an email it had planned into that conversation (it waits for a person instead). You become the conversation’s owner, so you need to be someone it can be assigned to. Each new customer message moves it to Needs Response. Drafts the worker had already written stay for you to send, edit or discard. On the portal and in the in-app chat, the customer’s message is saved and they see the same acknowledgement as when a reply is held. You answer from the conversation. The card shows who took it over. When you’re done, click Hand back, followed by the worker’s name: the worker answers the customer’s next message again, and the conversation has no owner, so it’s back under Auto-managed by Worker. If the customer is still waiting for a reply (the conversation is in Needs Response), you stay its owner, so it stays in your queue. Anyone the conversation can be assigned to can take it over; for anyone else Take over is unavailable and says why. Once someone has taken it over, nobody else can until it’s handed back, and anyone on your team can hand it back. If someone takes it over while the worker is already writing a reply, that reply is dropped.

​

Reviewing and sending a held reply

When a worker’s autonomy holds a reply (HIL, or the worker deferred), the conversation lands in the response-needed status (often Needs Response) with the drafted reply ready to review. Edit it if needed and send. For Slack, a Send as selector lets you post as yourself or as the worker before sending. Microsoft Teams has no Send as selector: the Statisfy app posts the reply in the customer’s thread, led by the worker’s name in bold. (Edits autosave — you’ll see Saving… / Saved as you type.) A reply the worker sent without review, rather than held, says Sent on its own beside its time in the thread. Drafts don’t pile up behind an answer. When someone on your team answers the customer directly, or sends one of the worker’s drafts, the worker’s older drafts in that conversation are closed and show as dismissed: “Someone on the team answered the customer.” A draft written after that answer stays for review. If the worker hits an error and can’t finish its reply, the conversation moves to Needs Response for a person, so the customer’s message doesn’t wait unseen.

​

Approving proposed tool calls

If a worker proposes an action that needs approval (for example, creating Jira tickets), it appears as a tool-approval card in the conversation: “Review the pending tool call(s). Approve runs them; Dismiss rejects them.” When several calls are bundled, you can approve or dismiss them individually or all at once. Nothing runs until you approve.

​

When a worker escalates to a human

Some questions a worker must not answer on its own. Instead of only marking the task blocked, the worker escalates the decision to a human. A worker escalates when a customer:

• Asks about pricing, discounts, contract terms, or legal matters
• Signals cancellation intent, mentions evaluating a competitor, or expresses doubt about renewing
• Presents account data that contradicts itself

The escalation arrives as an escalation card in the queue of the same person who reviews the worker’s held drafts. The card carries:

• Reason — what the human needs to decide and why, often quoting the customer.
• Urgency — urgent (revenue or the relationship is at risk now), normal (needs a decision this week), or low (FYI).
• Recommended action — optionally, what the worker would do if the call were its own.

While the escalation is open, the worker continues with the parts of its task that don’t depend on the decision. It sends the customer a brief acknowledgement rather than arguing the escalated point. Each open matter gets its own card: if the worker raises the same matter again, it updates the existing card instead of opening a second one.

​

Related