Customer newsletters 2026: how the letter actually gets sent — and how the list holds up

The list is the asset — and it usually sits with someone else

The only thing in your marketing you genuinely own is the addresses of people who said yes to hearing from you. Social media you borrow, ad space you rent, but the list is yours — provided you can show where each row came from. That is where most businesses fall down. The addresses live in a sending tool an employee set up four years ago, and when you export them you get names and email addresses but not the part that makes the list usable: when the person signed up and where they did it. Without those two fields you do not have a list, you have a liability.

So move the list home with the proof of consent intact, row by row, before you build anything else. In practice that means three columns beyond the address: date, source and status. The source is the sentence you will later put in the footer of every letter — "you are receiving this because you signed up in the shop on 12 March" — and that sentence is both a practical legal requirement and the single best way to avoid spam complaints. A recipient reminded why she is on the list unsubscribes; one who is not clicks the spam button, and that button costs you deliverability for everyone else.

One detail that is expensive to discover late: first names may only come from a field someone actually filled in. The temptation to derive one from the address is strong when half the list has no name, but the result is letters beginning "Hi Info!" and "Hi Contact!" — and those are precisely the letters that make a customer wonder what else you are guessing at. If the name is missing, "Hi!" is the right answer. The same principle applies to deciding where customer data should live at all, which is the subject of the guide on GDPR and AI.

Are you allowed to email your customers? Usually yes — but the exception is narrower than you think

The main rule in section 19 of the Swedish Marketing Act is that advertising by email to a consumer requires consent. The exception for existing customer relationships exists, but it carries four conditions that must all hold at once: the address must have been given in connection with a purchase, the marketing must concern your own similar goods or services, the customer must have been given an easy opportunity to decline when the address was collected, and the same opportunity must be present in every message. If one fails, the exception fails.

"Your own similar goods" is the condition most often missed. If someone bought smoked salmon from you, a letter about the weekend fish counter is similar; a letter announcing that you now rent out the function room is not obviously so. And "in connection with a purchase" means exactly that — the bowl of business cards on the counter, the trade-fair list and the addresses you found on customers' websites all fall outside it. The practical conclusion is simple: build for consent anyway. A checkbox at the till and a signup form on the site cost an afternoon, and after that you never again have to reason about which category an individual row falls into.

Two more mechanisms belong here, and both are build questions rather than legal ones. Double confirmation — a signup does not count until the person clicks a link in a confirmation email — costs you roughly a fifth of your signups and gives you in return a list where every row can be evidenced. And the suppression list has to survive the person being deleted from the database. If you only store a flag on the customer row, whoever unsubscribed will reappear the next time someone imports an old export file. Store the unsubscribe separately instead, and let it override everything else at send time.

The blank page is why the letter never gets sent

Ask a business owner why the newsletter died and the answer is almost never "it did not work". It is "I did not have time". What actually happened is that a Monday morning with ten free minutes met an empty text field, and ten minutes is not enough to think of what to write, phrase it, find the images and check the prices. It is, however, plenty to read through something already there and change three sentences.

So AI belongs at exactly that point and nowhere else. In the build I am describing, the owner writes three lines in their own words — the promotion, the weekend menu, what came into the counter — and ticks which site content the letter should carry. The model then fetches the rest itself from the same database the site reads: this week's products, the lunch menu, events in the next fortnight, the news items. Roughly half a minute later there is a draft with a subject line, an alternative subject line and body text in the business's own voice. Above the draft sits a plain-language list of exactly what the model worked from, so whoever reads it can see the difference between what was fetched and what was written.

This is also why this particular use case pays for itself while many others do not. The model gets a bounded brief, a clear task and a human who reads before anything leaves the building. Compare that with cases where a model is meant to act freely against the outside world — the reasoning on which AI tasks actually carry their cost is in the guide on AI agents and use cases.

The model writes prose — the site writes numbers

This rule is the only one in the whole build I would call non-negotiable. A language model writing marketing copy invents prices, because a price is exactly the kind of detail that makes text feel credible — and it does not know that the difference between 349 and 399 kronor per kilo is the difference between a happy customer and an argument at the till. The fix is not a better prompt. It is a mechanical gate: prices are pulled from the database into the brief as a permitted list, and before the draft is shown, every kronor figure in the text is compared against that list. An amount not present in the brief stops the draft.

