Payment reminders
A polite factual reminder — this invoice, this amount, this date, here is how to pay — automates well, because every element of it comes from a record rather than a judgement. Everything past that point is regulated work in most places: arrangements, interest, escalation, anything that could be read as pressure. Those belong to a person, and Connect refuses the terms that constitute them.
Draw the line before configuring anything#
| Automates safely | Stays with a person |
|---|---|
| An invoice reference, amount and due date read from your own records | Any payment plan, settlement or write-off |
| A restatement of your published payment terms | Interest, fees or charges not already documented |
| A link to how the customer normally pays you | Anything mentioning legal action or a third party |
| A question asking whether there is a problem with the invoice | The answer, when the problem is financial difficulty |
| Recording the reply and the commitment | Deciding what to do about a broken commitment |
Where the numbers come from#
This is the part that decides whether the reminder is safe at all. Connect answers from records: the Data grid's sheets, an uploaded ledger, Knowledge. An amount that no source carries is not stated — safe_sales refuses commercial terms Knowledge does not support and escalates instead of estimating. There is no accounting integration in the capability registry, so whatever your invoicing system knows reaches the workspace as data you put there or it does not reach it at all.
Frequency, and the rules that outrank your schedule#
- Do-not-contact
- Checked in one place before any outreach, along with suppression, unsubscribe and complaints. An entry outranks your reminder schedule entirely. Clearing one is a person's decision, recorded against them, and the Assistant cannot clear one at all.
- A block directive
- A
connect_memoryrow taggedblock:<channel>holds across channels and across future conversations. It is the right instrument for 'this person has asked to be contacted only in writing'. - Duplicate protection
- A follow-up with the same due time for the same person is a duplicate. Two people setting up the same chase does not produce two messages.
- The autonomy mode
ask_before_sendon the payments endpoint means a person sees every reminder before it leaves. On a debt-adjacent channel that is usually the right setting even when it is slower.- The 24-hour expiry
- A phone follow-up more than 24 hours late is closed as missed and never rung, so a chase does not resurface as an unexpected call days later.
What Connect does not have is any concept of what a reasonable contact frequency is in your jurisdiction. It follows the schedule you set. Setting one that would be defensible if it were read back to you is your part of this.
The evidence a dispute will need#
- Send evidence. A message is reported as sent only when the provider acknowledges it. The third state — uncertain — is shown as uncertain rather than guessed, because a reminder re-sent on a maybe is exactly the thing a complaint is built from.
- The decision log, holding what was decided, under which rule, and what happened — refusals included, because a refusal is a decision.
- Transcripts and summaries for any call. There is no audio: recording is foundation and is not enabled on the live carrier.
- The timeline, which puts the reminders and the customer's replies in one order across every channel they used.
When somebody says they cannot pay#
That sentence should end the automated part of the conversation. Connect cannot agree an arrangement — safe_sales refuses terms Knowledge does not support — and it should not try to reassure somebody in difficulty. The correct configuration is a scope that routes such a contact to a person, and the correct mechanism is a task follow-up with the thread attached, which no drain will ever send.
Where the money goes#
Very little, in writing. A reminder is a short model call against a record that is already loaded, and the plan's daily allowance is the ceiling. The obvious cheap channel is unavailable: outbound SMS is provider-dependent and the carrier on the live account carries none, with DLT entity, header and template registration required in India regardless. Phone reminders are the expensive option and the one most likely to be complained about; they are not the place to spend either budget.
Questions#
Can Connect agree a payment plan with a customer?
No. A plan is a commercial term, and terms that Knowledge does not support are refused and escalated to a person. If your published policy includes a standard arrangement, that is a documented fact and can be offered as written; anything negotiated is a decision with a person's name on it.
Where does it get the invoice amount from?
From your own records — a data sheet, an uploaded ledger, Knowledge. There is no accounting integration in the capability registry, so nothing arrives automatically from your finance system. A figure with no source is not stated, which is the safeguard that matters most on this kind of message.
Can it send payment reminders by SMS?
Not on the live carrier, which carries no SMS. With a provider that carries it, and in India with DLT entity, header and template registration completed with the telecom operators, the channel works. Inbound SMS, STOP and suppression already function regardless.