Guides and instructions
Instructions, FAQs and guides are the least glamorous content a company publishes and often the most useful. They decide whether someone succeeds with your product or writes to support.
The content nobody budgets for
Guides, manuals and FAQ pages rarely appear in a marketing plan. They produce no campaign, they are not shareable, and nobody presents them to a board. They are also the content most likely to be read carefully, because the person reading has a problem and is motivated to finish.
That combination (high attention, low investment) is why so much of it is poor. Instructions get written by whoever built the feature, in one sitting, from memory. It is accurate and unusable, because the author cannot see which steps they are skipping.
Where the failure usually is
Bad instructions are rarely wrong. They are incomplete in a specific way: they omit the step the author considers too obvious to state.
Someone who has performed a task fifty times no longer registers that you have to be logged in as an administrator, or that the setting is on the second tab. To them the sequence is four steps. To a new user it is seven, and they stop at the missing one. This is not carelessness, it is a predictable effect of knowing the system well.
The fix is procedural rather than literary. We perform the task, note every action including the ones that feel too small to mention, and then have someone unfamiliar with the product follow the draft. Where they hesitate is where the document needs work.
Structure matters more than style
Nobody reads a manual. They scan it, looking for the part that applies to them, and they arrive mid-task with the product open in front of them.
That has direct consequences for how these documents are built. Headings have to describe the reader's problem, not the internal feature name, because they are what someone scans and what a search engine matches. Each step covers one action, with a visible result so the reader can confirm they are still on track. Warnings appear before the step they apply to, not after it, which is a small detail that avoids a lot of avoidable damage. And troubleshooting is organised by symptom, since the reader knows what they are seeing and not what caused it.
None of this is stylistic. It is the difference between a document that resolves the problem and one that gets abandoned halfway.
Plain language is a discipline, not a limitation
Writing simply about something complicated is harder than writing about it in the vocabulary of the field. Jargon is efficient among specialists and a wall to everyone else, and the reader who hits that wall does not ask what a term means. They contact support, which is the outcome the document existed to prevent.
We use the customer's vocabulary, keep sentences short, and introduce a technical term only where it is genuinely needed and then define it once. If a concept has three names across your site, we pick one and apply it everywhere. That last point sounds trivial. In practice, inconsistent terminology is one of the more common reasons people fail to find the page that would have answered them.
Documentation is never finished, and it needs an owner
Products change. A screen gets redesigned, a setting moves, a step disappears, and the guide describing it becomes quietly wrong. Wrong documentation is worse than none: it costs the reader time and then costs you the support ticket anyway.
Keeping it current is an ownership problem more than a writing one. We help set up the mapping between product areas and the documents they affect, so a release makes it obvious what needs review. Without that, help content reliably drifts out of date within a few releases and nobody notices until customers start reporting it.
What we need from you follows from that. Access to the product, ideally a real account. Your support tickets, which are the best available list of what to write. And one person who can confirm technical accuracy before publication and stays the same person over time.
What you get
Step-by-step instructions
Procedures written in the order the reader performs them, with each step describing one action and its visible result.
FAQ sections built from real questions
Questions taken from your support inbox rather than invented, phrased the way customers phrase them so they are findable by search and by AI answer engines.
Onboarding and first-use guides
The path from unboxing or signup to the first successful outcome, which is the point where most abandonment happens.
Troubleshooting content
Symptom-first material organised around what the user is seeing, not around the internal component that caused it.
A consistent structure for the whole set
One pattern for headings, step formatting, warnings and terminology, so a reader moving between documents is not relearning the format each time.
A glossary and terminology decisions
One agreed name per concept, applied everywhere. Calling the same thing three names across three pages is a common and quietly expensive problem.
How we work
- 01
Work out where people actually get stuck
We start from support tickets, chat logs and returns reasons. The recurring points of failure become the documentation backlog, in priority order.
- 02
Walk through the process ourselves
Wherever possible we perform the task before describing it. Instructions written from a specification tend to skip the step that is obvious to the author and invisible to everyone else.
- 03
Structure before wording
We agree the document set, the heading pattern and the terminology first, so the individual pieces fit together instead of being reconciled afterwards.
- 04
Write plainly and test on a non-expert
Drafts are checked by someone unfamiliar with the product. If they get stuck, the instruction is wrong, regardless of whether it is technically accurate.
- 05
Review with your specialists and publish
Your team verifies accuracy, we deliver the content in whatever system you use for help material and note what will need revisiting after the next release.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- Markdown
- Docusaurus
- MkDocs
- Meilisearch
- Outline
- LanguageTool
- Vale
- WordPress
- Sanity
- Notion
- Zendesk
- Intercom
Frequently asked questions
More services in this category
Articles and blogs
Regular articles turn your site from a name in a search result into the place people go for an answer, and the archive keeps working long after publication.
Website and landing page content
Your website has a few seconds to explain what you do, who it is for and why it is worth someone's attention. We write the copy that makes those seconds count.
Product descriptions
A good product description does more than list parameters. It tells the customer what those parameters mean for them. That is what turns a browsing visitor into a buyer.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
How many support tickets could a good guide close?
Message usTell us where users get stuck and what your team answers over and over. We will propose a set of guides and FAQs that takes those questions off their plate.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more