Your biggest debtors are behind a phone menu

Nearly everything published about chasing invoices quietly assumes a consumer debtor: you ring a mobile, a person answers, and you talk to the human who owes the money.

Business debtors don't work like that. You ring a landline, a recording answers, and it reads you a menu. And business debtors are usually the bigger invoices, which means the part of the ledger with the most money in it is the part with an obstacle in front of it that nobody writes about.

Two separate problems, not one

It's tempting to treat this as a single problem called "switchboards". It's two, and the second one is more interesting than the first.

1. Getting through the menu. A mechanical problem: hear the options, work out which one is accounts payable, press it.
2. Knowing who you've reached. Once you're through, you are not talking to the debtor. You're talking to an accounts clerk, and almost every collections script ever written is wrong for that person.

An accounts clerk is not the debtor

This is the part worth internalising whether you chase by phone yourself, hand it to staff, or automate it. The standard collections approach fails against a finance team for three specific reasons.

• They can't pay from their desk. "Are you able to settle that today? I can resend the payment link" is a reasonable question to a business owner and a nonsense one to a clerk. Worse, an unexpected caller pushing a payment link at a finance team reads as a scam, because that is exactly what scams do.
• They work by invoice number, not by story. An owner remembers the job. A clerk has a queue and needs a reference. If you can't give the invoice number, the purchase order, and the entity name in the first fifteen seconds, you can't be helped even by someone who wants to help you.
• They have no authority over timing. Payments go out in runs, on a schedule set above them. Pressure achieves nothing except making you the vendor they'd rather not deal with, and the fastest way to get quietly dropped from the next run is to be unpleasant to the person building it.

That fourth question is why this conversation is worth having at all. An invoice sitting unpaid at 60 days because it was never approved for want of a reference number is not a collections problem. It's an admin problem wearing a collections costume, and nobody finds it by sending a fifth reminder email.

Say who you're calling for, immediately

One more thing that matters more with a finance team than with anyone else: state whose behalf you're calling on in the opening sentence. A clerk who can't immediately tell which supplier you represent will treat you as a scam call, and they are right to. Bookkeepers and outsourced finance staff calling on behalf of a client have the same problem, and the same fix.

Where we're up to on the menu itself

We're building automated phone-menu navigation for exactly this reason, and we want to be straight about its status: it is built and tested, and it is not switched on for any live call yet. One link in the chain is still unconfirmed, which is whether a given real switchboard acts on the tone we send, and until that's settled with a proper control test it stays off.

What we can describe is how it's designed, because the design decisions are the interesting part and they're the same ones any careful person would make:

• Listen to the whole menu before deciding. Menus read options in sequence, so acting on a partial transcript is how you press 2 when accounts was 4.
• "Accounts receivable" is a trap, not a match. Receivable is the department chasing *their* debtors. We want the one that pays *ours*. It contains the word "accounts", so any naive keyword match ranks it highly, and it is scored heavily negative alongside sales and collections.
• A wrong key is worse than no key, because it puts your customer's name on a stranger's desk. Every ambiguous case gives up rather than guessing: no clear option, two plausible options, a second menu behind the first, all escalate to a note for the owner rather than a coin flip.
• Credentials are never keyed. An account number is a routing key and a PIN is a secret. If a menu asks for a PIN, password, card number or date of birth, the call ends without keying anything, every time, even where a reference is on file. "It's just digits" is how that boundary erodes.
• No disclosure to a machine. The AI-and-recording disclosure is held back while a menu is being navigated and delivered in full to the human it reaches. Announcing yourself to a recording means the person who eventually picks up hears nothing.

The account reference, where a switchboard demands one before routing anywhere, comes from the customer's account number field in Xero. Where it's blank, the call escalates with a note naming the debtor so it can be filled in once, in the place a bookkeeper is already working.

What to do about it today

Menu navigation aside, most of the value here is available immediately and manually, because the second problem was always the bigger one.

1. Separate business debtors from consumer debtors on the ledger. They need different scripts, different questions, and different expectations about timing. Treating them as one list is why the big invoices stall.
2. Fill in the account number field in Xero for the businesses that have one. It's useful long before anything is automated.
3. Ask the four questions, in that order, and write down the blocker. Then fix the blocker rather than sending another reminder.
4. Find out each large debtor's payment run. "We pay on the 15th and the 30th" changes your entire follow-up calendar, and it takes one call to learn once.

None of that needs software. What software adds is doing it on every business debtor, every cycle, instead of on the three you got around to. The wider sequence is in the 60-day chase ladder, and if your clients bill progressively, do the ledger split before any of it.

See it on your own Xero

Connect Xero and hear the AI teammate chase a quote and recover an overdue invoice by voice.

Keep reading