Why Your Follow-Ups Die in Someone's Inbox

A practitioner's guide to automating quote follow-ups and overdue invoice reminders without creating a second, broken ledger inside your email tool.

Updated on: 2026-08-11

The thing that kills follow-ups is not laziness. It is that the person responsible has forty other things open, and chasing a quote from nine days ago or an invoice that went overdue on Tuesday sits below all of them. So the quote goes cold. The invoice ages another two weeks. Nobody decided that. It just happened, one busy afternoon at a time.

If you run a service business with 20 to 50 people, this is money you already earned or nearly earned, leaking out because a task that takes four minutes never gets prioritized. Automating it is one of the highest-return workflows we build, because the value is revenue you keep, not hours you save.

Here is the short version before the detail: automate the scheduling, the eligibility checks and the sending, but keep your accounting system as the source of truth for what is actually owed. The most common failure is not a broken email. It is an email that goes out after the customer already paid.

Quote follow-up and invoice chasing are two different jobs

People lump these together because both involve sending a reminder. They should not share a template, a tone, or a state machine.

A quote follow-up is a sales nudge. The prospect has an open offer and has not decided. The message is low-pressure: are there questions, is the timing right, is there anything to clarify. It stops the moment the quote is accepted, rejected, expired or converted into an invoice.

An overdue invoice reminder concerns a payment obligation that already exists. It carries the invoice number, the original due date, the current outstanding balance, a payment method and, eventually, an escalation path. It can have accounting and legal consequences a "just checking in" email cannot.

If you send the same friendly note for both, you either sound pushy about an unpaid invoice or oddly formal about a sales quote. Worse, you lose the branching logic that keeps the automation safe.

The workflow has to make decisions on at least five inputs:

• Record type: quote or invoice
• Lifecycle status: draft, sent, accepted, rejected, expired, invoiced, open, partially paid, paid
• Elapsed time: days since the quote went out, or days since the invoice fell due
• Customer context: consumer, sole trader, company, strategic account, disputed account
• Human exception: a dispute, a promised payment date, a wrong email address, an account owner hold

Let your accounting system own the truth

Whether you run Jortt, Fortnox, e-Boekhouden.nl or Exact Online, that system already knows what a quote is worth, when an invoice is due, and whether a payment has been matched. Do not rebuild that knowledge inside an email tool. The moment your automation starts deciding independently who owes what, you have two ledgers that disagree, and the email one is always wrong at the worst moment.

The clean split we use:

The accounting system owns invoice number and amount, due date, payment and partial-payment status, credit notes, quote and invoice lifecycle status, and the official reminder history where it exists.

The automation layer owns scheduled checks, waiting periods, personalised email copy, sales-owner notifications, suppression rules, escalation to a human, audit logging, and coordination when more than one system is involved.

A useful example of why this matters: Jortt distinguishes open, overdue and paid based on whether a payment has been linked to the invoice, not simply whether the invoice was created. If your automation assumes "invoice exists therefore unpaid," it will chase people who paid last week.

What you need in place before you build anything

Skipping the prerequisites is how automations end up sending reminders to the wrong contact for a credited invoice. Confirm these first.

A defined source of truth for each field. The accounting system owns invoice and quote state. The customer record owns the billing email, account owner and preferred language. The workflow layer owns scheduling and send history. The email service owns delivery, bounce and complaint events.

Stable identifiers. Every workflow record needs the accounting system name, a tenant or administration or division ID, the quote or invoice ID, the customer ID, the workflow type, the current state, the last observed source update, the last follow-up sent, the next eligible date, and any hold reason.

API access at the right subscription level. This trips people up. Jortt's API is only available from the MKB or Plus plans, not Starter or ZZP, so check the customer's subscription before designing an API-led example. Fortnox applies a documented limit of 300 requests per minute per client and tenant, so your polling has to respect that.

An authenticated sending domain. Use a business domain with correct SPF or DKIM. For one-to-one invoice and quote correspondence you care less about bulk-marketing rules and more about a correct From and Reply-To address, bounce handling, a monitored reply mailbox, and no misleading subject lines. Quote nurturing that drifts toward marketing may fall under different consent rules than a transactional payment reminder, so keep the two streams separate.

A written timing policy. Decide the cadence before you touch the tool. Something like:

Quotes — send at day 0, ask if there are questions at day 3, share a useful next step at day 8, one final low-pressure check at day 14, stop the instant it is accepted, rejected, expired or invoiced.

Overdue invoices — optional courtesy note on the due date, a polite reminder at day 1 to 3, a firmer one with a payment link and the outstanding balance at day 7, internal owner notification or a final reminder at day 14 or 21.

These are examples, not legal deadlines. Fortnox's own service has a seven-day reminder timing with Swedish fee and interest rules baked in. Do not copy those numbers into a Dutch Jortt or Exact setup.

The build, step by step

Map how work actually moves today

Before any code, document the real path from quote creation to payment matching to escalation, and note where each decision currently lives: the accounting software, someone's inbox, a spreadsheet, or memory. Reminder automations fail at handoffs far more than at email delivery, which is exactly why mapping the real process matters more than the email template.

Use explicit states, not a single flag

A boolean like follow_up_sent cannot tell you whether a quote was accepted before the scheduled email ran. Use named states with entry and exit conditions:

