Yes, an AI support agent can launch without a knowledge base or SOPs, but past emails and call transcripts are raw material, not training data you can point it at and walk away. Resolved tickets show how customers phrase a question and what your team said back; they do not tell you which of those answers is still your policy. The practical route is to redact the history, turn a narrow set of resolved tickets into short signed-off articles, launch on those intents only, and let every escalation tell you which article to write next.

This guide is for support leads whose real documentation lives in sent folders, call recordings and a few senior agents' heads. It covers seven steps, a table of what each source is good for, and the tools that help with each part.

Key takeaways

• History tells you the questions; people sign off the answers. A resolved ticket records what one agent said on one day, including exceptions. Treat it as a draft until the policy owner approves it.

• Redact before you mine. The UK ICO says personal data should be adequate, relevant and limited to what is necessary, and Australia's OAIC says de-identification is context dependent and may be difficult to achieve.

• Launch narrow. Pick a handful of high-volume, stable-answer intents and hand everything else to your team on day one.

• One question, one answer, per article. Short articles titled in the customer's own words are easier for retrieval to match than long policy documents.

• Escalations are your backlog. Every ticket the agent hands off is evidence of a missing or unclear answer; review them on a fixed cadence.

How we chose and checked these

We picked the steps that most often decide whether a first AI support launch works when documentation is thin: what to collect, how to protect personal data, how to get answers approved, how to test and how to close gaps. Regulator and standards guidance comes from NIST SP 800-122, the UK ICO, the Office of the Australian Information Commissioner and the NIST AI Risk Management Framework. Every vendor fact in the tools table was checked on that vendor's own public pages on 22 Oct 2026, and each row links to its source.

Lorikeet publishes this guide and is one of the tools listed. We have tried to describe every product, including our own, using only what each vendor publishes, and we link to the source for each claim.

What past emails, chats and call transcripts can and cannot give you

Each source in your history answers a different part of the problem. None of them, on its own, is a policy.

1. Inventory your answers: find where they live today

Start by listing every place a correct answer currently exists. For most teams without a knowledge base that is the helpdesk's sent replies, macros, the call platform's recordings, a shared drive of old onboarding notes, and two or three people who get tagged whenever something is unusual. Export a recent sample rather than everything you have: a few months of resolved tickets is enough to see your top contact reasons, and older tickets are more likely to describe a policy you have since changed.

Tag the sample by intent. You do not need a perfect taxonomy; a spreadsheet with the customer's first message, the intent, the final reply and whether the customer came back is enough. Note which intents need account data (where is my order, why was I charged) and which have one answer for everyone (opening hours, how to reset a password). That split matters later, because the second group can be answered from short articles and the first group needs the agent to read and act in your systems.

Finally, write down who owns each policy area. If nobody owns refunds, the AI agent will not fix that, and the gap will show up as inconsistent answers in week one.

2. Redact and minimise: clean the history before anyone mines it

Clean the data before it is copied anywhere, including into a spreadsheet or a model prompt. NIST SP 800-122 gives context-based guidance for identifying PII and deciding what level of protection each instance needs, and says PII should be protected from inappropriate access, use and disclosure. Under UK GDPR, the ICO describes data minimisation as holding data that is adequate, relevant and limited to what is necessary for your stated purpose.

Australia's OAIC guidance on developing and training generative AI models is the most practical on this. It says that without consent for a secondary, AI-related purpose, an organisation must be able to show the use would be reasonably expected and related to the original purpose; that de-identifying personal information is itself a use for a secondary purpose; and it lists removing or sanitising personal information after collection, before use, as a way to minimise it. It also warns that de-identification is context dependent and may be difficult to achieve, so treat redaction as risk reduction, not a guarantee.

In practice: strip names, emails, phone numbers, addresses, account and card numbers, and anything a customer used to prove who they are. Lorikeet's customer authentication guidance points out that verification answers and codes end up in transcripts, call recordings and system logs, where anyone with access can reuse them. Get your privacy or legal lead to approve the redaction rules once, in writing, before step 3.

3. Pick a narrow first slice: five to ten intents

Choose five to ten intents that are high volume, have a stable answer and carry little risk if the agent hands off instead of answering. Good first candidates are status questions, how-to questions and plan or feature questions. Leave refunds outside policy, complaints, vulnerable customers, anything legal or clinical, and anything where the right answer depends on judgement for later, or for people permanently.

This is how most vendors recommend starting. Lorikeet's getting-started guide says the customers who are most successful start incrementally and get their concierge live and answering some tickets quickly, and its how it works page describes deploying on the topics the agent is trained for and leaving the rest with your team. Whatever tool you use, write the in-scope list down and decide what the agent says when a question falls outside it: a clean handoff to a person, with the conversation attached, is a good outcome on day one.

A narrow slice also makes the documentation job finite. Ten intents means roughly ten to thirty short articles, which one person can draft in a week from the tagged sample, rather than a knowledge base project with no end date.

4. Turn resolved tickets into articles: one question, one answer

For each in-scope intent, pull the best few resolved tickets: the customer did not come back, the reply was complete, and it matches current policy. Rewrite the answer as a standalone article rather than pasting the ticket. Lorikeet's reference material guide sets out rules that apply to any retrieval-based agent:

