Before You Write: Reader, Purpose, Action Signal & Sentence Here is an email that can consume half a day without looking difficult. Subject: Scanner update. Hi Devon. I wanted to follow up regarding the scanner situation we have been discussing. We have continued to experience some issues, and with next week coming up, I think it would be good to move forward soon. Please let me know your thoughts. The sentences are grammatical. The tone is polite. And the reader still has to ask: What happened? What does move forward mean? What do you need from me? When do you need it? What happens if I do nothing? Now compare this opening. Subject: Approval by three p.m. Friday: two thousand four hundred dollar intake scanner. Devon, please approve the attached two thousand four hundred dollar replacement-scanner quote by three p.m. Friday. Our current scanner now jams several times a day, and approval by Friday keeps expected delivery ahead of Monday's intake surge. The second version is not clearer because it uses prettier sentences. It is clearer because the writer made three decisions before drafting: who the primary reader is, what job the message must do, and what action the reader should take. Today we will build a one-card brief you can use before an email, memo, update, proposal, or procedure. I call it the Reader–Purpose–Action card, or RPA. Reader: who has to understand, decide, or act? Purpose: what is the document's primary job? Action: what should happen after the reader finishes, who owns it, when is it due, and how will anyone know it is complete? Federal plain-language guidance opens with the same rule: write for your audience. And the SEC's Plain English Handbook adds the rest: organize around what readers need, and decide that before you disappear into word-by-word editing. The RPA card is our practical way to do that in a few minutes. Workplace documents often have several readers. That does not mean every reader should control the opening. Choose the primary reader by asking: who can make the decision, perform the action, or use the information next? Then write down three things: What does this reader need in order to proceed? What do they already know? And what might they reasonably question? For our scanner email, Devon is the primary reader because Devon can approve the purchase. Devon needs the amount, timing, reason, and quote. Devon already knows the scanner has caused occasional trouble. Devon may reasonably ask why it must be replaced now and whether there is a lower-cost alternative. Mara's operations team and the purchasing clerk may read the message later. They matter, but neither one owns this decision. The email should not open with a paragraph of operational history for the team or purchasing instructions for the clerk. Those details can follow the approval request or live in the quote. Here is the test: if you write everyone in the Reader box, replace it with the person who must move the work next. Then account for other readers without making them all compete for the first sentence. There is one useful complication. Sometimes the decision owner is not the person with the most subject knowledge. Devon owns the approval, while Mara, the operations lead writing the request, knows the scanner's behavior. That changes the draft. Mara should not write as if Devon watched every jam, and Devon should not have to reconstruct the operational case from a month of messages. The writer's job is to bridge that knowledge gap with the smallest complete set of facts. Try the opposite test too. What can you safely leave out because the primary reader already knows it? If Devon requested this quote yesterday, the email does not need to retell how the purchasing process works. If Devon has never seen the problem, the usual scanner issue is not enough. Reader-centered writing is not automatically shorter. It is complete for this reader and this decision. Next, choose the document's primary job. Most everyday workplace documents are trying mainly to inform, request, decide, instruct, or record. One document can have side effects. A request may also create a record. A memo may inform people after a decision. But if every purpose is primary, none of them can organize the message. This scanner message asks for approval. More specifically: approve one quoted purchase. That tells us what belongs near the top. The history of the failing scanner supports the request. It is not the request. The fact that Monday will be busy creates timing. It is not the request. The vendor quote provides the amount and proposed solution. It is not the request. This distinction prevents a common drafting problem: writing facts in the order you remembered them. Memory order is not reader order. Put the document's job first, then arrange the supporting facts in the order the reader needs. If you cannot name the purpose with a verb and an object—request approval, explain the delay, record the decision, instruct the closer—the document is not ready for sentence polish. Watch how purpose changes the same facts. If Devon already approved the scanner in a meeting, the message is no longer a request. Its job may be to record the decision: This confirms Friday's approval of the $2,400 scanner quote. Mara will submit the order today. Same scanner, same people, different document. If purchasing asks only when to expect the paperwork, the purpose is to inform: The approved scanner order will enter the purchasing queue by 4:00 p.m. today. Forcing the old approval request into either message would create noise and possibly confusion about whether the decision was still open. So do not choose a template by document label alone. Email describes a delivery format, not a purpose. Name what this particular email must accomplish. Now specify the handoff. Action: approve the replacement scanner quote. Owner: Devon. Deadline: 3:00 p.m. Friday. Completion test: the quote is approved in the purchasing workflow, which lets the order go out before the quote expires. Not every message needs a deadline. A fake deadline teaches readers to distrust real ones. Use timing when a real dependency, choice, or consequence makes it useful. And not every document asks for action. If the message is purely informational, replace Action with Retention: what should the reader understand or be able to find later? No reply is needed; the new schedule takes effect Monday is a clear outcome. The completion test is especially useful because vague actions hide different interpretations. Review the quote could mean skim it, comment on it, approve it, or file it. Approve the quote in the purchasing workflow is observable. Here are three more translations. Take a look at the draft becomes Add comments in the draft, or reply 'no changes', by noon Tuesday. Coordinate with the team becomes Mara schedules the 20-minute handoff with intake and purchasing before Thursday. Make sure the records are updated becomes Mara changes the owner field on all twelve open records and posts the completion count in the project log. The goal is not to make every request sound rigid. The goal is to remove the hidden negotiation over what done means. If the action genuinely allows judgment, say where that judgment lives: Recommend one of the three options and note any unresolved risk. That is still observable without pretending the answer is predetermined. Only now do we draft. Start with the action because the primary reader can act and the purpose is a request. Subject: Approval by three p.m. Friday: two thousand four hundred dollar intake scanner. The subject carries the job, topic, and useful timing. Devon, please approve the attached two thousand four hundred dollar replacement-scanner quote by three p.m. Friday. The opening names the action, amount, owner by direct address, and deadline. The current intake scanner now jams several times a day. Approval by Friday lets purchasing place the order before the quote expires and keeps expected delivery ahead of Monday's intake surge. The next two sentences give the immediate reason and the real timing dependency. The quoted model meets the team's current volume requirement. We can retain the existing scanner as an emergency backup. The quote and one-page comparison are attached. This anticipates the reasonable question without turning the email into the entire purchasing file. If you want a different option priced before deciding, please flag that by noon Thursday. Otherwise, approval in the workflow completes the request. The close gives a legitimate exception path and repeats the completion test. Notice what we did not add: a claim that the new scanner will save a specific number of hours, a dramatic prediction about Monday, or a false statement that there is no alternative. Clear writing does not improve weak facts by inventing stronger ones. Before you send, check five failure modes. One: everyone is the audience. You can include several readers, but name the person who owns the next decision or action. Two: the document has three primary jobs. Pick one organizing job. Put secondary effects where they support it. Three: politeness becomes fog. Courtesy is useful. Throat-clearing is not. You can say please approve without I just wanted to reach out and see if perhaps. Four: the action is buried in chronology. Your drafting history is not the reader's required sequence. Lead with what the reader needs now. Five: urgency has no basis. State the dependency—the quote expires, another task cannot begin, the meeting occurs—instead of decorating every subject with urgent. One more problem sits upstream of all five: writing the message before resolving the request. If Mara does not know which scanner, what price, who approves, or when the quote expires, better prose cannot solve the missing decision. The RPA card exposes that gap early. Try this with a real document you need to write, but keep confidential details in your own system. Minute one: write one primary reader. Under the name, list what they need, know, and may question. For the second minute, finish this sentence: This document exists to… Use a verb and an object. Inform the field team. Request budget approval. Record the staffing decision. Instruct the intake closer. Minute three: write the action, owner, deadline, and completion test. If no action is needed, write the one thing the reader should retain. Minute four: write only the subject or heading and the first two sentences. Minute five: challenge the opening. Can the primary reader tell why this reached them, what matters now, and what happens next? If not, revise the plan before you revise the adjectives. Reader. Purpose. Action. Choose the person who moves the work. Give the document one primary job. Make the handoff observable. That short plan will not make every sentence perfect. It does something more important first: it makes the document useful. In the next episode, we will work on the two smallest pieces of an email that carry the most responsibility: the subject line and the opening.