The situation
In most Indian SMEs, collections don't live in a system. They live in a chat group.
Someone posts that a client has promised payment on Friday. Someone else confirms a transfer landed. A third person asks about an invoice from six weeks ago. It's all there, it's all current, and it is completely unusable as management information — because turning it into a number means one person scrolling back through a week of messages on a Sunday.
The result is familiar: everyone in the business has a feeling about receivables, nobody has a figure, and the MIS arrives three weeks after it could have changed anything.
The instinct is to buy a CRM. The reality is that the team will keep using the chat group, and the CRM will be updated by nobody.
What was built
An agent that reads the group the team already uses and produces the report nobody has time to assemble.
- Scheduled, not requested. It runs on a cron each evening — no one has to remember to ask.
- Deterministic extraction. A parser pulls payment mentions, promises, amounts and client references out of the message structure. Code, not comprehension.
- Analysed, then written. The model takes the structured output and produces the commentary — what moved, what's overdue, what was promised and hasn't landed.
- Emailed to the people who act on it, in their inbox before the evening is over.
- Installed with one command. The whole capability is a skill: point it at a group, name the recipients, done.
It runs on BizClaw, alongside the other agents — which means it inherits the same isolation, the same trust boundaries and the same discipline layer as everything else on the platform.
The numbers come from a parser
Where this system can be wrong
Ask a language model to read forty chat messages and tell you how much came in today, and it will give you a number. It will be confident. It will sometimes be wrong, and you will not be able to tell which time.
So the model never does the arithmetic. A dedicated script parses the group's message structure deterministically — regular expressions against known formats, same input producing the same output every time — and returns structured data. The model writes the narrative around numbers it did not compute.
This is a house rule rather than a one-off decision. Every skill on the platform ships against a checklist whose second item is deterministic code: anything code can do reliably must not be done by reasoning. Our own documentation puts it more bluntly — the agent had the right tool and chose cleverness instead of discipline.
And because a rule nobody measures is a rule nobody follows, there's an installable scorecard whose only job is to check whether the agent is actually calling those scripts or quietly improvising. Compliance is tracked, not assumed.
For a receivables report that lands in a founder's inbox and gets acted on the next morning, that distinction is the entire product.
What happened
The report goes out daily, on schedule, to named stakeholders. The team didn't change how they work — they still post in the group — and the business gained a daily number it previously got monthly, if at all.
The unglamorous observation worth passing on: the win here isn't intelligence, it's cadence. A mediocre report every day beats an excellent one every quarter, because only one of them arrives while you can still do something about the client who hasn't paid.
The second observation is about adoption. Nobody was asked to learn anything, log in anywhere, or maintain a record. The system met the team inside the habit they already had. Every collections tool that fails, fails on that.
Why this pairs with the advisory work
Receivables is where SME cash crises actually begin, and it's the first thing we look at in a financial health engagement. Having the daily number automated changes the conversation from what do you think your position is to here is the position, what are we doing about it.
That's the shape of the whole practice in one example: the advisory identifies what matters, and the engineering makes it observable without adding work to anyone's day.
What made it repeatable
It ships as an installable skill rather than a bespoke build. Point it at a group, set the recipients, choose the schedule. A sibling skill does the same for a lightweight sales pipeline — leads, stages and deals tracked in the group with a weekly summary by email.
Both follow the same rule: the chat group stays the interface, code does the extraction, the model does the writing, and a human gets a document they can act on.
The engagement shape
- Find the number that arrives too late — receivables, pipeline, utilisation, stock. Every business has one.
- Find where the raw material already is. Usually a chat group, an inbox, or a spreadsheet someone maintains by hand.
- Write the parser first, so the figures are reproducible before anything writes prose about them.
- Schedule it and route it to the people who can act, at a time they can act.
Days, not weeks. It's usually the cheapest engagement we do and the one clients notice first.
What's still open
Named, not hidden. A case study that admits open items is worth more than one that doesn't.
- The parser depends on how the team writes. It reads the formats the group actually uses. A team that changes how it posts will need the parser updated — which is a five-minute job, but it is a job, and pretending otherwise would be dishonest.
- It reports what was said, not what the bank shows. There's no ERP or bank reconciliation behind it yet. A promised payment that never arrived shows as promised until someone says so. Reconciliation is the obvious next step.
- One group at a time. Multi-entity businesses would need the schedule and routing generalised.
- No escalation logic. It reports; it doesn't chase. Automating the chase is a judgment call we'd want a client to make deliberately, not inherit by default.
Next case study
Smriti →