A cited draft on every client ticket

The starting position

The MSP looks after the IT of 14 small and mid-sized companies - accounting firms, a chain of clinics, a logistics business. Its 11 engineers already ran support in UnifyDesk, with each client set up as a product. What they did not have was a quick way to know how this client did things: which VPN, which backup schedule, who could approve a new mailbox, what the fix had been last time.

That knowledge was in a Confluence space per client, a shared folder of standard procedures, and the heads of the two engineers who had been there longest. New engineers took about three months to be useful on every client.

What they set up

SupaCortex on the Business plan, with one project per client. The operations lead set up the first three clients in a day and the rest over the following fortnight.

• Each client's Confluence space connected as a feed to that client's project, re-read every few hours, fetching only changed pages.
• The MSP's 40 standard procedures uploaded into each client project they apply to, as trust tier 1 alongside the client's runbooks.
• In UnifyDesk, the SupaCortex integration switched on with one API key granted the 14 projects, and each UnifyDesk product mapped to its client's project.
• Automatic drafts when a client writes, so the engineer who opens the ticket finds a cited draft already in the editor.
• A ticket-mining feed per client on 18 months of resolved UnifyDesk tickets, limited to that client's product.

Reviewing what the tickets knew

Mining produced about 2,900 candidate questions and answers, with names, email addresses, phone numbers and IDs replaced by placeholders before any model saw them. None was searchable until approved.

Two team leads reviewed them over three weeks, about an hour a day each, and approved roughly 1,050. Most rejections were one-off problems or answers that were right once and no longer are. Approved answers are weighted below the official runbooks in search, so where the two cover the same ground the runbook normally ranks first.

What went wrong first

One clinic had replaced its firewall in the spring, and its Confluence space still held the old firewall's VPN runbook alongside the new one. For a week, VPN drafts for that client cited the old one. The engineers caught it from the citation - the draft named the wrong device - and the old page was archived out of the connected space.

The second lesson was about expectations. Engineers initially read "no draft" as a fault. It was the opposite: on outage reports and new requests the documents had nothing to say, and SupaCortex returned no draft rather than a confident guess. Once the team saw why, the no-draft tickets became the ones it opened first.

The result

By week eight, 74% of tickets had a cited draft waiting when an engineer opened them. UnifyDesk reports back whether each draft was sent unedited or edited: 22% were sent unedited, 41% after editing, and the rest were not used. The draft metrics by category showed where to write next - printer and scanner tickets were discarded most, because nobody had documented the clients' printers.

Median first response fell from 2 hours 40 minutes to 1 hour 45 minutes in business hours, with the same 11 engineers. The newest engineer was taking tickets for every client within six weeks. Every reply was still read and sent by a person.