A support answer desk that drafts replies from your docs

Build me a support answer desk my reps keep open all shift, so they stop hunting through GitBook space by space while a customer sits waiting. It has two tabs: an Answer Desk that support reps work in, and a Docs Gaps tab the documentation team browses.

The Answer Desk tab is two panes. The left pane is the rep's live Zendesk queue: load tickets with List Tickets, defaulting to open and pending tickets and sorted by most recently updated, with a filter for tickets assigned to the logged-in rep. Put a search box above the queue that runs Search Tickets using Zendesk query syntax so a rep can pull up a specific requester, subject, or tag. Each row shows the ticket subject, requester, status, priority, and how long it has been waiting. Clicking a row selects it and loads its full thread with List Ticket Comments so the rep can read the conversation in place.

The right pane is the answer panel. It works from either the selected ticket or a question the rep types or pastes into a box at the top. When the rep hits Find the answer, the handler does two things against GitBook: it runs Search Organization Content to pull the most relevant pages across every space, and it runs Ask AI In Organization with the question to get GitBook's own AI answer over the whole organization. It then composes a drafted customer reply from both, in a plain, friendly support voice, and lists every source underneath. For each source page, call Get Page By ID to fetch the page title and its URL so the citation is a real clickable link rather than a bare id. Show a confidence signal: if the search results come back thin or low relevance, say plainly at the top of the draft that the docs may not cover this, and surface the Log a docs gap button prominently.

The draft lands in an editable text area. The rep edits it, picks public reply or internal note with a toggle, and clicks send, which calls Update Ticket to add the comment to the selected ticket. Nothing is ever sent without the rep clicking. Let the rep also set status on the same send, for example moving the ticket to pending or solved. After a successful send, show the sent comment inline in the thread and clear the draft.

When the docs genuinely do not answer it, the rep hits Log a docs gap. That opens a small dialog with the question pre-filled and editable, and saves a gap record into the app's own storage: the question text, the Zendesk ticket id and a link to it, the ticket subject, the weak search results the app did find, the AI answer it tried, the rep who logged it, and the timestamp. If the question closely matches a gap that already exists, attach this ticket to that existing gap instead of creating a second row, and show the rep that they just joined an existing gap.

The Docs Gaps tab is the documentation team's view of that list. Rank it by how many separate tickets hit the same question, highest first, so the docs team writes the highest leverage page first rather than the most recent one. Tie break by most recent. Each row shows the question, the ticket count as a badge, links out to every attached Zendesk ticket, the best but weak search results the reps saw, who logged it, and a status of open, drafting, drafted, or resolved. Let a docs person merge two gap rows together, which combines their ticket lists and counts, and dismiss a gap that turns out to be covered.

Each gap row has a Write the missing page button, and that is where the embedded background agent lives. Clicking it kicks off an agent that: reads the full thread of every ticket attached to the gap with List Ticket Comments, so it sees how customers actually phrase the problem and how reps eventually answered it; runs Search Organization Content to find the closest existing pages and reads them with Get Page By ID so the new page matches the house structure, voice, and terminology and can cross link properly; drafts the missing page end to end, with a title, an intro, steps, and links to neighbouring pages; opens a GitBook change request in the right space carrying that draft with Create Change Request, titled after the gap and described with the ticket count and links to the source tickets; then writes the change request link and the drafted title back into the gap row in the app and flips its status to drafted; and finally posts to the docs channel with Slack Bot Send a Message, saying which question it wrote a page for, how many tickets asked it, and linking the change request for review. While the agent is running, show that gap row as drafting with a live status, and show the finished change request link on the row when it completes.

Two GitBook details to bake in. The organization level search and ask endpoints both require a scope field in the body or they return a 400, so always send one. Use the organization level ask, which returns plain JSON, rather than the site level ask, which streams server sent events and is awkward to consume in a handler. Also note that edits to live GitBook content only happen through change requests, so the drafted page always lands as a change request for a human to review and merge, never straight onto the live docs.

Persistence and per user behaviour: the gap list is shared across everyone who opens the app, so ticket counts accumulate across the whole support team, but the queue and the draft in progress are per rep. Record which rep logged each gap and which docs person kicked off each page draft, and keep a short history on each gap so the docs team can see it was logged four times over three weeks before anyone wrote the page.