DEV Community: Fairdraft Studio

A late-invoice follow-up sequence that keeps the client

Fairdraft Studio — Fri, 25 Sep 2026 11:58:39 +0000

A late payment is often not a refusal

Before assuming the worst: invoices sit unpaid because they went to the wrong address, because a purchase order number is missing, because the person who approves them is on holiday, or because the finance team pays everything on the 30th regardless of what your invoice says.

Often the client has not decided not to pay. They simply have not done it yet. A sequence works because it escalates on a schedule, so you never have to decide in the moment how annoyed to sound.

Write the sequence once and follow it for every client. That is the whole method.

Step 1: friendly reminder, 1 to 3 days after the due date

Assume it slipped. Attach the invoice again, since making someone search their inbox is how another week passes.

Subject: Invoice 2026-014 for €1,200: quick reminder

Hi Marc,

Just a reminder that invoice 2026-014 for €1,200, due on 28 August, is still showing as unpaid on my side. I have attached it again in case it got lost.

You can pay by bank transfer or the payment link on the invoice. If it is already on its way, please ignore this.

Thanks!

Léa

No apology, no "sorry to bother you". You are not bothering anyone. You are providing information.

Step 2: firm follow-up, 7 to 10 days later

The tone changes here: still warm, but now you ask for something specific.

Subject: Overdue: invoice 2026-014 (€1,200, due 28 August)

Hi Marc,

I am following up on invoice 2026-014 for €1,200, which was due on 28 August and is now 13 days overdue. I have not had a reply to my reminder of 31 August.

Could you let me know the date the payment will be made, by Monday? If something is holding it up, such as a missing PO number or the wrong billing details, tell me and I will sort it out straight away.

The invoice is attached. You can pay by bank transfer or the payment link on the invoice.

Léa

Two things do the work: a request for a specific date, and an offer to fix the blocker. "When can I expect payment?" is much harder to leave unanswered than "just checking in".

Step 3: a 60-second phone call, between steps 2 and 4

If you have a number, use it. A one-minute call can settle what two weeks of email did not.

"Hi Marc, it's Léa. Quick call about invoice 2026-014. Is now a good moment?"
"It was due on 28 August, for €1,200. Is anything blocking it on your side?"
Listen. If there is something you can fix right now, fix it while you are on the phone.
"What date can I expect the payment?" Wait for an actual date.
"Great, I will send a short email confirming that date." Then send it.

That last step matters. The email is polite, and it is also a written record.

Step 4: final notice, 7 to 10 days after step 2

Formal, short, and specific about what happens next.

Subject: Final notice: invoice 2026-014 (€1,200) overdue since 28 August

Hello Marc,

Invoice 2026-014 for €1,200, due on 28 August, remains unpaid after my reminders of 31 August and 10 September.

Please arrange payment by 24 September. If payment is not received by then, I will pause the remaining work on the project, as set out in our agreement.

I would much rather resolve this directly. If there is an issue, reply today or call me on [number].

The invoice is attached. You can pay by bank transfer or the payment link on the invoice.

Léa

Only threaten what your contract actually allows

This is the part to get right. Do not mention late fees, interest, pausing work, or "formal recovery" unless your agreement or your local law genuinely gives you that right. An empty threat that the client's accountant recognises as empty costs you the leverage you had.

Late-payment rules differ by country, and many places set statutory interest or compensation for business-to-business invoices. In the EU, for example, a business that pays another business late generally owes late-payment interest plus at least €40 towards recovery costs (Directive 2011/7/EU). Check what applies where you work, and put it in your terms before the next project rather than inventing it mid-chase.

Prevent the next one

Three lines in your scope of work make the next one less likely:

A deposit before work starts. Clients who have paid something behave differently from clients who have paid nothing.
Payment terms in writing, with the due window, the method, and what happens when payment is late.
Billing details collected at kick-off: legal entity name, invoicing email, PO number, VAT number. An invoice sent to one person instead of the accounts inbox can sit unseen while that person is away.

When to stop

If the final notice passes with no reply, the decision is commercial, not emotional: the amount, the evidence you have, and whether you would work with them again. In many countries a formal payment demand letter is a cheap next step, and small-claims procedures exist for exactly this. Get advice for your situation rather than acting on a forum post, including this one.

What you should not do is keep working. Unpaid work plus more unpaid work is not a strategy.

General information, not legal advice: check the late-payment rules that apply where you work.

This article was written with Claude, an AI assistant, and checked for accuracy before publishing. Not affiliated with or endorsed by Anthropic.

How I designed a Claude skill that turns call notes into action items

