Thanking Someone for Documentation: 10 Messages
Tell the author where you used the document. That is feedback a page-view count cannot give them.
Tell the writer what you could do
“Your guide helped me finish the setup without asking someone to walk me through it.” That gives the author evidence that the document works. The sample messages below are fictional; substitute the task you actually completed.
Documentation is often invisible when it succeeds. The reader finds an answer, finishes the work and moves on. A short note returns that useful information to the person who wrote or maintained the resource.
Recognise the lifecycle of a document
Writing is only part of the job. Someone checks the steps, replaces obsolete screenshots and removes instructions that no longer apply. Leaving two contradictory procedures in search can be worse than having no polished introduction at all.
A handover prepares a particular person to take over work. Documentation usually serves several readers over time. Thank the contribution at that scale: the current answer, the tested example, or the decision history that remains understandable after the original team has moved on.
10 messages you can send
I followed your setup guide on a clean laptop and got through without asking for help. Thank you for testing the steps from the beginning.
On a setup guideReports a real use of the document.
Your runbook put the first check at the top. I found the failing dependency before I started changing anything.
On an operational guideCredits the order of the information.
Thank you for updating the screenshots after the form changed. The instructions now match what people actually see.
On maintenanceRecognises keeping a resource current.
The worked example explained the policy better than the rule alone. Thanks for showing what it means in an ordinary request.
On a process explanationNames the part that made the guidance usable.
You wrote down why we rejected that option. Thank you for saving the next team from having to reconstruct the decision.
On decision recordsCredits context that outlasts a meeting.
Thanks for separating the quick steps from the background explanation. I could finish the task and come back to understand the reasoning.
On document structureExplains the value of serving different reading needs.
I appreciated the text description beside the diagram. I could understand the flow without relying on the colours.
On accessible documentationNames a concrete access improvement.
Thank you for removing the old procedure and linking the replacement. Search now takes people to one current answer.
On retiring outdated contentRecognises deletion as maintenance work.
Your troubleshooting section starts with the error people actually see. Thanks for checking the wording against the application.
On finding the right answerCredits language that helps readers locate a solution.
Thanks for asking a new starter to try the guide before publishing it. Their questions found assumptions the rest of us had stopped noticing.
On testing instructionsRecognises verification with a real reader.
What makes one land
Mention the task the document helped you complete.
Credit maintenance and removal of outdated material alongside writing new pages.
Keep links inside the audience’s access permissions.
Share a useful correction separately so appreciation does not become an unsolicited rewrite.
Questions people ask
- How do you recognise documentation work?
Describe a task the document made possible or a decision it helped you understand. Thanking a usable example, an accurate screenshot or a clear recovery step makes the contribution visible.
- Should updates receive the same credit as new documents?
Yes, when the update makes the material useful again. An outdated guide can waste time or direct people to the wrong action. Testing and maintaining it are part of the work.
- What if I found an error in the document?
You can thank what helped and report the error respectfully through the normal editing process. Avoid posting a public compliment that turns into a list of corrections the author did not expect.
The values behind it
Where it fits
Recognition policy
A recognition policy records how an organisation runs employee recognition, including eligibility, responsibilities, acceptable content, rewards and review procedures.
Read the definition
HR and people teams
Recognise HR and people-team contributions with examples for onboarding, clear policies and careful coordination that protect confidential employee information.
Read the guide
IT teams
Recognise IT support, access management and preventive work with examples that value reliable service, useful documentation and appropriate boundaries.
Read the guide
Legal teams
Recognise legal-team contributions through clear advice, careful handovers and useful risk explanations, with examples that protect confidential work.
Read the guide
Marketing teams
Recognise marketing contributions beyond campaign headlines, with examples for research, measurement, production, useful revisions and cross-team coordination.
Read the guide
Research teams
Recognise research contributions through careful methods, useful negative findings and reproducible records, with practical examples beyond positive results.
Read the guide
Other occasions
Only pay for active users who use Evergreen
Lots of support, with a help center and direct email options
Cancel at any time, so why not give us a try
Start feeling good about work
For only $3.99 per active user a month. In the 14 day free trial we don’t plant real trees, but you can skip the trial if you like.
No credit card needed • No setup costs