Introducing Multi-Threading: Agentic Collections Get Smarter in Monk
Today we are releasing multi-threaded reasoning to agentic collections on the Monk Platform, making an already powerful collections module smarter.
Why multi-threading matters for email collection workflows
Customer is always right. And customers may decide to communicate about their payment in any email thread. This means a customer can send share thoughts about a PO#, credit memo, payment confirmation, or a dispute in an entirely separate email thread from the original invoice thread.
Previously, responses outside the main collections thread would confuse traditional dunning and create new work for the customer support and finance teams.
For agentic collections, this would mean the agent loses context. Not good.
With multi-threading, we are adding additional logic to an already powerful collections module to solve for this edge case.
.avif)
What were the technical challenges in building multi-threading
There are many open questions given that we need to be reliable systems that interacts with customers and finances.
For example, we had to figure out:
- Algo: AI, rule-based, or hybrid
- Rules and variables to include: invoice #, customer email, customer name
- Combination of (2) that is acceptable to match and how to handle partial match (ex. found customer name but not invoice #)
- Set of actions to allow if thread A is judged as related to thread B (ex. escalate, set promise to pay date)
And more to support partial edge cases.
Which signals multi-threading links back to an invoice
| Signal type | How multi-threading links it |
|---|---|
| Purchase orders (POs) | Connects a PO discussed in a separate thread back to the right invoice |
| Credit memos | Ties a credit memo reference to the related invoice and its context |
| Payment confirmations | Matches a payment confirmation in another thread to the original invoice |
| Disputes | Links a dispute raised outside the main thread back to the right invoice |
How to use multi-threading for agentic collections within Monk
Multi-threading is turned on by default for all customers. No new action needed.
This is another feature that takes your collections and AR-function to the next level.
To learn more, book a demo by following this link.
Frequently Asked Questions
What is multi-threading in agentic collections?
Multi-threading is added reasoning logic in Monk's agentic collections that links related email threads back to the right invoice, so when a customer discusses a PO number, credit memo, payment confirmation, or dispute in a separate thread, the AI agent keeps full context.
Why does multi-threading matter for email collection workflows?
Customers may communicate about a payment in any email thread, not just the original invoice thread. Without multi-threading, responses outside the main thread confuse traditional dunning and cause the agent to lose context, creating new work for finance and customer support teams.
How does Monk decide if two email threads are related?
Monk evaluates variables such as invoice number, customer email, and customer name using a combination of approaches, and it handles partial matches, for example when it finds a customer name but not an invoice number, before allowing actions on the linked thread.
What actions can the agent take when threads are linked?
Once a thread is judged related to an invoice, Monk can take defined actions such as escalating the issue or setting a promise-to-pay date, with additional logic to support partial edge cases.
Do I need to turn on multi-threading in Monk?
No. Multi-threading is turned on by default for all customers, so no new action is needed to benefit from it.
If this is the problem you are solving, these go deeper: Introducing Playbooks: A Workflow System for Intelligent Collections and Why Monk's Collections Inbox Looks Like Gmail.
.avif)