Fairdraft Studio — Mon, 14 Sep 2026 10:55:35 +0000

After a client call, the same admin always follows: reread the notes, work out what was actually decided, write down who owes what by when, and send a recap before memories drift.

That job is repetitive and has a clear right answer, which makes it a good fit for a Claude skill. So I made one. It is under 100 lines of Markdown, MIT licensed, and free. Below are the design decisions behind it, most of which apply to any skill.

What a skill actually is

A skill is a folder with a SKILL.md file in it. The file starts with YAML frontmatter holding a name and a description, followed by instructions in Markdown. There is no code, no dependencies and no API calls. Claude reads the instructions when the skill is relevant and follows them.

---
name: call-notes-to-actions
description: "Turns a meeting transcript, call recording notes, or rough meeting"
  notes into a crisp summary with decisions, an action-item table (owner, action,
  due date), open questions, risks, and a ready-to-send follow-up email. Use when
  someone asks to summarize a call or meeting, extract action items, write meeting
  minutes, or draft a follow-up email after a client call.
---

That is the whole interface.

The description field is the product

Claude reads the description to decide whether the skill applies to a request. A short, tidy one-liner like "Turns meeting notes into action items" is accurate, but it shares very few words with what people actually type.

So the description names three things: the inputs (transcript, call recording notes, rough notes), the outputs (summary, decisions, action-item table, follow-up email), and an explicit "Use when..." clause listing the requests: summarise a call, extract action items, write meeting minutes, draft a follow-up email.

A useful exercise: write down five ways you might ask for the skill, then check that each one shares vocabulary with the description. Instructions that never load do nothing.

Rules against inventing things

The obvious risk with meeting notes is minutes that look polished but include decisions nobody made. The skill has a few short rules for this, and I now reuse them in every skill:

Only extract what was said. No invented decisions, owners or dates.

Mark inference, don't hide it. If an owner or due date is implied but never stated, the skill fills it in and appends (proposed). You still get a usable draft, and you can see exactly which parts are guesses.

Give vagueness somewhere to go. Calls are full of "we should look into that". Those become action items with owner TBD instead of being dropped, so nothing quietly disappears.

Keep decisions and questions apart. The instructions define both: a decision is something agreed, and a question is something still open. Without that line, ambiguous points tend to end up in the decisions list, where they look settled.

Fixed output beats freeform

The skill specifies the exact output: a summary of at most three bullets, numbered decisions, an action table with owner | action | due | status, open questions, risks, the follow-up email, and a "To confirm" block to delete before sending.

A fixed shape has two benefits. The output is skimmable in the same way every time. And gaps become visible: an empty owner cell stands out, while the same gap inside a paragraph does not.

The email is built from the same table, under the headings "We agreed / I'll / Could you / Still open". Because the recap and the table come from one source, they shouldn't disagree, which is a common failure when you write the recap by hand.

Make the skill check its own work

The last section is a checklist the skill goes through silently before answering:

every action item starts with a verb and has an owner and a due date (real, proposed, or TBD)
nothing appears that the notes don't support, and inferences are marked
decisions and open questions are not mixed
relative dates are converted to real dates
the email matches the action table exactly
the summary has at most three bullets

Per line, this is probably the most useful part of the file. It isn't a guarantee, because it's still a model checking its own output, so you should still read the result before sending. But it turns vague quality goals into specific things to check.

Dates need their own rule

"Next Friday" is a trap. The skill converts relative dates using the meeting date, or today's date if the meeting date is unknown, and notes that assumption in the "To confirm" block. Any LLM workflow that handles dates needs an explicit rule about which day it counts from. Otherwise you get deadlines that sound confident and are wrong.

Try it

In Claude Code:

/plugin marketplace add FairdraftStudio/call-notes-to-actions-skill
/plugin install call-notes-to-actions@fairdraft-studio

In the Claude app: turn on code execution and file creation under Settings > Capabilities, then go to Customize > Skills > Upload skill and choose call-notes-to-actions.zip from the repo.

Then paste a transcript and say "summarise this call and draft the follow-up email". The repo has a worked example with an input and its output.

What I'd tell myself before starting

Spend more time on the description than on the instructions.
Write the output format before the rules. The shape of the answer constrains everything else.
Add the self-check list early, not as final polish.
Test on the messiest real notes you have, not on a clean example you wrote yourself.

Repo (MIT): https://github.com/FairdraftStudio/call-notes-to-actions-skill. This post and the skill were written with Claude, an AI assistant. Not affiliated with or endorsed by Anthropic.