Reading the ticket for the real question
A support ticket is rarely a request for documentation. It is a story told in a hurry, usually at the moment something stopped working. Before you open a blank page, read the ticket once and write down one sentence: what the person was trying to achieve before the trouble started. That sentence is the promise your help-center entry has to keep.
Then pull out the details that make the story reproducible. Three things matter most:
- The goal the user had in mind, such as connecting an assistant to an API.
- The exact step where things went wrong, worded the way the user experienced it.
- The error text, the tool name, and the settings involved, copied exactly as they appeared.
Hold on to the wording of the error even when it looks unhelpful. People search the help center with the words they saw on their screen, so an entry that repeats those words is easier to find than one that only uses polished internal language.
Finally, strip out anything that belongs to one person. Names, account numbers, and one-off edge cases rarely belong in a public entry. What remains is a general question you can answer once and reuse forever, which is the whole point of writing it down.
Drafting the answer in plain language
Write for someone who opened the help center five minutes after joining. That reader does not know your product vocabulary, does not remember which settings screen holds which field, and has no patience for a paragraph that buries the instruction. Plain language is not about avoiding technical terms; it is about explaining them the first time they appear.
Configuration questions are a good example. At SwiftRelay, a pay-as-you-go relay for Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and other models, the same setup question arrives again and again: which address goes into which tool. Claude Code and Gemini CLI take the bare host, https://api.fastapirelay.com, while OpenAI-compatible SDKs add /v1 to that host. An entry that shows both shapes in one place ends a whole category of tickets.
A few habits keep the prose readable:
- Give one instruction per step, and put the steps in the order the reader will perform them.
- Say what the reader should see after each step so they know they are still on track.
- Prefer verbs like open, paste, select, and save over vague words like handle or configure.
- Keep sentences short, and break long explanations into a list instead of a single paragraph.
Read your draft aloud. Anywhere you stumble, a newcomer will stumble too. If a sentence needs a second reading to make sense, cut it in half or replace it with two clear steps.
Building an entry with the parts readers scan for
Readers rarely read an entry from top to bottom. They scan for the heading that matches their problem, then jump straight to the step they think they need. Give them predictable places to land.
- A title that starts with the task or the error, phrased in the user's own words.
- A short opening line naming who the entry is for and what it solves.
- A prerequisites list covering the account, credentials, and tools required.
- Numbered steps with commands and values formatted so they can be copied safely.
- A closing note telling the reader what to try next when the steps do not fix the problem.
Search wording matters as much as structure. Include the phrases a reader would actually type, such as the exact error line, the tool name, and the setting they were looking for. If your title uses only internal shorthand, the entry can be perfect and still never get found.
Billing questions deserve the same care, because the answer is usually about what a charge means rather than how to pay it. SwiftRelay bills per token with no recurring commitment, new accounts receive a small gift credit, and inviting friends earns 14% of their top-ups. Spelling that out in one entry prevents a surprising number of worried messages.
Aim for one question per entry. It is tempting to answer five related questions in a single page, but readers who land in the middle of a long document often miss the part that solves their case. Group related topics together only after each one stands on its own.
Running the steps before the green light
An entry is a promise that the steps work. Test that promise yourself before publishing. Start from the reader's position: a fresh account, the same tool version, and none of your usual saved settings. Walk through every step exactly as written, including the punctuation in commands and the placement of the host value.
If you cannot reproduce the setup from scratch, borrow a second pair of eyes. Ask a teammate who has never solved that problem to follow the draft while you watch silently. Every place they hesitate is a step that needs clearer wording or a missing detail.
Check the small things that quietly break entries:
- Host values are shown correctly, with the bare host for Claude Code and Gemini CLI and the /v1 path for OpenAI-compatible SDKs.
- Model names match what the dashboard shows, including entries that mention Claude Sonnet 5.5 and Gemini 3.8 Flash.
- Commands are free of stray line breaks that would break pasting into a terminal.
- Expected results describe what success looks like, not just that the command ran.
Publish only when the walkthrough feels boring. Boring means every step did exactly what the sentence promised, with no surprises to explain afterward.
Keeping entries alive after they ship
Shipping an entry is a lap, not a finish line. Tickets keep arriving, and they are your review queue. Watch for the same question appearing after an entry exists; that repetition is evidence the title is hard to find, the steps are out of date, or the page answers a slightly different problem.
Keep a light routine. Once a month, scan new tickets for repeat offenders, skim the top entries for stale instructions, and note anything that changed in the product. Small regular fixes cost far less than a documentation rewrite triggered by a crowded inbox.
Also treat tickets as raw material for new entries. A short answer you typed into a reply is often one edit away from a helpful page. Trim the greeting, generalize the details, run the steps once, and it is ready for readers who never write in at all.
If you are new to SwiftRelay, sign up and try this workflow with a real task, then turn whatever you learn into your first entry. The habits you build here, reading tickets closely, writing plainly, testing carefully, and revisiting what you published, will keep your help center useful long after the first sprint ends.