Why promises to pay get broken, and how to make them stick

What is a promise to pay, and how do you measure it?

A promise to pay, PTP in collections shorthand, is a specific commitment from the customer: this amount, on this date, by this method. "I'll sort it out soon" is not one. "I'll pay 150 euros on Friday by card" is. Collectors log promises because they are the clearest sign that a conversation went somewhere, and that is exactly why they get overcounted.

The number that matters is the kept promise rate: of the promises made in a period, the share paid in full by the agreed date, give or take a short grace window you define once and never change. Track partial payments separately, since a customer who promised 300 and paid 200 has told you something different from one who paid nothing. A team rewarded for promises made will collect plenty of them. A team measured on promises kept learns to ask for ones people can keep.

Why do promises to pay get broken?

Most broken promises were broken at the moment they were made. The commonest failure is the wrong person: a partner who says they'll pass the message on, an adult child who promises on a parent's behalf, a colleague who wants the call to end. Collections teams call reaching the actual borrower a right party contact, and the right party contact rate is the share of attempts that do. Improving that rate is the first job, because a promise from anyone else has nobody behind it. It also matters legally, since in most markets the debt may only be discussed with the person who owes it.

The next three failures sit inside the promise itself. It was too big, because the collector anchored on the balance and the customer agreed to end an uncomfortable call. It was on the wrong date, the end of the month when their salary lands on the 2nd. Or it had no route to payment: the customer meant it, then needed to find an account number, log in somewhere, or call back during office hours, and the moment passed.

The last failure comes after the miss. Someone who has broken a promise often goes silent out of embarrassment, and a collector who answers that silence with a sharper tone confirms the fear that kept them quiet.

How do you size a promise someone can keep?

Ask about the month before you ask for money. When does income arrive, what is already committed, what could they put towards this without missing rent? Then propose an amount below what they said they could stretch to. A customer who keeps a modest promise is still in conversation with you next month; one who stretches and fails usually is not.

Let them choose the date, too. A date the customer named is a date they have checked against their own calendar, and it lands after payday instead of before it. Your job is to keep it close: within days rather than weeks, so the promise stays live in their head.

Here is an illustration with invented but plausible numbers. Take 100 customers who each owe 1,200 euros. In the first approach, each is pushed to promise the full 1,200 by the end of the month, and suppose 35 of them pay: 42,000 euros collected, and 65 customers who now feel they have failed. In the second, each agrees four payments of 300 euros, the first taken during the conversation. Suppose 85 make the second payment, 78 the third and 72 the fourth. That is 335 payments of 300 euros, or 100,500 euros over the same quarter, an 84 percent kept rate across the 400 instalments, and most customers still answering your messages.

Change the assumptions and the gap narrows or widens, but its direction rarely flips, because the plan banks money on day one and every later payment is a smaller ask.

Why take payment during the call?

Because a payment made now cannot be broken later. When a customer says they could pay something today, the best answer is to let them, before the call ends: a secure link sent by text or message while you stay on the line, or a card payment taken through a proper payment process. Taking payment during the call turns the first instalment from a promise into a receipt, and it tells you the plan is real.

Do it properly. The card industry's security standard, PCI DSS, restricts keeping the card security code once a payment is authorised, and call recordings are where that rule quietly gets broken, so most teams either keep card details out of the recording or send a payment link and let the customer type the details themselves.

For everything after the first payment, give the customer a self-service portal, or at least a payment page tied to their account: the amount due, the next date, a pay button, and a way to move the date without phoning anyone. Rescheduling has to be as easy as paying. If the only way to say "Friday won't work, can we do Tuesday?" is a call to a queue, the customer will often say nothing, and a promise that could have moved by four days gets broken instead.

What should happen the day before and the day after?

The day before the due date, send one short reminder: the amount, the date, the link, and a line saying they can change the date if they need to. Something like "Hi Ana, a reminder that your 300 euro payment is due tomorrow. Pay here, or pick a new date here." Plenty of missed promises are forgotten rather than abandoned, and this is the cheapest fix in the whole process.

The day after a miss, get in touch once, early, and ask what changed rather than why they failed. Then offer a new date or a smaller amount. A first missed promise usually means the plan was wrong, not the person, so resize and carry on. Escalate on a pattern: two or three broken promises with no contact in between is a different account, and it belongs on a firmer track.

This is where promise to pay automation earns its keep. The reminder the day before, the check the day after and the reschedule link are simple steps that people forget to do for every account, and software doesn't forget. When AI runs friendly collections, this is most of what it does: the same patient follow-up applied to the thousandth account as carefully as to the first.