Inside the Review Inbox
A walkthrough of the SupportPages review inbox: how generated articles queue for approval, what you can edit first, and why nothing publishes unattended.
The most requested feature we have never built is automatic publishing. It comes up in nearly every demo, usually phrased as a compliment: the drafts are good enough, why make me click approve? It is a fair question with a boring answer, which is that the day we ship it is the day the help centre stops being something anyone at your company can vouch for.
Everything that reaches your customers passes through one person deciding it should. That is the constraint the rest of the product is built around.
Four things queue, not one
"Review inbox" undersells it. Four different kinds of work arrive there, and they want different amounts of attention.
Draft articles are the obvious one - a generated article, complete with mockups, waiting for approve or discard. Recommendations are lighter: a proposed topic with a rationale, where approving triggers generation rather than publication. Update suggestions arrive when a merged pull request appears to invalidate something already published, and they carry the diff that prompted them. Walkthrough recommendations flag existing articles that would benefit from video.
The distinction that matters is that only one of those four is expensive to review. A recommendation is a five-second yes or no about whether a topic is worth covering. An update suggestion is usually obvious the moment you see which code changed. Batching those and leaving articles for when you have a proper twenty minutes is how the queue stays manageable, and it is why they are separated rather than presented as one undifferentiated list.
What review actually involves
Not proofreading. If you are reading generated articles for grammar you are spending your attention in the wrong place - that is the part the model is reliably good at.
The three things worth your eyes are all judgement calls a model cannot make from source. Is this the right article - does your audience need this, or is it documenting an internal concept nobody outside engineering thinks about? Is the framing right for your customers rather than for your codebase? And is there something here you would rather not say publicly yet, because the feature is half-rolled-out or the pricing is about to change?
Correctness is the thing people expect to spend review time on and the thing they spend least on after the first fortnight, because the article was written by something that read the actual template. That shift - from checking facts to checking judgement - is the whole trajectory of using the product, and it happens faster than most people expect.
You can edit anything before approving. Title, prose, individual steps, which mockups are included, which section it lands in. Edits stick; regenerating an article does not silently overwrite what you changed.
The queue does not remember your decisions
The queue does not know what you have already decided. Reject a recommendation about a feature you consider internal, and a later audit run may well propose it again, because gap-finding compares coverage against the codebase rather than against your past decisions. That is a genuine annoyance for anyone running regular audits and the fix - a persistent "not this, and here is why" - is the single most obvious missing piece.
There is no reviewer assignment. Everything sits in one shared queue with no way to route articles to whoever owns that area, which is fine at three people and awkward at fifteen.
And approval is currently binary in a way real editing is not. There is no "approve but flag for a second pair of eyes", no partial approval of the prose while the images get redone. You edit until you are happy, then you approve.
Why the constraint stays
I get the argument for auto-publish. At volume, review is the bottleneck, and a system that writes forty articles you have not read is only useful if forty articles can reach customers.
But the value of the help centre is that it is yours. The moment nobody at your company has read a page before a customer does, you have outsourced your voice and your accuracy to a pipeline, and the first time it is confidently wrong about your refund policy you will wish you had not.
Approve in batches, spot-check once you trust it, keep the click.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.