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. 

‍

‍

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:

1. Algo: AI, rule-based, or hybrid 
2. Rules and variables to include: invoice #, customer email, customer name 
3. Combination of (2) that is acceptable to match and how to handle partial match (ex. found customer name but not invoice #)
4. 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.

‍

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. 

‍