Your reminder emails are read by nobody: where the sequence actually breaks

Before anyone rewrites the copy, establish whether the message is arriving in front of a human being who is permitted to pay it. Non-response in business-to-business collections is overwhelmingly an addressing, routing and completeness problem. The sequence is technically sending, the reports look healthy, and the messages are landing in a shared mailbox that files them by rule, in a ticket queue with no assignee, or in front of somebody who left in March.

This matters because the usual response to silence is to escalate tone and frequency. That produces a firmer message going to the same dead address, and eventually a customer who is annoyed on the one occasion a message does reach them. Fix the route first; the wording is the cheapest variable and almost never the binding one.

Delivered, opened, replied — measured per contact, not per campaign

The campaign-level open rate hides everything worth knowing. Run this per contact, over the last 90 days, before changing a single line of copy.

1. Split the funnel into 3 numbers. Accepted by their mail server, opened, replied. High delivery with no opens points at filtering or a mailbox nobody reads. Opens with no replies points at a message that cannot be acted on.
2. Classify every bounce. A hard bounce is a leaver or a dead domain and should immediately mark the contact invalid. Repeated soft bounces on one address usually mean a full mailbox nobody owns.
3. Read the auto-replies as data. Out-of-office, ticket acknowledgements and "no longer with the company" notices are structured facts about the route, and most collections tools throw them away.
4. Determine whether the address is a person. A generic accounts payable address is a queue with a filing rule; a named address is a person with a calendar. The follow-up you send differs completely.
5. Probe once with a request that forces an answer. A statement of account asking for confirmation of what is receivable will get a reply from a working AP function even when reminders do not. Silence to that is diagnostic.
6. Confirm your sending domain authenticates. Alignment across the usual sender-authentication mechanisms — SPF, DKIM and DMARC — is worth verifying with whoever runs your mail, because a receivables sequence sent from a subdomain nobody authorised looks exactly like fraud to a filter.

A collections sequence with excellent delivery statistics and no replies is not underperforming. It is sending mail to a room with nobody in it.

Their purchase order number is the field that makes the invoice payable

A large accounts payable function does not pay invoices, it clears matched documents. The match is against their purchase order and their receipt, and it is keyed on their reference — not yours. A reminder quoting only your invoice number asks a clerk to search backwards from an amount, which is work they will not do for a supplier who is not currently blocking anything.

• Capture the reference at order entry, not at chasing time. If the purchase order number is not a required field before an order is accepted, you will be reconstructing it under pressure at day 45, against a customer who went quiet at day 30.
• Put it in the subject line. The subject is what gets searched and what a filing rule reads, so the buyer's reference belongs there alongside the amount.
• Do not split or merge against their order. An invoice covering 2 of their purchase orders cannot be matched by their system without a manual exception, which is the slowest queue they have.
• Attach the invoice as a file. A link behind a login is a task; a document is evidence they can drop into their own workflow immediately.
• State the dispute route explicitly. If part of the amount is contested, say where that goes, because an unstated deduction turns into a silent short payment — the mechanics of which are set out in running a deduction dispute to closure.

Five reasons the message is ignored, in the order to check them

The second row deserves its own attention because it is the only one where nobody is ignoring you. The invoice does not exist at their end, so no amount of chasing the amount will work; what is needed is confirmation that a document was accepted, which is a different event from a document being sent.

Turning bounces and auto-acknowledgements into contact state

Every automated response your sequence receives is a fact about the route, and most receivables stacks discard all of them. Each maps to a state change on the contact record, and once those state changes are made the sequence stops repeating a known failure.

• Ticket acknowledgement. Store the reference, switch the thread to reply-into-ticket, and treat an ageing ticket with no human response as an escalation trigger in its own right.
• Out-of-office with a return date. Hold the sequence until the date rather than sending 3 more messages into an empty chair, and record the named cover contact.
• Leaver notice. Mark the address invalid, promote the secondary contact, and raise a task to confirm the replacement rather than guessing from a signature block.
• Portal-only notice. Some buyers reply only to say they accept invoices through a portal. That is a workflow change, not a message, and it should update how the account is billed.

Parsing this reliably is the kind of narrow, high-volume classification work that suits agent and automation builds, on the same principle that makes automation which outputs an action rather than a score worth building: the useful output is not a sentiment label on the reply, it is a changed field on the contact and a suppressed send.

Landing before the payment run instead of after it

Most accounts payable functions pay in batches on a fixed rhythm — weekly, twice monthly, or on a cut-off a few days before month end. A reminder arriving the morning after that run has missed its window by construction, and the customer is not being difficult when they do not reply: there is nothing they can do for another 6 days.

This is knowable per account and worth storing as 2 fields: run day and cut-off. Ask once, record both, and schedule sends to land 2 to 3 working days ahead of the cut-off. Where the run day is unknown, reply timestamps give it away — if answers cluster on Tuesdays, the run is on Wednesday. That is 2 numbers per customer, and they move the response rate further than any rewrite of the message body.

That last rule depends on cash being applied promptly enough to be visible, which is why a slow matching process shows up as a collections problem rather than as an accounting one. If receipts sit unmatched for days, look at the cash-application matcher, and if the amounts never quite line up, at why payments keep landing a little short.

The contact record a sequence can actually be driven from

All of the above collapses into one object. A collections contact is not an email address on a customer master; it is a route with a state, a permission and an owner, and it should be modelled with the same seriousness as permission is modelled in bank data — recorded explicitly, versioned, and never inferred from the fact that someone once replied.

• Route type. Named person, shared mailbox, ticket queue or portal — each takes a different message and a different follow-up.
• Validity state and evidence. Valid, bouncing, leaver, unknown, with the message that last proved it.
• Their references. Purchase order numbers, supplier number, entity and tax registration as their system holds them.
• Timing fields. Payment run day, cut-off, and any invoice submission deadline they have told you about.
• Last meaningful contact. Not the last send — the last time a human at their end did something.

Get those 5 groups populated and the sequence starts behaving like an operational process rather than a mailing list. The wider set of decisions around it lives under receivables, collections and cash application, and the systems work sits with finance operations builds.

• collections
• dunning
• receivables
• email operations