Every time I write a genuinely good answer for a client, donor, or volunteer, I paste it into one document. Pricing questions, process questions, policy questions, the same handful of objections that come up every month. In a month I have a working library I can search, copy, tweak for the person in front of me, and send in seconds. It's the simplest system I run, and it saves more time than almost anything else on this list.
I caught myself writing the same thoughtful answer for what felt like the hundredth time. Same question, a different name at the top of the email. I remember stopping mid-sentence and asking myself why I was composing this from scratch again when I clearly already knew the answer cold. I had written some version of it, and written it well, at least a dozen times before.
That moment is where hack 11 in my "30 Hacks From Dahlia" series came from. It's the least flashy hack in the series so far. There's no tool to install and nothing to automate. It's one document. But it's the system I now point almost every small team toward, because it fixes a problem that has nothing to do with technology and everything to do with how small teams actually run.
Small teams don't have time to reinvent the same paragraph twice
Every small team I've worked with, whether it's a two-person nonprofit or a solo consulting practice, fields the same handful of questions on repeat. What does this cost. How does the process work. What's your policy on refunds or cancellations. Why should we trust you over the other option. The questions rarely change. What changes is who is asking, and that's the only part that actually needs a fresh sentence.
The trouble is that a good answer takes real thought the first time. You're choosing the right words, anticipating the follow-up question, being honest without being blunt. That thinking is valuable, and on a small team it usually happens once, gets used in a single email thread, and then disappears into a sent folder nobody searches. The next time the same question comes in, you either dig through old messages hoping to find it, or you start over. Neither one is a good use of an hour you don't have.
How I set up the document
The folder doesn't need to be complicated, and I'd argue it shouldn't be. Mine is one document, not a wiki, not a database, not a new piece of software to learn. A Google Doc or a Notion page you already have open works fine. The only structure I'd recommend is a handful of simple category headers so you can scan the page at a glance: Pricing, Process, Policies, Common Objections. That's it. Four headers cover most of what a small team gets asked.
Under each header, I don't write generic FAQ copy. I paste the actual answer I sent to an actual person, close to word for word, the version that already worked. Real answers read differently than answers written in a vacuum for a hypothetical FAQ page. They have the texture of a real conversation, which is exactly what makes them fast to reuse and easy to personalize later.
The discipline that makes it work
The part people skip is the part that actually matters: paste the answer in the moment you write it, not later. It's tempting to tell yourself you'll go back at the end of the week and properly organize your best responses. That week never comes. By the time you try to reconstruct a good answer from memory, the sharpest version, the one with the right tone and the right amount of detail, is already gone. What you write instead is a flatter, second-guessed version of the original.
The rule I follow is simple: the moment I send a reply I'm proud of, I copy that paragraph into the document under the right heading, right then, before I move on to the next task. It takes seconds, not a project. No batching it for later, no weekly cleanup session, just capture it while it still exists in its best form.
I didn't need a smarter answer. I needed to stop writing the same good one twice.
Using it day to day
Once the document has a few weeks of real answers in it, using it is the easy part. A question comes in, and I search the document instead of my inbox. I find the closest match, copy it, and tweak it: the name, a specific detail about this person's situation, sometimes the length. I'm never starting from a blank cursor and I'm never guessing at tone, because the tone is already proven. It already worked once.
This isn't a copy-paste-and-never-look-at-it shortcut. I still read every answer before I send it and still adjust it for the person I'm actually writing to. What changes is where the sentence starts. Instead of starting at zero, I'm starting from a draft I already trust.
Keeping it current
A library of answers is only useful if the answers are still true. Pricing changes. A program ends. A policy gets updated after you learn something the hard way. I set aside a short pass, once a quarter is enough, to skim the whole document and retire anything that's outdated. If I update a policy anywhere else, in a contract, on the website, in a client conversation, I go update the matching entry in the document at the same time, not sometime later. An outdated answer sent confidently is worse than no answer at all.
The foundation this becomes
The unglamorous part of this hack is also the reason I keep recommending it. Once you have a real library of your own best answers, you have the raw material for things that used to feel like separate projects. A public FAQ page on your website is much easier to write, because the answers are already tested on real people and already in your own voice. Onboarding a new team member or a VA gets faster too, because instead of explaining your policies from memory in a rushed conversation, you hand them a document that already has the good version written down. And if you ever want an AI tool to help draft replies in your voice, this document is exactly the kind of material that shows it what your voice actually sounds like.
Key takeaways
One hack, out of thirty
This is hack 11 in an ongoing series, and it's proof that not every useful system needs to be complicated or technical. Sometimes the best hack is just deciding to keep what you already wrote. If you run more than one inbox, or answer to more than one audience, whether that's clients, donors, volunteers, or all three, the same pattern scales: one document, sorted simply, updated the moment a good answer exists.
Frequently Asked Questions
Start with the questions you get asked most: pricing, how your process works, your policies on things like refunds or cancellations, and the common objections people raise before they say yes. Those four categories cover most of what a small team fields on repeat.
A FAQ page is written once for a general audience and often sits untouched for months. This folder is private, constantly updated, and made up of real answers you actually sent to real people. It is the working draft a FAQ page eventually gets built from, not a replacement for one.
Set a recurring quarterly pass to skim the whole document and retire anything that no longer matches your current pricing or policies. The better habit is smaller: whenever you update a policy anywhere else, update the matching entry in the document at the same time.
Start today instead of trying to remember old ones. The next time you write an answer you're proud of, about pricing, process, or a tricky question from a client, paste it into a new document right after you hit send. The library builds itself one real answer at a time.
