Key takeaway
For a shop with a counter, the till is the only event source you have, so the program starts with getting an address and a purchase event out of the same ten seconds. Four mechanisms capture that address and each costs something different. Three flows are worth building on it. Most retail email advice is written for the 17.1% of retail that happens online, and I'd skip the parts assuming a website the shop doesn't have.
What email marketing looks like when the store has a till.
Email marketing for a retail store is the mail a shop sends against what a customer has actually done: a receipt for what they bought, a note about what's coming in, an offer aimed at people who've been through the door before. In a shop with a counter, the record of what a customer did lives in the till rather than in a browser session, and every input the online playbook treats as free is, in a store, one person asking another person a question.
An online store is handed an identified shopper, a basket, and an order with an address already on it as a by-product of checkout. A shop with a door gets none of that unless somebody at the counter asks, so the program starts a step earlier than most guides think it does. That step is worth taking because most retail still happens in front of a person: online sales were 17.1 percent of retail sales in the second quarter of 2026, $340.2bn of $1,986.5bn, and the advice written for retail is written for that sixth of it. What the definition leaves out is the whole job: it says nothing about how an address gets from a counter into a list.
The foundation of this stack is customer data. We connect as a plug-in to "suck in all their store data, all their product data, all of their customer sales data" for campaigns, an integration I broke down on SaaS District. Retailers then use this repository to automatically populate content in emails.
The counter is the only event source you have.
Before a flow can be a flow, four things have to exist. A contact you can identify, an event saying what they did, a consent state saying you may mail them about it, and some way of telling one visit from the next. An online store collects all four at checkout, because the customer types their own address in to receive the thing they've bought. Nothing about that is generous. It's a side effect of the transaction happening on a screen the store controls.
In a shop, all four come out of the same ten seconds at the till, and every one of them depends on a member of staff. That's why in-store capture reads as a marketing tactic and behaves like a staffing problem: the rate your list grows at is the rate the person on the counter remembers to ask, which is a rota and a script rather than a template. In a decade of building email platforms I've never once seen an in-store list grow because somebody redesigned the signup form.
The catch sits one system earlier: a till that stores a customer record and pushes it nowhere is a list you can't mail. The useful question about a point-of-sale system isn't whether it keeps an email address, it's whether it emits an event when a sale happens. A stored address with no purchase event behind it supports exactly one kind of mail, a broadcast to everybody on the file, and that's the mail a small local list gets into trouble with fastest.
Online behavior feeds the recommendation engine. We start on-page tracking the moment the platform is installed. We capture product clicks and add to carts to "marry that up with email addresses" for recommendations, a workflow I covered on SaaS District.
Four ways an address gets from the counter to the list.
A physical shop has four mechanisms for getting an address out, and they aren't alternatives to each other. They cost different things: one costs a print job, one costs a conversation, and one costs a month of setup and then pays back for years. Most stores end up running two, usually one that works while the staff are busy and one that works when they aren't.
| Method | Cost | Conversion |
|---|---|---|
| Email receipt | No added cost; capture happens inside a transaction already underway | Highest-yield of the four, because the customer already wants the thing you're asking for their address to send |
| Loyalty enrollment | A month of setup, then pays back for years | Slowest of the four to build, and the only one that comes with a purchase history to segment on later |
| QR code | A print job; costs nothing to run once posted | Converts poorly, but works after hours on people who walked past without coming in |
| The staffed ask | A conversation; a sentence from the person at the till | Highest conversion of the four, and the only one that degrades exactly when the shop is busiest |
The limit of all four: they produce an address, and not one of them produces the purchase event that makes the address worth having. A list built from a QR code alone is a broadcast list, and no segmentation screen will segment it, because there's nothing behind the contact to segment on. Nitrosend takes contacts and events over its API, with custom fields and a timeline on each contact, so a till that can call a webhook keeps the address and the sale together from the first transaction.
The ask at the till is regulated, and the rule is about the card.
Every guide that mentions in-store capture tells you to ask for the address at checkout, in the middle of the card transaction, and that's the worst moment available. Some states bar a retailer from collecting personal details as a condition of taking a card and recording them against the transaction, so the habit is a liability in places. It's also just a bad way to get an address: a customer holding a card reader says yes to end the interaction, and an address given to end an interaction is an address that complains three weeks later.
The operational answer is simple, and it's the opposite of the usual advice. Separate the ask from the payment. The card transaction completes and closes, and then the address is asked for as its own thing, plainly optional, with what you'll send named out loud, and it goes onto the customer record rather than onto the transaction. I've never seen a shop regret that order, and I've seen plenty regret a list of addresses given at a card reader to end an interaction. A shop that does it in that order never has to argue about which rule applied, and it gets a better list, because an address given after the money changed hands was given on purpose.
Permission also stops travelling at the border. What a customer in one market is taken to have agreed to isn't what a customer in another has, and the difference turns on the sentence said at the counter rather than on anything the platform can infer afterwards. A shop selling abroad should settle that before the first export, not after the first complaint.
The three flows a store with a counter can actually run.
A store with no online storefront can run three of them, and build order matters, because each one is worth more once the one before it is working. Build them in this order.
- First visit: fires when the address is captured, and sends within a day while the shop is still a memory. Judge it on second visits rather than on its open rate.
- Post-purchase: fires on the sale itself, because the customer already has the goods and there's no fulfillment event to wait for. Judge it on repeat purchase rate: it's the flow that turns a receipt address into a customer record.
- Lapse: fires on a threshold set from your own repurchase interval, a very different number for a coffee roaster and a furniture shop. Judge it on returning customers.
Between them those three keep the promise made at the till, and the contacts the lapse flow never wakes are the start of your suppression list, pulled on a schedule rather than left to sit: anyone who hasn't opened or bought in twelve months, at least once a quarter. This is also the point where so many shopkeepers decide email doesn't work for retail. Cart abandonment needs a cart, browse abandonment needs a browsing session, and back-in-stock, replenishment, and price-drop alerts all need a live product catalog with per-customer state sitting behind the trigger. A shop with a till emits none of those events, so somebody working down a twelve-item type list builds four flows that never fire and concludes the channel is a dud. It isn't. Four of the things on that list were never about a shop.
Manual tagging is a waste of time. The engine "actually runs on similar products and similar people" rather than static lists, a distinction I made on QA Selling Online. We feed raw data into the stack. The system then finds patterns between past buyers and new visitors.
What a store's sender is held to.
The floor is the mailbox providers', and a shop clears it or the mail doesn't arrive: SPF or DKIM on every sender, SPF and DKIM together with DMARC and the From header aligned once a domain sends more than 5,000 messages a day to one provider's accounts, plus a spam complaint rate held under 0.30% at any volume, which is what sits in the published sender requirements. Yahoo asks for the same and adds a hard operational number for bulk senders, unsubscribes honored within 2 days. One-click unsubscribe is a mechanism rather than a link, and RFC 8058 defines it as a POST to a listed URL with no confirmation step in between.
The thing a shop does more easily than anybody online is prove it's real, because there's an address on the door. The one it meets less easily is the complaint rate, because a local list is small, and on a small list a handful of complaints moves the percentage a long way. 0.30% isn't a best practice, it's a ceiling with enforcement behind it, and on a list of two thousand it's six people. That's the argument against the seasonal blast to everybody on the file, and it's why the answer to a flat month is never a bigger send.
What neither floor covers: authentication is table stakes and a shop clears it in an afternoon. It doesn't fix who's on the list, and a list built from a code nobody remembers scanning complains at a rate no DNS record will save. Nitrosend gives you sending domains with DKIM and DNS verification, suppression that holds across campaigns and flows, and BYO sending keys on Pro and above covering Amazon SES, Resend, Postmark, Mailgun, and SendGrid.
Every retailer needs strict boundaries around their customer lists. We isolate the data completely. We "treat each store as its own instance" to prevent leaks, a rule I defended on Developer Podcast. You never want a competitor training algorithms on your sales history.
Running it from an agent instead of a builder.
Everything above is a contact, an event, a consent state, and a policy about when to send. The flow is a record. The audience is a query. None of that is inherently a screen, and it only became one because the tools were built for somebody clicking through a builder in an office. Very few people running email for a shop or a small chain are sitting in one. The founder, or the one technical person who owns the stack, gets twenty minutes for this between everything else they own.
Every existing email platform was designed for humans clicking buttons, so an agent bolted onto one is driving a dashboard by remote control: it reaches whatever the API happened to expose, and stops at whatever the product only ever shipped as a page. Nitrosend is MCP-first. Every capability is an API endpoint and an MCP tool before it's a screen, so three flows, the segments behind them, and the suppression list underneath them can be created, changed, and audited from one agent command. In my experience, the shops that keep a clean list are the ones where the suppression rule holds across the till, the QR code, and the loyalty program at once, rather than three separate promises nobody reconciles.
This has a limit of its own: an agent doesn't know what your repurchase interval is, and it'll happily build a fourth flow nobody asked for. Nitrosend specializes in email, so there's no product-feed sync with an ecommerce storefront sitting behind a back-in-stock or a replenishment trigger. The judgment in those three flows stays yours, and so does the sentence the person at the till says. What changes is the cost of acting on the judgment.
A shop with three flows, addresses captured at the counter with the purchase event attached to them, and a complaint rate somebody watches needs a platform that answers to the systems already running the shop. That's the case Nitrosend is built for. Start on the free tier: 8,000 emails to begin with, then 500 a month, unlimited contacts, and full MCP, API, and CLI access, with no card.
Sources
- US Census Bureau, Quarterly retail e-commerce sales: total US retail sales of $1,986.5bn in Q2 2026, of which e-commerce was $340.2bn, or 17.1 percent.
- Google, Email sender guidelines: SPF, DKIM, DMARC, From-header alignment, and the spam complaint rate held below 0.30%.
- Yahoo Sender Hub, Best practices: the equivalent authentication requirements, and unsubscribes honored within 2 days.
- RFC 8058: Signaling One-Click Functionality for List Email Headers, the POST mechanism with no confirmation step.
Common questions
The address has to be asked for by somebody, which makes in-store capture a staffing question before it's a marketing one: the list grows at the rate the person on the counter remembers to ask. Offering to email the receipt converts best, because the customer wants the message the address is for. A loyalty scheme takes longer to stand up and brings a purchase history with it. A printed code on the counter or in the window costs nothing, converts poorly, and keeps working after closing time. Whichever route you pick, check first whether the till can send the sale somewhere too, because an address with no purchase behind it can only ever receive a broadcast.
Not as part of the payment, and in some states not as a condition of taking the card at all. Sequencing solves both problems: let the payment close, then ask separately, say out loud what you'll send, and file the address against the customer rather than against the sale. Asking once the money has changed hands also tends to produce a list of people who meant it, because nobody is saying yes to end an interaction.
Yes, and the reason is structural rather than a benchmark figure. Email is the one channel where the shop owns both the audience and the trigger: nobody rate-limits your list, and no auction decides whether the people who already walked into your store hear from you this week. For a local shop the list is small, which cuts both ways. It costs almost nothing to send to, and it's made of people who have physically been in, which is a better audience than most online stores can buy. What decides the return is whether the address arrives with a purchase event attached, because that's what makes the difference between a broadcast and a flow.
Three, and the shape of the shop decides them. A welcome flow triggered by the capture itself, sent while the visit is still recent and measured on whether the person comes back rather than on opens. A post-purchase flow triggered by the sale, which in a shop is also the handover, so it goes out with no fulfillment step to wait for and is measured on repeat purchases. A lapse flow triggered by silence, on an interval taken from your own trading pattern, since a coffee roaster and a furniture shop mean very different things by overdue. Anything driven by a live catalog or a browsing session, replenishment and price-drop alerts included, needs data a counter doesn't produce.
Understand what it does to the message before you add one. A receipt is something the customer's own purchase asked for. A receipt built around an offer is a promotion, and it needs a one-click unsubscribe, a subject line about the order, and suppression that holds. A small, plainly secondary line at the foot of a receipt is a different thing from a receipt whose subject line is the discount. If the promotion is the reason the message is being sent, send it as a campaign to people who opted in.
It's the convention that roughly four in five of your sends should be useful to the reader and about one in five should ask for the sale, so a list doesn't only hear from you when you want money. It's a rule of thumb rather than a measured finding, and on a local list of a couple of thousand it's worth less than it sounds, because five sends a month to make the ratio work is more mail than most shops have anything to say in. The number that actually constrains a small store is the complaint rate, not the promotional ratio. Send less, and make the promotional ones count.
Set the frequency against your complaint rate and your trading rhythm, not against a number from a guide. Google's published sender requirements put the spam complaint rate under 0.30%, and on a list of two thousand that ceiling is six people, so a local list punishes over-mailing much faster than a large one does. In practice that means the shop's own calendar sets the cadence: a new season, a delivery worth mentioning, an event, a closure. If you can't name what makes a send worth opening, that's the week to skip, and a skipped send costs nothing while a complaint is on the record for months.
They need separate treatment, and often a separate sending identity. Receipts are the mail a shop can't afford to have delayed or filtered, and campaign volume is what moves a sending reputation around, so a weekend of hard promotion off one domain is a weekend the receipts ride on. Authenticate properly either way: SPF, DKIM, and DMARC with the From header aligned is the floor both large mailbox providers publish. Beyond that, keep the two streams distinguishable, watch the complaint rate on the promotional one, and make sure suppression applies to the campaigns without ever suppressing somebody's receipt.