The same kind of gate is needed for claims that must never be made. In a food business that is allergens: the words "free from" may not leave the building in a marketing email, however confident the model sounds, because the claim requires kitchen routines a mailshot cannot guarantee. In a clinic the equivalent is medical promises; for a tradesperson, guarantee periods. Put the gate in the code, not in the prompt — prompts are usually followed and code always is.

One more thing that is easy to miss in an integration: subscribers' names and addresses never need to be sent to the model. One call is made per draft, not per recipient, and the greeting, footer and unsubscribe link are added by the template afterwards. That is cheaper, faster, and removes the entire question of what the provider does with your customer data.

Saved, tested, sent — in that order

The draft is not the problem. The send is. A letter to six hundred people cannot be undone, and there is no version of "I slipped" that the recipient can tell apart from intent. So the send-to-all button should be locked until two things are true: the text is saved, and a test email has gone to you on exactly that saved text. Change one letter afterwards and the test lapses and you send a new one.

That sounds fussy until you have seen what the test email catches. It is almost never a typo — it is a broken link, an image that does not load in Outlook, a heading that wraps to three lines on a phone, or a subject line that looks like spam in the inbox list and perfect in the editor. And the checks belong on the server, not only in the interface: greyed-out buttons are a courtesy to the user, while the check that actually holds is the one that runs the moment the send is requested.

Six hundred emails at once is spam-filter training

The most common technical disappointment is that the first real send from a new sending domain lands largely in spam. It is not the content. Recipients' systems have never seen your domain send anything, and six hundred emails in a minute is exactly the pattern they are built to stop. The fix is to warm up: split the first send across several days with a daily cap — I use two hundred and fifty — so the remainder goes out on the following mornings. After two or three sends it is no longer needed.

Two infrastructure decisions belong with this. Send marketing from its own subdomain, separate from the address you invoice and answer customers from, so that a spam complaint about the newsletter does not poison your ordinary mail. And verify the domain properly with your provider before the first send — it is the same kind of invisible groundwork that decides whether a site is visible at all, rather like page speed: nobody thanks you when it is done, everybody notices when it is not.

What you actually get — and what you do not

Be honest about the order of magnitude. A newsletter to a few hundred local customers is not a growth engine, it is a reminder that you exist, and its value lies in repetition. It does three things well: it fills a quiet week when you tell people what is in the counter, it gives regulars a reason to come back before they have forgotten you, and it makes it cheap to test whether an offer bites before you pay to advertise it. It does not make you a well-known sender, it does not replace being visible when someone searches, and it does not rescue a business without repeat customers.

Cadence matters less than most people think, as long as it is predictable. Weekly works if something genuinely changes weekly — a fish counter, a lunch menu, an events programme. If it does not, fortnightly or monthly is better, because a letter sent because the calendar said so shows it immediately in the content. And the closest thing to a guaranteed loss I can point to is sending the same offer over and over to a list that has stopped opening.

Finally: the newsletter is one of several routes back to the same customer, and the weakest of them on its own. It works best alongside the customer booking their next visit while still standing there — the subject of the guide on rebooking and regulars — and alongside the satisfied ones actually being visible in public, which is what the guide on getting more Google reviews is about. Three weak signals pointing the same way beat one strong signal alone.

The order to build in

1. The list comes home first. Export it, and make sure date and source travel with every row. Where they are missing for part of the list, treat that part as uncertain and ask for a fresh yes in the first send.
2. The signup routes. A form on the site with double confirmation, and a checkbox at the till or in the booking flow. Two ways in is enough; more just becomes more to maintain.
3. Unsubscribe and suppression. A link in every letter, and a suppression record kept separately from the customer row so it survives both deletion and the next import.
4. The sending domain. Its own subdomain for marketing, verified with the provider, separate from your ordinary email.
5. Send it by hand for a few weeks. Before you build the AI half. Then you know what the letter should actually contain, and you find out whether you have something to say every week.
6. Only then the draft. The AI reads your own content, you read the AI. Price gate and test email from day one, not as a later improvement.