Why is the help center both the source and the product?
In a software company the help center is where the product is documented, and it is also the most neglected asset, because the people who could improve it are answering tickets instead. A Customer Support Digital FTE on ftes.ai closes that loop: it answers from the help center with a citation, and every question it cannot answer from the help center becomes evidence of a gap. Recurring gaps become proposed articles, and once approved they resolve the next occurrence at first line.
Over a quarter, the help center gets better because of the tickets rather than in spite of them.
How does a cited reply work for a product question?
The FTE reads the ticket, searches the help center and any approved product documentation, and drafts a reply that cites the article it answered from, quoting the relevant step where helpful. If the customer's plan or account state affects the answer, it reads what the connected helpdesk shows and cites that too. If no article answers the question, it does not extrapolate from adjacent articles; it escalates with a note that the help center has a gap, which is what the support lead needs to know.
Review is checking the citation and the tone. Because the source is visible, a wrong reply is caught at the citation, not after the customer replies.
How do gaps become articles?
When the same unanswered question recurs, the FTE proposes an article: the question as customers phrase it, the answer drafted from approved product documentation and, where relevant, from replies the team has given and approved, with sources attached. The support lead approves, edits, or declines. Approved articles are published to the help center through its connection and become a source for the fact gate on the next reply. Nothing publishes unattended, because a wrong article propagates into every future reply.
The proposal queue is also a product signal: the gaps cluster around the features customers find hardest, which the product team can read.
- Trigger: the same unanswered question recurs
- Draft: from approved documentation and approved replies, sourced
- Gate: the support lead approves; nothing publishes unattended
What escalates in software support, and how?
Billing questions and refunds, account access and permission changes, security concerns, bug reports, complaints, and any customer in distress. Each reaches the person who owns that category with a four-part summary: what was asked, what the FTE found, why it did not resolve, and a suggested next step. For bug reports the FTE gathers what a good report needs, the steps, the plan, the browser or client, the time, and attaches it, but it does not assign severity; triage is the engineering team's judgement.
The list is fixed in the remit at every autonomy level and grows after incidents.
What does a support lead measure?
First-line resolution per category against the helpdesk's baseline; median first response including overnight; escalation quality, meaning summaries that met the standard; knowledge gaps closed, as proposed articles approved and first-line resolution in their categories afterwards; and approval rate with send-back reasons per category. Satisfaction where the helpdesk surveys it, unmeasured where it does not. Reply volume is not a measure.
The pattern to watch is first-line resolution rising in a category after its articles were approved, which is the loop working.
What does the first month look like?
Week one: choose one how-to category with reasonable coverage, confirm its articles, write the escalate list with receivers and the summary standard, connect the helpdesk and help center with scoped credentials, and record the baseline. Weeks two to three: approve cited replies in seconds, send back with reasons, review escalations against the standard, and approve the first proposed articles. Week four: read the FTE's own report and decide whether the category has earned auto-send within bounds.
By day 30 one category is owned with a citation on every reply, the help center has gained its first articles from real tickets, and the team starts every escalation from a summary. The second category is set up in a fraction of the time, because the escalate list, the summary standard, and the connections already exist.