Dunning as policy, not as a monthly decision.
Collections is the process most retailers run by hand and least want to be inconsistent about. Conduit takes the policy once — thresholds, timing, fees, holds — and applies it to every past-due account every day.
Off your desk
You stop running the aging report by hand and deciding, account by account, who gets a notice this week.
Without this
What this looks like today.
The aging report gets run, somebody reads down it, and decisions are made account by account about who gets a notice this week. It is slow, and worse, it is inconsistent: two customers in the same position get different treatment depending on who was reading and how busy the week was.
Inconsistency in collections is not just untidy. Disconnection is regulated, notice periods are prescribed, and weather moratoriums are not optional. A process that lives in somebody's judgement is a process you cannot evidence when asked to.
And the ending is the hard part. A disconnect is a market transaction, so the collections process has to reach into the market and back — which is exactly the seam where a manual process drops things.
How it works
Collections, in detail.
The path from past due to disconnect, encoded once as policy instead of relived every month.
Your policy, configured once
Thresholds, notice timing, grace periods, fees and the steps between past due and disconnect are configuration. You describe your policy; the sweep applies it. Changing the policy changes what happens tomorrow, uniformly, without re-training anybody.
A daily sweep, not a report someone remembers
Every past-due account is measured against the policy each day. Notices go out on the day they are due, fees apply where you said they should, and accounts move between stages on their own. What a person sees is a worked queue of accounts needing a decision, not a list of everything.
Disconnect and reconnect bridged to the market
An account reaching disconnect becomes a 650 service order to the TDU, and the reconnect after payment goes back the same way. The collections path and the market chain are the same system, so nothing has to be re-entered at the moment it matters most.
Moratoriums and a switch that stops everything
Weather moratoriums hold accounts automatically rather than relying on somebody noticing the forecast. There is also a global pause — one switch that stops the whole engine — because some months you need to stop, immediately, and explain later.
Deferred payment arrangements
A customer who agrees to a plan comes off the dunning path and onto the plan, and the arrangement posts to the ledger like any other financial agreement. Breaking it puts them back, without anybody manually re-adding them.
At a glance
- Dunning policy you configure: thresholds, notice timing, grace periods, fees
- A worked operator queue rather than a report someone remembers to run
- Disconnect and reconnect bridged to the market as 650 service orders
- Weather moratoriums and a global pause switch, because some months you must stop
Connected
What this leans on.
Nothing here is a separate product with an integration between it and the rest. These are the capabilities this one shares a record and a ledger with.
Questions
The ones we actually get.
Does Conduit disconnect customers automatically?
It queues the 650, it does not fire it unattended. Accounts reaching disconnect arrive in an operator queue with the policy's reasoning attached, and a person releases them. The automation removes the clerical work, not the decision.
How are weather moratoriums handled?
As holds applied by the engine rather than by someone watching a forecast. Affected accounts move to a held state and stay there until the moratorium lifts, and the reason for the hold is visible on the account.
Can we stop collections entirely, at short notice?
Yes. There is a global pause that stops the engine outright. It exists because the realistic emergency is not a mis-set threshold, it is a day when nothing should go out at all and there is no time to reason about configuration.
Is collections part of the core platform?
No, it is an opt-in module. Most retailers add it once the book is large enough to have a genuine past-due problem, which is later than they expect and earlier than they would like.
The rest of the platform
One customer record, one ledger, one audit trail.
See it against your own book.
Bring a month of real transactions and a TDSP invoice. Collections is easier to judge against data you already argue about than against a demo tenant.