The question “how do I write a newsletter with AI from our own data” has a rather dull answer: first somebody has to look at what actually sold last month, what customers kept asking about, and what is running low. Nobody does that, because it means an hour of clicking through three systems. Give Claude access to those systems and the same brief takes a minute, so the writing starts from facts.
The work nobody wants
In a small company the newsletter usually gets written on Friday afternoon, because it is due. A blank document opens, the ceiling gets stared at, and in goes whatever happens to be in the writer's head: a piece of news sales mentioned that morning, or a product they suddenly remembered. Then nobody is surprised that it landed flat.
The data was there the whole time. The shop admin knows what sold most over thirty days and what showed up in baskets for the first time. Accounting knows where stock is falling and what got reordered twice. The support inbox holds questions repeated often enough to deserve their own paragraph. Nobody joins those up, because each number sits on a different screen and retyping them into a spreadsheet is nobody’s idea of a good afternoon.
In the end we sent whatever we had to hand.
— Friday afternoon, abridged
What “from your own data” actually means
On its own, Claude knows nothing about your company. It can write, it can compare one period to another, it can pick the two numbers worth mentioning out of a pile. One thing is missing: access to what really happened at your place. That access can be built, and it is less work than people expect.
It is built as an MCP server: a small, single-purpose bridge between Claude and one system. One for the shop, one for accounting, one for the support inbox. The bridge carries your identity, meaning the login of a specific person and their permissions. Nothing is copied anywhere, no database is uploaded into someone else’s service. Claude looks at what it needs for the answer, and answers.
Concretely: the shop, Pohoda and the support inbox
Say a small coffee e-shop, two people in marketing, a newsletter every fortnight. The systems stay exactly as they are: orders in Shoptet, invoices and stock in Pohoda, questions in email and in the website chat, sending in Ecomail. Nothing gets migrated. What gets added is a bridge and one skill describing what the brief should contain.
- Pull the items with the biggest sales increase over the last four weeks and compare them with the period before.
- Flag anything whose stock will last less than two weeks, so the newsletter does not push it.
- Group support questions into themes and show which ones came up most often.
- Remind you what is close to end of season or expiry, while there is still time to mention it.
- Write a first version: subject line, three paragraphs, one product link, and a note on where each claim came from.
It can look the same for one freelancer running newsletters for two clients. Instead of chewing through exports for two hours every month, they open the skill, pick the client and the period, and start at the text rather than at the spreadsheets. The saving is not in the writing. Writing is the fast part. The saving is in the preparation.
The skill you write once
The most valuable part of this is not the copy. It is the description of how your newsletter gets made: which periods you compare, how many products get mentioned, what never goes in the first paragraph, how you speak to long-standing customers. In small companies that is usually written down nowhere. One person carries it in their head, and when they take a week off the newsletter reads differently.
A skill is that recipe written down in one place, with versions. When it turns out that shorter subject lines work better, you change it in one skill and from then on it applies to everyone who uses it, each with their own permissions. Bit by bit the company builds a library: the newsletter brief, the ad review, the weekly sales summary. Working methods that used to leave with people.
What AI will not write for you, and why that is good
Claude cannot tell that a product which looks excellent in the numbers is one you quietly stopped promoting because complaints piled up. It cannot tell that a large client prefers not to be named. And it does not decide what tone is right for your list, which is a matter of taste, not of data.
So the bridge stops at a draft. Claude gathers the facts, writes the first version, and shows where every figure came from. The decision and the Send button stay with a person. That limit is exactly why the pattern can be trusted: nothing reaches your customers without somebody having read it.
The measure of success does not belong to the model either. An email open is no longer a reliable number: Apple describes a Mail Privacy Protection feature in its Mail app that loads message content privately and hides the reader’s IP address, so a share of recorded opens never involved a human at all. That is why the brief looks at orders after send instead. And who may receive the newsletter in the first place is settled by your consent records and, in Czechia, by Act No. 480/2004, not by Claude.
What it would take
No year-long project. A first bridge to one system is usually a matter of days, not months. It runs on your infrastructure, on your cloud, under your logins, so no copy of your database travels anywhere. We normally start with one source, most often the shop or accounting, and one skill for the brief. Once the first newsletter gets written from facts with nobody exporting anything, you add the next source.
What is left
The model is not the bottleneck. Claude already writes a better newsletter than you need. The bottleneck is the distance between it and the numbers your company already has. That is the distance we close.
If you send a newsletter and start from a blank page every time, write to us. A short call is enough to work out where your data sits and what a first bridge would cover. After that you can look at a brief for your own last month and decide for yourself.