A staff report is the document most likely to decide how a council vote goes. Council members are elected or appointed officials working through a packet with dozens of pages before a meeting even starts. If a report buries its recommendation under three paragraphs of history, or opens with background nobody asked for, it gets skimmed instead of read. Writing a report that actually gets read is not about better prose. It is about respecting how little time the reader has and putting the decision where they can find it.
Why most staff reports get skimmed, not read
Ask any council member what they wish staff reports did differently, and the answer is usually the same. Too long, too dense, and the actual ask is hard to find. A common pattern is history first: a report opens with a paragraph on when the issue arose, who studied it, and what happened at a prior meeting, before ever stating what the council is being asked to do. By the time the recommendation appears, the reader has already lost the thread.
Council members read many reports back to back, often the night before a meeting, sometimes on a phone or tablet during a commute rather than at a desk. Attention is the scarcest resource in the whole process. A report competing for that attention needs to lead with the point, not build up to it.
The fix is not about writing more elegantly. It is about sequencing. The same information, reordered so the ask comes first, reads as a completely different document, even when not a single fact has changed. A report that respects the reader's time earns a more careful read, not a faster one. Once a council member trusts that a department's reports consistently lead with the point, they read that department's items more closely, not less, because they know the effort of separating the ask from the noise has already been done for them.
Lead with the decision, not the history
The first sentence of a staff report should state the recommended action. Not the history, not the process, the action: approve, deny, adopt, authorize, or direct staff to proceed. Everything else in the report exists to support that one sentence.
This does not mean background disappears. It means background moves after the ask, where it belongs. A reader who agrees with the recommendation on sight can stop there. A reader who wants the full picture can keep reading. Either way, nobody has to hunt for the point.
A useful test for any draft recommendation sentence: could someone who has never seen the item before understand exactly what is being asked, with no other context, just from that one sentence. If the answer is no, the sentence needs another pass before the rest of the report is written. Vague recommendations, such as "receive and file the attached report," are sometimes exactly right, but only when that genuinely is the ask. A recommendation that is actually asking for approval of a specific action dressed up as a passive request to receive information creates confusion at the dais when a member tries to make a motion and cannot tell what they are actually voting on.
Consider two versions of the same opening line. A history first version might begin: "In 2019 the council directed staff to study options for the aging community center roof, and a consultant was retained in the following year to evaluate replacement alternatives." A recommendation first version of the same report instead opens: "Staff recommends the council award a contract to replace the community center roof." Both reports can contain exactly the same background information later on. Only the second version tells a busy reader, in the first five seconds, what decision is actually in front of them.
The parts a complete report needs
Most staff reports for action items need the same handful of parts, in roughly this order.
Recommended action. One or two sentences, stated plainly, at the top.
Background. Enough context to understand why the item is in front of the council, kept short. If the full history matters, link to the prior agenda item or minutes rather than repeating it.
Fiscal impact. Every action item touches the budget in some way, even if the impact is none. Say so directly rather than leaving the reader to guess.
Options considered. A short list of alternatives that were weighed, and why the recommendation was chosen over them. This is what builds trust in the recommendation.
Attachments. Reference every attachment by name so the reader knows what supports the report and what does not.
Prior related actions. A short list of earlier council actions connected to this item, with dates, so a reader can trace the full history without it being repeated in the body of the report.
None of these sections need to be long. A recommendation is one sentence. A background can be three or four. A fiscal impact can be a single line if the answer is simple. Length is not the goal. Completeness is. Skipping any one of these is usually what turns a five minute read into a confused ten minute discussion at the dais.
Writing the recommendation section well
The recommendation section carries the most weight of any part of the report, and it deserves the most careful editing, even though it is usually the shortest section. Use an active, specific verb. "Approve the attached agreement" is clearer than "consider the attached agreement," because the second version does not actually say what action would satisfy the request.
If the recommendation includes more than one action, such as approving an agreement and also authorizing the city manager to execute future amendments within a set scope, list each action separately rather than folding them into a single dense sentence. A council member making a motion needs to know exactly what they are moving, and a compound recommendation that is not clearly broken apart risks an incomplete or inaccurate motion being read into the record.
Avoid conditional language in the recommendation itself. Phrases like "staff recommends the council may wish to consider" hedge so much that the actual ask disappears. If the report is asking for a decision, state the decision being asked for. Save any genuine uncertainty for the background or options section, where it can be explained rather than buried in the ask.
Writing the background section without padding
Background exists to answer one question: why is this in front of the council now. It does not need to recount every meeting that ever touched the topic. A background section that starts three years in the past when the relevant history is really from the last six months is padding, not context, and it pushes the reader further from the point.
A background section can often work backward from the fiscal impact and the recommendation rather than forward from history. Ask what a reader genuinely needs to know to understand why this specific action is being requested today, and include only that. If a longer history matters to a specific reader, a link to the prior staff report or minutes serves that reader without forcing everyone else to read past it.
Dates matter more than narrative in a background section. "The council directed staff to return with options in March" is more useful than a paragraph describing the tone of that meeting's discussion. Precision reads faster than storytelling, and a staff report is not the place for storytelling.
Getting the fiscal impact section right
A fiscal impact section that says only "none" when there genuinely is no cost is fine. A fiscal impact section that says "none" when there is, in fact, a cost, is the single fastest way to lose the room's trust in a report. Every recommendation that spends money, commits to future spending, or changes revenue needs its fiscal impact stated plainly, in dollars and in plain terms, not buried in a paragraph of budget code references.
A complete fiscal impact answers a few consistent questions. Is the cost one time or ongoing. Is it already budgeted, and if so, in which fund or account. If it is not budgeted, where is the money expected to come from. And if the action creates an ongoing obligation, such as a multi year contract or a new staff position, what does that commitment look like in future years, not just the current one.
Even a fiscal impact of zero deserves a sentence explaining why, especially for an action that might otherwise seem like it should cost something, such as accepting a grant that fully covers a project's cost. Stating that explicitly prevents a reasonable question from turning into a delay at the meeting itself.
For a recommendation with a multi year commitment, a short table showing the estimated cost by year is often clearer than a paragraph trying to describe the same numbers in prose. A reader scanning for the total obligation over the life of a contract should not have to do arithmetic on figures scattered across several sentences to find it.
Options considered and why it builds trust
A short list of alternatives that were weighed, and why the recommendation was chosen over them, does more to build confidence in a recommendation than any amount of additional justification for the chosen option alone. A council member reading only the recommendation has to take the department's judgment on faith. A council member who can see that two or three real alternatives were considered, and understands in a sentence or two why each was set aside, is evaluating a decision rather than simply accepting one.
This section does not need to defend every possible option that exists in the abstract. It needs to show that the realistic alternatives were actually weighed. If cost, timeline, legal risk, or community impact ruled out an alternative, say so briefly. This is also the section where a report can acknowledge a genuine tradeoff honestly, such as a lower cost option that comes with a longer timeline, without that honesty undermining the recommendation. A recommendation that acknowledges its tradeoffs directly is more credible, not less.
Write for two audiences at once
A staff report is read twice: once by the council before a vote, and again later by anyone, a resident, a reporter, a future staff member, who pulls the item out of the record. Both audiences need the report to stand on its own.
That means avoiding department jargon and defining any acronym the first time it appears. It means writing the fiscal impact in plain dollars and terms a non specialist can follow. And it means never assuming the reader was in the room for an earlier discussion. The report is the record. If it only makes sense to someone who already knew the backstory, it has failed the audience that matters most: the public.
This is also why acronyms deserve special care. A department that lives inside CIP budgets and RFPs every day forgets that a resident reading the packet later has no idea what those letters mean. Spelling it out once costs a few words and prevents the report from reading like an internal memo that leaked into the public record by accident. The same care applies to internal project names or code names that make sense to staff but mean nothing to anyone outside the building; a report should use the name a member of the public would recognize, or explain the internal name the first time it appears.
Common mistakes that bury the point
A few habits show up again and again in reports that get pushback at the dais.
Passive voice that hides who is responsible for what happens next. Dense paragraphs with no line breaks, so the reader cannot scan for the recommendation. An unclear ask, where it is not obvious whether the council is being asked to approve something or simply receive it as information. And a missing fiscal impact section, which almost always triggers a question from the dais that a complete report would have already answered.
A related mistake is repeating the same fact in two different sections, once in the background and again in the fiscal impact, which pads the report without adding information. A tighter report, where every sentence appears exactly once, is easier to trust because nothing feels like filler. Another common mistake is burying a genuinely important caveat, such as a pending legal question or an unresolved community objection, deep in an attachment instead of surfacing it in the body of the report where the council will actually see it before voting.
A final mistake worth naming is treating every item the same regardless of type. A routine consent calendar item, expected to pass without discussion, still needs a clear recommendation and an honest fiscal impact, but it does not need the same depth of options analysis as a contested action item. A public hearing item, by contrast, often carries specific notice and procedural requirements that belong in the report itself, so a member of the public reading the packet understands not just what is being decided but how the hearing itself will run. Applying a single template without adjusting its depth to the item in front of it either adds unnecessary detail to routine items or shortchanges complicated ones.
Formatting that helps a tired reader scan fast
Structure carries as much weight as wording. Bold section headers that match a consistent structure across every report let a reader jump straight to the fiscal impact or the recommendation without reading the whole document in order. Short paragraphs, ideally no more than four or five sentences, are far easier to scan under time pressure than a single dense block of text.
Bullet points work well for genuinely parallel items, such as a list of options considered or a list of attachments, but they should not replace real sentences in the recommendation or background sections, where the relationship between ideas matters and a list can flatten that relationship into something misleading. Bold text used sparingly, to highlight a dollar figure or a date that a reader is likely to search for, helps a scanning reader more than bold text used throughout a document, which stops meaning anything once everything is emphasized.
Page length deserves the same discipline. A one page limit works for most routine items, and two pages covers the majority of everything else. When a report runs longer than that, it is worth asking whether the extra length belongs in the body of the report at all, or whether it is really supporting detail that belongs in an attachment instead, referenced but not reproduced. Keeping the core report short does not mean hiding complexity. It means separating the decision itself from the material that supports it, so a reader can choose how deep to go.
A simple structure you can reuse across departments
Consistency across departments matters more than any single report being beautifully written. When every department uses the same outline, council members learn where to look for the recommendation, the fiscal note, and the attachments, and they stop having to reparse the format on every item.
A workable outline: recommendation, background, fiscal impact, options considered, attachments, and prior related actions. Keep each section short. Most items, even complicated ones, can be covered in a page or two. Length should track the complexity of the decision, not the habits of whoever wrote the report.
It also helps council members compare items to each other. When the recommendation always appears in the same place, a member scanning a sixty page packet before a meeting can find every ask in the same few seconds per item, instead of hunting through six different formats from six different departments. A shared template file, kept current and used by every department preparing a report, is a small investment that pays off every single meeting.
Reviewing and editing before it reaches the packet
A report is rarely ready for the packet on its first draft, and building in a review step catches problems before they reach the dais rather than after. A second reader, ideally someone outside the department that wrote the report, is well positioned to catch jargon that feels obvious to the author but would confuse an outside reader, and to ask the same questions a council member is likely to ask.
A short review checklist helps make this consistent: does the first sentence state the recommendation clearly, is the fiscal impact stated in plain dollars, are all attachments referenced by name, is every acronym spelled out on first use, and does the background avoid repeating information covered elsewhere in the report. Running a report through a checklist like this before it is finalized catches the same handful of problems that otherwise surface as questions at the meeting itself.
Any report involving a contract, an agreement, or a change to a rule or ordinance should also pass through legal review before it reaches the packet, and the report itself should note that the review happened. A single line noting that the attached agreement has been reviewed as to form gives the council confidence that the legal steps were followed without requiring the full legal analysis to appear in the report itself.
Where a first draft can come faster
Pulling a first draft together from an existing staff report template, a set of attachments, and the minutes from a prior related item is repetitive work, and it is exactly the kind of drafting that AI tools built for local government can help with. A tool like Govera can generate a first pass at the background section from a city's own documents, with each line traceable back to the source it came from, so staff spend their time checking accuracy and sharpening the recommendation instead of starting from a blank page. The recommendation itself, and the judgment behind it, stays with staff.
This matters most for departments that write staff reports only occasionally, where the blank page problem is worst. A consistent starting draft, built from the department's own prior reports and the current item's documents, gives everyone the same baseline quality regardless of how often they write. It also frees up the time that would otherwise go into formatting and reassembling old background language, so more of a writer's attention goes into the part that actually needs human judgment: making sure the recommendation and its reasoning are sound.
