The notification is the last link in an automation and the only one a person reads. The whole scenario can run flawlessly - data is taken in, recalculated, saved - and if the message at the end is badly written, the process fails over the last ten centimetres between the screen and the hand.
The cheapest fix in a whole project is usually the format of a value in a message. The most expensive consequence is usually what happens when that fix is put off.
On the eighth an order came in for the eleventh. It was delivered on the eighth
On an e-shop project with food delivery, orders went into a message with the date written so that day and month could be swapped. On 1 February 2022 the client asked us to change the order, and the reasoning at the time was mild: "it confuses us, one order fell through because of it".
The change was not made then. On 11 March 2022 the same request came a second time, now as urgent - and by then there had been an order the staff read wrongly, and the food was delivered several days before it was due. Five and a half weeks passed between the first request and the second.
Exactly when the format was fixed in the end is not in our records. The request is recorded, not its completion - and that too says something about how small things get handled.
Three things about this case are worth noticing.
First, the fix was technically trivial. It is one formatting string in a message, not a change to the system.
Second, the error was not visible in the data. The date was stored correctly in the database. What was wrong was only how it looked in the message read by a person under pressure with a phone at their ear.
Third and most important: the client submitted the request as a small thing, and so it was treated as a small thing. The phrase "it mildly confuses us" did not pass through any priority queue. Only the second request, after the misdelivered order, began with the word "urgently".
A phone number you cannot call, because the plus got lost on the way
From the same project, the same month, a second case - and a more instructive one, because it was caused by a fix.
On 15 February 2022 a request came in to handle international numbers. We handled them. On 19 February the client reported: in the admin the order shows +420, but in the message that arrives in the messenger the plus is missing, and you cannot call that number by tapping it.
On 22 February the cause was found, and it is nicely inconspicuous: while typing, customers were deleting the 420 prefix from the field, because they had written it there a second time themselves. The plus stayed. The result was a number entering the system that looked right on one screen and did not work on another.
The lesson is not about phone numbers. It is that fixing a format creates another format, and until it is verified along the whole path of the value - from the field in the form, through storage, to the message - you have fixed only the place you were looking at.
What has to be in an order notification
The experience from both cases can be written as a list. It is not long and it costs nothing - it is an hour's work if done while building, and an unpleasant conversation if done after an incident.
The date is written so that it cannot be read two ways. In a message for staff that means the weekday plus the date with the month as a word: "Thursday 11 March". The numeric form 11. 3. is correct and still gets mixed up with 3. 11. by anyone who also sees orders from a foreign system every day. Machine to machine, the date travels in the unambiguous ISO 8601 format (2026-03-11), but that belongs in the data, not in a message for a person.
A date always says what it refers to. "Ordered" and "deliver by" are two different dates in a message, and in a hurry they merge into one.
Times carry a zone whenever anyone in the process is in another country. Midnight is the most dangerous hour in automation: at midnight the whole day shifts.
Phone numbers are stored and sent in international form (E.164, that is +420 and nine digits with no spaces), and the form converts them into that shape itself instead of demanding the right notation from the customer. The customer will not hit the format, and has no reason to.
The order number is in both the subject and the body. It is what the message is later found by when a complaint is being dealt with.
Amounts have a currency. Always, even if you only sell in one country - the first order from abroad arrives before anyone thinks of it.
One piece of information per line. Nobody reads a notification; staff pull three values out of it with their eyes. A solid paragraph makes that impossible.
A test that exposes most of these errors in ten minutes
You need neither a developer nor access to the system for it.
- Create a test order for the eleventh of the month and have it delivered into every channel you use - email, messenger, print, admin. The eleventh because a swap there is only noticeable if you are watching for it; the ideal is an order placed on the 3rd with a delivery date of the 11th, where a swap shows up immediately.
- Compare all the channels side by side. The question is not whether the date is correct but whether it is the same everywhere. A difference between channels is a fault, even if each of them is legible on its own.
- Call the number in the message by tapping it, not by retyping it. That tests the format, not the existence of the number.
- Have someone who does not know the system read the message and ask them when the order is due to be delivered. If they hesitate, the message is badly written regardless of the values in it being correct.
This test is worth repeating after every change to forms or notifications. Our second case came out of a fix.
Why small things of this kind get postponed
Worth saying out loud, because the mechanism is always the same and has nothing to do with the quality of the supplier.
A request to change a format arrives phrased as cosmetics. It has no visible cost of failure, because at the moment it is reported no damage has occurred yet. So it is queued behind features that have a line of their own in the brief.
The solution we use: for requests that concern a message read by a person, one sentence is added to the brief - what happens if it is read wrongly. "It confuses us" and "we will deliver the food three days early" describe the same error, but they land in different places in the queue. The first is a feeling, the second is a consequence, and a priority queue only understands consequences.
Automation does not end when the data is saved. It ends with a sentence a person reads - and that is tested like everything else.
Want us to go through your own notifications
Send us three real messages your system sends about an order and tell us who reads them and in what situation. We will send back a list of the places that can be read two ways, and what to do about them.
Scenarios, integrations and alerts are what we build under business process automation. When the numbers in the messages disagree with what the system shows, that is a different fault and we take it apart in Why your GA4 revenue does not match.
Write to info@lamapixel.com or call +420 775 599 009.
