What to Settle Before You Automate Order Confirmations and Invoices

Automated email is the part of a project that is built fastest and underestimated most often. The reason is a distinction that never appears in an automation log. Sent and delivered are two different things, and only one of them is recorded.

When a mail step turns green, it means exactly one thing. A mail server accepted the message for onward delivery. What happens after that is recorded nowhere. The receiving server decides seconds later whether the message goes to the inbox, the junk folder or nowhere at all. When it classifies a message as unwanted, it tells nobody.

Why this gets expensive in day to day operations

With order confirmations you notice it on the phone. The back office fields more calls asking whether the order arrived. With invoices you notice it in payments received, and by then the problem is weeks old. With appointment reminders in a clinic you notice it in patients who do not show up, and that cost never appears in any report as a delivery problem.

This is the awkward class of failure. The numbers look good, the error rate is zero, and the message still reaches nobody.

Three name system records decide the outcome

Every receiving server checks whether the sending server is allowed to write on behalf of your domain. Three records govern that check, and automated sending touches all three.

SPF lists the servers permitted to send for your domain. If an automation platform sends through its own infrastructure, it has to be listed there. The record has a hard limit of ten lookups, and each reference to another service can trigger further ones. In companies that have added a newsletter tool, a customer database, a ticket system and accounting over the years, that limit is often exhausted. Anything beyond the tenth lookup is ignored, and that is typically the service added most recently.

DKIM signs each message, and the recipient verifies the signature against a public key in your name system. Without it a message rarely survives forwarding, because the origin check then falls on the forwarding server. Forwarding is the rule rather than the exception in hospitals, freight forwarders and associations.

DMARC states what a recipient should do when the other two checks do not line up, and it sends you reports on who is sending in your name. Without those reports you learn about a delivery problem from a phone call.

None of this is automation work. It is the precondition, and it belongs in the schedule and in the quote.

The question that actually drives the timeline

Who is allowed to change these records? In many companies the name system sits with an external provider, sometimes with the agency that built the website years ago. Establishing who may raise a ticket there and how long changes take can easily consume two weeks.

That is not a technical problem but an ownership problem, and it is one of the few places where you can shorten a project timeline purely by clarifying something in advance.

Bounces are data, not noise

When a message is rejected, the receiving server sends a response. It goes to the address configured as the sender, which in automated sending is often a mailbox nobody has opened in years.

Decide before launch where these responses go and who reads them. A customer address that is permanently undeliverable belongs back in your master data, otherwise the automation sends into a wall month after month.

Which sending route to choose

There are three usual routes. The mail step of the automation platform, a specialised sending service, and your own mail server. The first is quickest to set up and gives you the least feedback. The second costs a fee and returns delivery statistics while separating bulk sending from ordinary business correspondence. The third keeps everything in house but puts the deliverability of your normal company mail at risk when something goes wrong.

For invoices, order confirmations and appointment reminders the second route is usually right, because it is the only one where you can see what actually arrives.

When the message carries personal data

As soon as an automated message carries personal content, the sending service belongs in your record of processing activities, a data processing agreement is required, and retention of message content at the provider has to be defined. In clinical settings there is a further question. Whether the content may be sent unencrypted at all, or whether the message should only point to a portal.

What is already visible before the project

You do not need an automation to find out whether you have a delivery problem. Take the confirmations or invoices of recent weeks and count how often somebody called to ask whether a message had arrived. Ask accounting how many reminders come back with the answer that the invoice never appeared.

Both numbers are a rough estimate rather than a measurement. They still show the direction, they cost no project time, and they are the best argument for not treating email as a side issue of the project.

The recommendation

Split the project in two. First deliverability, meaning records checked, ownership clarified, sending route decided, bounces collected. Only then the automation itself. In that order the email part costs a few days. In the reverse order a finished automation sits idle for weeks because nobody is allowed to change a record.

Sophera Consulting checks deliverability, ownership and sending route before building, then builds the sending side for a fixed price, with responses routed to a named owner instead of a shared mailbox. The entry point is free via the automation check.