Building a Complex Customer Support Workflow

You already know that a searchable knowledge base helps customers and agents find answers faster. If you read How to Automate Customer Support with AI Document Search, you have the foundation: organised documents in a workspace, and search that understands plain-language questions.

This post goes one level further — into a complex workflow, not a single lookup. A single search is perfect for FAQs. Many real tickets are not one-shot questions. Answering them often means several searches in different parts of your knowledge — billing policy in one place, refund rules in another, a how-to guide for upgrades, product requirements, legal wording, and so on. A workflow can run those lookups one after another (or across different workspaces), bring the results together, and only then draft a final reply that reflects everything you found.

On top of that you may need triage, data from an external system, a human check before anything is sent, and a record of what you decided so the next ticket does not start from zero.

You can wire that up in A1KnowHow as a workflow: a repeatable sequence of steps your team runs with one click.

The ticket we will automate

Throughout this walkthrough, imagine Acme Widgets receives:

I was charged twice for my Pro plan after upgrading. Order #10482. Can you fix this?

By the end you will have a workflow that:

1. Classifies the ticket and notes what matters.
2. Searches your support knowledge base (and optionally external sources).
3. Decides whether you have enough information to answer or should escalate.
4. Drafts a reply using your playbooks and this customer’s history.
5. Pauses for a person to approve before anything is sent.
6. Saves what happened to a memory document for the next time.

That matches how many support teams work in practice: log → triage → research → resolve (or escalate) → close, with knowledge updated along the way.

What each part of the product does (plain language)

Phase	What your team does today	What you build in A1KnowHow
Intake	Ticket arrives with the customer’s message	Workflow inputs — message, order id, product area
Triage	Tag topic, urgency, account tier	Agent step + optional SKILL: playbook; facts go to memory
Research	Search policies, billing docs, vendor PDFs	Tool step — search workspace; upload external PDFs; optional MCP step for live data
Diagnose	Enough to answer, or escalate?	Condition step — branch on a yes/no rule
Draft reply	Write a clear, policy-safe answer	Agent with skills + memory
Approve	Lead reviews before send	Human approval step
Close / learn	Note outcome for next time	Agent or tool step appends to memory

Workflow steps come in a few kinds (full detail in Workflow authoring):

Step kind	Use it for
Agent	Triage, summarise, draft, classify
Tool	Search the knowledge base, read or update a document
MCP tool	Call a connected external service (billing API, web fetch, etc.)
Condition	Skip or branch — e.g. only draft if search found results
Human approval	Pause until someone approves or rejects

You add most steps from From Template in the workflow editor; names in the catalogue match what you will see in the app (for example Search workspace by meaning, Agent - With Skills + Memory, Human Approval Gate).

Step 1: Start with your support knowledge base

What you have now: nothing automated yet — just the content search can use.

If you followed the earlier customer support post, you already gathered FAQs, refund policy, billing upgrade rules, and troubleshooting guides.

1. Sidebar → Organize → open or create a workspace, e.g. Acme Support Knowledge.
2. Add documents your agents need:
   • Create Document for policies and SOPs you write in the app.
   • Upload Document for PDFs from vendors, old exports, or partner manuals.
3. Let processing finish so search works across everything.

What you have now: one workspace full of searchable internal (and uploaded) documentation. The workflow will search here in a later step.

Step 2: Add memory for this customer

What you have now: knowledge for everyone — not a durable notebook for this customer.

Agent memory is a normal document — often MEMORY.md — that the agent is told to read before answering and append to after. The same file is used in the next chat or the next workflow run.

1. Create a workspace Acme Support Memory (or use one combined workspace if you prefer).
2. Create Document → name it MEMORY.md.
3. Paste a simple header and an Entries section (see the template in the Agent memory guide).
4. Open the document and copy document id and workspace id from the browser URL (/sb/workspace/.../edit-doc/...). You will paste these into agent instructions. Details: Building your agent — Copy IDs.

Example lines after a few tickets:

- [2026-05-10] fact: Pro plan, order #10482, double charge reported
- [2026-05-10] decision: partial refund approved pending billing confirmation

What you have now: a place that persists facts across sessions. Any agent whose instructions point at this document id can read and update the same history.

Step 3: Add skills (playbooks)

What you have now: memory for facts — but no standard process for tricky ticket types.

Agent skills are short playbook documents. Title them with a team convention such as SKILL: so people and agents recognise them. The agent is instructed to search the skills workspace by meaning, open the best match, and follow the steps.

Create one document per playbook. For Acme Widgets, start with three:

Document title	When to use it
SKILL: billing-double-charge	Duplicate charge, upgrade billing, refund eligibility
SKILL: draft-support-reply	Tone, structure, cite policy, what not to promise
SKILL: when-to-escalate	Legal threat, fraud, no policy match, angry repeat contact

