Your concurrency guards are all vertical

In a real office, three people might each need something from the same client on the same morning. What stops the client getting three emails before lunch is not a system. It is that they sit near each other, and one of them says "hang on, I already emailed her about the statement."

Software has no equivalent of sitting near each other.

Everything protects the wrong thing

Every safety check in a normal system stops the same job being done twice. Two servers cannot both send the same reminder. The same payment cannot be processed twice. All sensible, all necessary.

Nothing counts how many times one person hears from you.

So a business running three of our services gets three perfectly correct outcomes. The visibility report is ready on Monday. An invoice went overdue overnight. The bookkeeping needs a receipt. Each one is right. Together they are three emails from one company before lunch, and a client who thinks nobody there talks to each other.

Nothing is broken. Every machine is running correctly. There is just nobody deciding what order they go in.

The one rule that makes it work

A limit on contacting clients sounds obvious until you try it and immediately make things worse.

The rule is this: the limit only applies to messages we decided to start. Replying to something the client just said is not spending their attention — it is giving it back.

Get this wrong and you build something genuinely awful: a client asks a question, and gets silence, because a scheduled check-in used up today's quota. That is worse than the problem you were fixing.

If only one thing can go today, send the right one

Just counting messages means the loser is whichever service happened to run second. That is random.

So things are ranked by how much they matter to the person receiving them. Work they are waiting for goes first. Then money. Then something that is blocking work they are paying for. Then a report. Last is a friendly check-in — because the entire reason for a check-in is that nothing else was happening.

Two a day, four hours apart

Two rather than one, because a business that genuinely has two things to say in a day is normal, and a limit of one makes the whole thing feel asleep.

Not three. At three, the fourth becomes inevitable, and the client starts skimming.

The four-hour gap is what actually fixes the original problem. Three messages in one morning is still within a daily limit of two if two of them land at 9am. Spacing them out fixes the impression even when the count was fine.

Do not keep a separate list

The obvious way to build this is a log: every time you contact someone, write it down.

We did not, because that log can quietly disagree with reality. A message that went out but failed to get logged is invisible to the limit — and the client gets the extra email the whole thing existed to prevent.

Instead we count the actual work records that caused the contact. They cannot disagree, because they are the same thing.

Two details that took a while to learn

• Count what you tried to send, not what got through. If a failed send frees up a slot, then a broken mailbox produces more attempts, not fewer. That is a storm.
• A delay must come with a time. "Not now" with no "then when" is the same as "never" — and nobody ever notices the email that did not arrive.

The general version of this: the moment you have several independent things that can all contact the same person, somebody has to own the question "how much of this person's patience have we used today?" Nobody owns it by default. And when nobody owns it, nothing breaks — which is exactly why it goes unnoticed.