What happens after a research report is approved?
When a research report gets final approval, it feels like the finish line. The analysis is done. The writing survived three rounds of review. Leadership signed off. Everyone exhales.
But approval is not the finish line. It is the point where a different kind of work begins — work that most teams underestimate, understaff, and start too late.
The false finish line
Approval means the content is final. It does not mean the content is ready for anyone to read. Between an approved document and a published web page sits a long list of production tasks that somebody has to do.
These tasks are rarely accounted for in project timelines. When someone says “the report will be ready in two weeks,” they almost always mean the content will be ready. The publication work — the part where someone actually puts it online in a readable, accessible, professional format — is treated as an afterthought.
Then launch day arrives, and everyone wonders why the web version isn’t ready.
What actually needs to happen
Once a report is approved, the publication work includes most or all of the following:
- HTML conversion. The source document — usually Word or InDesign — needs to become structured HTML. Not a PDF embed. Not a screenshot. Proper semantic markup that works on screens.
- Images and figures. Charts, graphs, maps, and infographics need to be exported at the right resolution, compressed, given alt text, and placed correctly in the page.
- Tables. Complex data tables need to be rebuilt in HTML with proper headers, captions, and responsive behavior. A table that works in a PDF at 11x17 does not automatically work on a phone.
- Footnotes and references. Academic and policy reports rely on footnotes, endnotes, and citations. These need to be linked, numbered, and positioned correctly in a web context.
- Accessibility. Heading hierarchy, reading order, color contrast, alt text, link labeling, keyboard navigation. Web accessibility is not optional for government-facing or publicly funded research.
- Mobile and responsive layout. The report needs to read well on a phone. That means rethinking layout, table widths, image placement, and text reflow — not just shrinking the desktop version.
- Downloads and assets. PDF versions, data appendices, Excel files, supplementary materials — all organized, named properly, and linked.
- Bilingual alignment. For organizations that publish in two languages, every heading, figure caption, download link, and table title needs to match across both versions.
Why launches get delayed
In most organizations, report launches slip for one of four reasons. None of them are about the research being late.
Publication work starts too late
The publication timeline only begins when the document is final. If content review takes longer than expected — and it always does — the publication window shrinks. A two-week timeline becomes four days. Quality drops or the launch moves.
Nobody clearly owns the publication step
Research teams own the content. Communications teams own the messaging. The website team owns the CMS. But who owns the actual conversion from finished document to web-ready deliverable? In many organizations, this falls into a gap. Whoever is most available — or most anxious about the deadline — picks it up.
The website team is busy
Internal web teams are often shared resources with their own sprint cycles and priorities. When a report lands on their desk with a three-day turnaround, it competes with every other request. The report might be high priority for the research team, but it is one of ten items for the digital team.
Accessibility review happens at the end
Accessibility is frequently treated as a final check rather than a built-in requirement. When someone runs a screen reader over the page on launch day and finds fifteen issues, the timeline breaks. Either the launch is delayed or the report goes live with problems that have to be fixed after publication.
A brief case study
A public opinion research firm we work with publishes roughly 30 reports a year. Each report goes through a standard approval process: draft, internal review, client review, final. That process works well.
The problem was always the last step. After approval, one of two senior people would spend 6-10 hours manually preparing the web version — rebuilding tables, exporting figures, fixing heading structure, checking links, and aligning the English and French versions. That work pulled them away from the next study, the next client conversation, and the next proposal.
The report was never late because the research was slow. It was late because the publication step was treated as trivial when it was scoped, then consumed real hours when it actually had to be done.
What changes when publication work is planned for
The fix is not complicated. It is recognizing that publication is real work that requires dedicated time — either from internal staff or from someone external.
When teams plan for publication work explicitly, three things tend to happen:
- Timelines get honest.Instead of “approved Tuesday, live Thursday,” the timeline accounts for the 8-12 hours of production work between approval and launch.
- The right people stay on their core work. Senior researchers stop spending afternoons fixing table formatting. Communications leads stop being the accessibility QA team.
- Quality becomes repeatable.When the publication step has a clear owner with a clear process, every report comes out at the same standard. There are no more “the intern did that one” situations.
This is not about adding headcount. It is about acknowledging that the work exists and deciding who should do it — so it stops quietly draining time from people who are supposed to be doing something else.