Each skill should include When to use, Steps, and Do not — see the sample in Agent skills.

Copy the skills workspace id from the URL when that workspace is open.

What you have now: reusable playbooks the agent can find without you rewriting instructions every time.

Step 4: Create the agents

What you have now: documents and playbooks — but no saved assistants configured to use them.

You will use two agents (you can combine roles later; splitting keeps triage fast and drafting careful):

Triage agent

1. Settings → Agents → Add New Agent or From Template → Agent - With Memory.
2. Name: Support Triage.
3. In System Prompt, say to: read the customer message; open the memory document by document id; add tags (topic, urgency); append one or two lines to memory.
4. Enable tool access for documents (read/update memory) and search if you want it to peek at the knowledge workspace.
5. Save.

Research and draft agent

1. From Template → Agent - With Skills + Memory (Creating agents).
2. Name: Support Research & Draft.
3. Replace placeholders in the prompt with your skills workspace id, memory document id, and memory workspace id (workflow templates fill these when you configure a workflow step; for a standalone agent, paste from the URL).
4. Save.

Full UI walkthrough: Creating agents. End-to-end wiring: Building your agent.

What you have now: specialists your workflow can call by name.

Step 5: Wire the workflow

What you have now: agents and content — not yet a single button your team can run.

1. Sidebar → Workflows → Create workflow.
2. Name it Acme — Billing ticket research & draft.
3. Add workflow inputs, for example:
   • customer_message (the ticket text)
   • order_id
   • account_id (optional)
4. Add steps From Template, in order. A practical first version:

Inputs: customer_message, order_id

1. triage_ticket          → Agent (Support Triage)
2. search_policies        → Tool: Search workspace by meaning
3. check_external_billing → MCP Tool (optional, if you use a billing integration)
4. enough_to_answer       → Condition - Branch on expression
5. draft_reply            → Agent - With Skills + Memory (Support Research & Draft)
6. approve_reply          → Human Approval Gate
7. save_to_memory         → Agent or document step to append outcome

Chaining steps: later steps use formulas like {{ workflow_inputs.customer_message }} and {{ steps.search_policies.outputs.results }}. Put search results into an agent step input named content, then reference {{ content }} in the prompt — see Workflow authoring.

Condition example: branch to draft_reply only when search returned results; otherwise jump to an escalation agent or a short “need more info” agent.

Human approval: the Human Approval Gate step stops the run until a teammate approves the draft. Nothing goes to the customer until then.

What you have now: a documented, repeatable path from ticket text to approved draft plus memory update.

Step 6: Bring in external documents and live data

What you have now: a workflow that uses your workspace — but some answers live outside it.

Two common additions:

Upload external files

Vendor billing guides, PDF terms, or legacy exports: Organize → your support knowledge workspace → Upload Document. They are processed and searched like any other doc. No workflow change — the Search workspace by meaning step already includes them.

MCP tool step (optional)

When the answer is not in a file — live order status, subscription state, CRM record — add an MCP Tool step after search. You connect an MCP server under Settings (see MCP Servers & LLMs), then pick the server and tool in the step. Pass order_id from workflow inputs with a formula.

Use MCP when data must be current. Use uploaded documents when the source is stable policy text.

What you have now: internal docs, uploaded externals, and optional live lookups in one run.

Step 7: Test with the sample ticket

What you have now: a complete design — verify it behaves as you expect.

1. Sidebar → Workflows → open Acme — Billing ticket research & draft. Click Actions (top right), then Trigger Workflow. Fill in the inputs on the next screen and start the run. (You can also trigger from chat if you configured that on the workflow.)
2. Paste the Acme double-charge message and order 10482.
3. After triage, open MEMORY.md — you should see new triage lines.
4. After search, confirm results reference billing/refund docs.
5. At approval, read the draft — check tone and policy.
6. Approve, finish the run, and confirm memory records the outcome.
7. Run again with a follow-up: “Any update on order 10482?” — the draft agent should read memory and not ask for the order number again.

If something fails, check: document ids in agent prompts, tool access enabled on agents, step order (outputs only flow up to later steps), and that skills workspace id is correct.

What you have now: a workflow you can hand to the team for a whole class of billing tickets.

How this fits your support stack

• Document search alone (first post) deflects simple FAQs.
• Agent chat (Agent Chat) helps one agent research while viewing a document.
• This workflow standardises a multi-step, multi-agent path with memory, skills, optional MCP, and approval — so complex tickets get the same quality every time.

You do not need to build everything on day one. Ship intake + search + one drafting agent + approval; add skills, memory, and MCP as you learn which tickets repeat.

Where to go next

• Guides hub — full series on agents, memory, and skills
• Workflow authoring — formulas, conditions, approvals
• AI Agents — create and manage agents
• Workflows — overview of automation in the product

When you are ready to go deeper on a single pattern, the Building your agent guide walks through memory and skills with another example end to end.