An FAQ that addresses user concerns directly will become a valuable support artifact in your product. Listing FAQs as marketing documents during product discovery is a waste of everyone’s time. FAQs are useful to your product when they are addressing user concerns, and the format should be in the form: question + answer in the same order they are asked.
This eliminates the fabricated question. No one has ever typed “what makes this app different” into a help search box.
Clarity starts as a matching problem before it is a writing problem. The person who types “why is my export empty” will not find an article titled Understanding Export Behavior. Matching the question to the user’s own terms rather than using more elegant terminology in the answer is the biggest step teams skip. Prioritizing matching terminology over elegant phrasing of the answer is the best way to ensure the answer is understood. This step is the most skipped.
Ask a model for app FAQs and it will produce the types of questions a marketing page would ask: what is it, who is it for, how do I start. Your actual top ticket is probably about a single failure that occurs in a single browser, and no model will be able to identify that because the answers can be found in your helpdesk.
We ask users to either share the last six months of support tickets or search log data. We have found that the top twenty questions are generally not the questions a product team would have assumed to be the most frequent. The writer answers those questions and double checks the answers against the product to ensure they are correct. They will also flag cases where the most correct answer may be that the product design should be changed.
The set review should be done by Support before the answer is published by the Product team. This is because Support will be able to determine in a day or less whether an answer is wrong. We include a table with the source ticket count corresponding to each question. This usually resolves arguments for keeping or removing an answer without the need to gain an opinion.
One rate, whatever the format: $10 per 100 words. You are paying for the writer’s time and judgement, so the price scales with the words rather than with a package tier.
| Typical app FAQ | Words | Writing | Fee (1%) | You pay |
|---|---|---|---|---|
| Single article | 400 | $40 | $0.40 | $40.40 |
| Five articles | 1,600 | $160 | $1.60 | $161.60 |
| Full section | 4,000 | $400 | $4 | $404 |
The writer receives 100% of the writing price. Our 1% fee is added on top of it, and 0.5% is donated to tree planting. Full pricing breakdown.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Ask on the contact page and a person will answer, usually the same working day. For a live order, reply to your confirmation email and it reaches whoever is handling it.
Next, we use your store reviews, search logs (if any), and a chat with a customer email answerer. That is less precise than ticket data, but it is better than guessing. We also include a note showing which questions came from evidence and which came from the team.
Shortened or long versions are usually both available. We create the long version and cut down a short version for the app, meaning we do not have to update both of them after a while and risk creating contradictory versions.
Completely. Copyright transfers to you on delivery, with no attribution requirement and no licence back to us. Nothing written for you is resold, repurposed or republished.
Reviews from completed, paid orders in this category.
Our releases happen every fortnight, and our notes have evolved into change logs. To keep things organized, the writer has noted what changed within a card or view and what changed underneath. Each note is a brief summary of the change. The biggest metric I’m interested in post release is the volume of support tickets. It always dips.
Our changelog has little snippets about why the change happened, and that seems to have solved the issue of support receiving the ‘what does this actually do?’ tickets. I honestly never thought that release notes would give us the answer for that.
Mostly excellent. Your improvements to the auth section are better than what our engineers wrote. Your pagination endpoints, however, were explained in the spec according to how they behave rather than how they are, which required two revisions. Our spec is incorrect in that area as well.
We do not ask you to take the no-AI promise on trust. Each draft is run through these platforms and the reports are attached to your delivery email.
Originality.aiAI detection + plagiarism
GPTZeroAI detection
TurnitinAI detection + similarity
CopyleaksAI detection + plagiarism
Winston AIAI detection
ZeroGPTAI detection
SaplingAI detection
Content at ScaleAI detection
Send the brief, get a human draft back within 3 days. No account, no subscription, no AI.
$10 per 100 words · all of it to the writer · 0.5% to trees