The send is only the middle

One of the messiest communications I ever managed was not difficult because of the message itself.

We needed people to enroll in a third-party payment system. On paper, the assignment sounded simple: tell them where to go, explain what to do, and give them a deadline.

The problem was that my team did not own the system. We could not see whether someone had started, gotten stuck, or finished. When people called us for help, we had to send them to the vendor because we could not troubleshoot what they were seeing.

Imagine receiving instructions from a company, calling that company when the instructions do not work, and learning that the people who contacted you cannot see the system either. Excellent experience all around.

We received a completion report from the vendor once a month. Until then, a person continuing to receive a paper check was a clue that they had not enrolled, but a clue is not a status. When the report arrived, we compared it with the people we had contacted, followed up again, and waited for the next report.

The communication had been sent successfully. Operationally, very little was settled.

What are you actually asking someone to do?

That experience changed the first question I ask about an operational communication.

I do not start with, “What do we need to say?” I start with, “What needs to happen?”

Sometimes the answer is simply that the recipient needs to understand an important change. Often, though, we are asking them to do something: sign a document, choose an option, submit information, enroll in a system, correct a record, or contact someone else.

That action has a life outside the message. The recipient has to understand why it matters, decide it is worth interrupting whatever else they are doing, follow the path we gave them, and know where to go when the path does not work.

The organization may care deeply about the outcome. That does not mean the recipient automatically does. If the benefit is unclear, the process is annoying, the support route is useless, or nothing appears to happen after they finish, another reminder email is not necessarily the missing ingredient.

The communication cannot carry an operational process that nobody designed.

Work backward from the outcome

Before drafting, I want to be able to complete one thought:

We need this person to do this specific thing, by this time, in this place, for this reason. If they need help, this person or team can actually help them. We will know it happened when this evidence becomes available.

That sentence forces the uncomfortable parts into the open.

Do we control the system we are sending them into? Can our support team see it? Are we giving the recipient a reason to act, or merely explaining why the organization wants them to? Will we know what happened tomorrow, next week, or once a month? What are we going to do with the people whose status is still unknown?

The answers may change the message, the timing, the support instructions, the follow-up plan, or whether the communication is ready to go at all.

This is not about manufacturing urgency or bribing people into compliance. It is about respecting the fact that the recipient has a life and a workload too. If we need their action, we should make the reason clear and the path possible.

Sent is not the same as finished

The send matters. The correct person still needs the correct message and files, and the release still needs an owner. But the send only proves that the communication left our hands. It does not prove that the recipient understood it, completed the action, received useful support, or reached the intended outcome.

This is part of why I built Letterbatch. It helps with the preparation and validation work before release: bringing recipient data, approved content, documents, and person-specific files into one reviewable workflow and surfacing configured gaps before the output moves into the delivery process an organization controls.

It cannot decide what you need people to do, give them a reason to care, or tell you what happened inside somebody else’s system. I would not trust software that pretended it could.

That judgment still belongs to the people who understand the work.

Before you write the next message, decide what needs to happen after someone reads it. Then work backward until the communication, the action, the support, and the evidence agree.

If this is work you recognize, request an invitation to Letterbatch and tell me what you are trying to make happen.