• Write one question and one answer per article, and title it as the customer's question, using phrases from real tickets.

• Put the answer first and give exact values: "Refunds take 3 to 5 business days", not "a few days".

• Put the answer in the text. That guide notes the agent does not read linked pages, PDFs or videos, so an article that only says "see attached" answers nothing.

• Keep instructions for the agent, such as when to escalate, out of customer-facing articles.

Do not feed raw transcripts in as articles. A transcript contains the agent's guesses, the customer's misunderstandings and the exception a supervisor approved once; retrieval cannot tell which sentence is the policy. Use transcripts to find the question and the customer's vocabulary, then write the answer fresh. For a fuller treatment of article structure, see our knowledge base practitioner's guide and the checklist in is your knowledge base ready for AI.

5. Get policy sign-off: every answer needs an owner

Each article needs a named owner who confirms it is current policy. This is the step teams skip when they are in a hurry, and it is the one with legal consequences. In February 2024, CBC reported that British Columbia's Civil Resolution Tribunal ordered Air Canada to pay a passenger $812 after its website chatbot described a bereavement fare refund process that contradicted another page on the same site. The tribunal member wrote that it should be obvious the airline is responsible for all the information on its website, whether it comes from a static page or a chatbot.

The lesson for a team mining old emails is direct: an answer an agent once gave is not automatically an answer the company stands behind. Ask each owner three questions per article. Is this still true? Are there exceptions the agent should not offer? What should happen when the customer pushes back? Record the answers and a review date. The same reference material guide recommends giving every article an owner and reviewing it at least every 6 months, because an outdated article produces a confident wrong answer where no article would have produced a handoff.

For intents that need account data or actions, the sign-off is on the procedure, not just the wording. That is where SOPs usually get written for the first time, and it is worth doing even if you never automate the intent.

6. Test against history: replay real tickets before go-live

Your redacted ticket history is most valuable as a test set. Replay real questions against the configured agent and read the answers before go-live. The NIST AI Risk Management Framework, released on 26 January 2023 for voluntary use, and its Generative AI Profile, published on 26 July 2024, both frame testing and evaluation as ongoing work across the system's life rather than a launch gate.

Lorikeet's how it works page describes replaying historical tickets and synthetic scenarios in bulk to see projected resolution quality and knowledge gaps before deploying. Its simulation FAQ adds a caution that applies to any tool: when a test scenario is generated from a ticket that went badly, the expected result copies the original mistake, so a person has to edit it to describe what should have happened. Include tickets your team handled poorly; they make the most useful tests.

Set a pass bar per intent before you look at results, and only switch on intents that clear it. Anything that fails goes back to step 4 or step 5.

7. Fill gaps from escalations: review on a fixed cadence

Once live, every handoff tells you something: a missing article, an unclear one, or an intent that should never be automated. Review escalations on a fixed cadence, weekly at first, and sort them into those three buckets.

Tools can do the sorting. Lorikeet's Coach is described as proposing a fix, such as a missing knowledge base article, when it identifies a gap and implementing it with your approval, and its MCP skills list includes a knowledge-gaps skill to find missing knowledge from escalated tickets. The reference material docs also describe promoting a good answer from a handled ticket into a new knowledge article. None of this is automatic learning from transcripts: a person still approves what becomes policy.

Two published examples show the cadence. Firm360 runs analysis every two weeks against Lorikeet's MCP server, Slack and recent customer conversation transcripts, and gets a ranked list of knowledge base gaps with draft answers attached. At Carmoola, Coach helps the team see which escalated conversations to automate next; the story reports 60% of all inbound on WhatsApp, chat and email resolved end to end.

Tools that help: an AI agent for customer support when you don't have a knowledge base or SOPs

Lorikeet publishes this guide and is one of the tools listed. We have tried to describe every product, including our own, using only what each vendor publishes, and we link to the source for each claim.

If you already run Zendesk or Intercom, their native tools are the shortest path to a first draft knowledge base. A layer such as Lorikeet earns its place when the intents you want to automate need account data and actions, not just articles; our guide to what agentic AI means for support explains that difference, and AI support agents you can set up yourself covers self-serve options.

What still needs a human

• Policy decisions. Mining tickets surfaces contradictions; only the policy owner can decide which answer is right.

• Privacy sign-off. Redaction rules, retention and whether this use fits what customers were told need your privacy or legal lead.

• Exceptions and goodwill. Refunds outside policy, complaints and vulnerable customers should route to a person with context.

• Clinical, legal and financial advice. In regulated settings the agent handles the operational question and escalates the judgement, every time.

• Approving new knowledge. Tools can draft articles from escalations; a named person decides what becomes policy.

Questions to ask before you pick a tool

• Can we test the agent against our own historical tickets before it talks to a customer, and see which questions it could not answer?

• Where does redacted or raw ticket data go, who can read it, and is it used to train models?

• When the agent drafts a new article from conversations, who approves it, and is there an audit trail?

• Can it take actions in our systems for account-specific intents, or only answer from articles?

• What happens on a handoff: does the person receive the full conversation and context?

• How long to the first live ticket, and what does the trial include?

If you want to try the process on your own tickets, Lorikeet offers a 30-day free trial with self-serve sign-up. Time to first live ticket is as little as hours, with an average under 29 days, according to its pricing page.