overdue → paid            when the accounting source reports a matched payment
reminder_1_sent → paid    when the balance reaches zero
overdue → disputed        when a reply or internal tag records a dispute
follow_up_eligible → accepted   when the quote is accepted before the email fires

Pick the strongest available trigger

In order of preference: a webhook or event notification where the system supports one reliably, then scheduled API polling with a last-updated cursor, then a scheduled export and import if there is no usable API, then the accounting system's native reminders when they already do what you want. Do not assume every object in every system emits a webhook. Fortnox documents invoice services and rate limits, but other objects may need polling.

Normalise every source into one record shape

Map Jortt, Fortnox, e-Boekhouden.nl and Exact into a common structure so the rest of the workflow does not care which system a record came from:

{
  "source": "jortt",
  "record_type": "invoice",
  "record_id": "INV-1042",
  "status": "overdue",
  "amount_outstanding": 1250.00,
  "currency": "EUR",
  "due_date": "2026-08-01",
  "next_action_at": "2026-08-15T08:00:00Z",
  "hold": false
}

Check eligibility immediately before sending, not just when queuing

This is the check that prevents the most embarrassing failure. Right before dispatch, verify the quote is still open or the invoice is still unpaid, the stage has not already been sent, the customer has not disputed or promised payment, the invoice has not been credited, the recipient address is valid, the customer is not suppressed or on hold, and the attempt count is under the limit. Run this final check at send time, because a payment can land in the gap between scheduling and sending.

Build separate templates and always show the current balance

You need distinct copy for quote follow-up one and two, invoice due reminder, overdue reminder one and two, a payment acknowledgement, and a human escalation note. For invoice reminders, show the current outstanding amount, not the original total. If a customer paid half, chasing the full figure destroys trust. Jortt's native reminders describe including the remaining balance and a payment link for exactly that balance.

Keep late fees, deadlines and collection language out of generic templates unless the business has approved the wording and the accounting system supports the jurisdiction.

Make every send idempotent

Create a send record keyed on source, tenant, record ID, workflow stage and scheduled date before or atomically with the send. If the same trigger fires twice, the second run finds the record and exits. This matters most for webhook and polling designs, where duplicate events are normal, not rare.

Native reminders or an external layer?

You rarely want one or the other. A hybrid is usually safest: the accounting system sends the official invoice and the formal reminder, and a separate, clearly labelled courtesy follow-up runs in the automation layer, checking the accounting status before every send.

e-Boekhouden.nl already covers much of the overdue process with multiple reminder moments and editable templates, so there the automation earns its keep on scheduling, customer-specific routing, quote follow-up and exception handling. Exact supports online quote acceptance and converting a signed quote straight into an invoice, which makes that conversion your cleanest event boundary. In both cases, verify during implementation which reminder and payment-state fields the specific edition and region actually expose. Do not assume the invoice object carries the full reminder history.

Where these workflows quietly break

That last one is worth dwelling on. A reminder workflow that sends nothing looks identical to a healthy one on a dashboard. If you normally expect a handful of eligible invoices each morning and suddenly there are zero, someone should be told. The same discipline shows up when an invoice can be perfect and still be wrong: the system reports success while the outcome is quietly broken.

Where a human still has to step in

Automation should stop and notify a person when the customer disputes the invoice, the amount is high value, the account is strategically important, a payment promise is missed, a quote reply contains a question, the email bounces, or the reminder count maxes out. The notification needs a direct link to the record, the last message sent, the customer's latest reply and a recommended next action. Anything less and your team has to reconstruct context before they can act, which is the friction you were trying to remove.

What I would do first

Do not try to automate all four systems and every edge case at once. Pick one administration, one quote sequence and one overdue sequence. Run it against real records including the awkward ones: the partially paid invoice, the quote accepted an hour before the follow-up was due, the credited invoice, the missing email address. Watch it for two weeks with hypercare in place before you widen it.

That controlled pilot is where you catch the reminder that would have gone out after payment, or the quote nudge that would have landed after the deal was signed. Those are the misfires that erode customer trust, and they are cheap to catch in a pilot and expensive to explain in production.

This is the shape of work we build at FasterAdmin: operations systems on n8n, inside the tools you already run, so the chasing gets done reliably and you can see what happened. Every build starts with a paid, fixed-scope diagnostic that quantifies the hours you are losing before anyone writes a workflow, and states plainly where a native reminder already does the job and no automation is needed.

FAQ

Should I automate quote follow-ups or just overdue invoices first? Start with overdue invoices if cash flow is the pain, because the money is already earned. Start with quotes if your win rate drops on deals that go quiet. Most businesses feel the invoice side more sharply, so that is usually the higher-return first build.

Will customers notice these are automated? For invoice reminders, they should. A clear, factual reminder with the invoice number and balance reads as normal business, not spam. For quote follow-ups, keep the copy specific to their situation and route real replies to a person, and it holds up fine.

Can I just use my accounting system's built-in reminders? Sometimes, yes, and if the native cadence matches your policy you should. e-Boekhouden.nl and Fortnox both cover a lot natively. The automation layer earns its place when you need timed quote sequences, per-customer branching, sales-owner alerts, or one workflow across several systems.

What is the biggest risk? Sending a reminder after the customer has paid, disputed or been credited. Every safe build re-checks the accounting status immediately before sending, not just when the record enters the queue.

Further reading

• Jortt invoice reminder documentation
• Jortt API and subscription requirements
• Fortnox reminder flow and API limits