Support scenarios

A customer-facing agent answers questions, and the business wants the CRM to hold a complete record of every conversation, even ones the agent resolved.

1. Customers chat with a support agent trained on approved help articles.
2. When the conversation ends, a webhook starts a Loop in Command.
3. A CRM-connected agent reviews the conversation and its summary.
4. It creates a case: resolved conversations get a closed status, unresolved or escalated ones get an open, higher-priority status, using the CRM's real status values.
5. The run history records the case ID.

The end of the conversation is when the full context and final score are available. Creating the record then avoids an update for every message.

• Should every conversation become a case, or only ones where someone needs help?
• Which statuses, priorities and custom fields exist in the CRM?
• How will the customer's identity be known?
• What counts as a finished conversation?

• Duplicate cases. Use a unique event reference so a repeated webhook doesn't create two.
• Guessing field values. Check the CRM's actual schema.
• Promising the customer a case number in the chat. The case is created after the conversation ends.

Customer emails already arrive in the service desk as tickets. The business isn't ready to put AI in front of customers.

1. A new ticket triggers a Loop.
2. A support agent with live access to the ticket and trained knowledge analyzes it.
3. It adds a private internal note: likely category, relevant articles, suggested steps, questions to ask, and a draft reply.
4. Staff review and send the response themselves.

The team gets most of the time savings while keeping full control of what customers see. It's a safe way to build trust before going customer-facing.

• Can the service desk send an event when a ticket is created?
• How does it tell internal notes apart from public replies?
• Which fields, if any, may the agent update?
• Who reviews the agent's suggestions?

• Defaulting to AI replies sent through the old ticketing screen, as if from a person. It's usually a clumsy fit. If you do build it, make it a deliberate, controlled choice.

A public agent handles Tier 1 questions and should create a CRM case only when the customer asks for help or the conversation escalates.

Choose one of three variations:

1. During the conversation. The agent gathers context and creates the case through a scoped tool, either directly or through a specialist, then gives the customer the confirmed reference.
2. After the conversation. Escalation fires a webhook that starts a Loop, which creates the case and notifies the team.
3. Hand to a person. Escalation alerts the team in Copilot, and someone joins the same conversation. A case may not be needed if Copilot holds the record of the work.

Most conversations don't need a case. Creating one only when it's useful keeps the CRM clean and the team focused.

• Which words or situations should trigger escalation?
• Should the agent keep responding after escalating?
• Who is notified, and how?
• What details must a case have before it's created?

• Expecting a Loop's case number to appear in the live chat. If the customer needs the number then, create the case directly from the conversation.
• Telling the customer a case exists before the tool confirms it.

The business wants an internal support agent and a customer-facing one. Customers must never see staff-only procedures.

1. Create a private internal agent in Copilot, with internal knowledge and, if needed, access to code or systems.
2. Create a separate customer-facing agent with approved public knowledge and public channels.
3. If keeping public documents in both is a burden, let the internal agent consult the public agent through the orchestrator.
4. Never give the public agent any route to the internal one.

Two agents with separate knowledge is a firm boundary. One agent with complicated "only tell staff" instructions is not.

• Shared knowledge stores between agents. Check which store each agent uses.
• Relying on an instruction to refuse. Test by asking the public agent for internal material as a customer would, and check its knowledge and tools as well as its answers.

There are few past tickets, but plenty of product or equipment manuals, some of them large PDFs.

1. Gather manuals and FAQ pages in a Command knowledge folder, by upload, import or web crawl.
2. Review the converted content, splitting large files and checking scanned text, tables and diagrams.
3. Train the content into the agent's knowledge.
4. The agent answers from the right manual and cites it.

Approved manuals are better training material than raw tickets, which are full of noise.

• Can the text in scanned documents be selected, or does it need recognition?
• Which product versions does each manual cover?
• Which diagrams must survive conversion?
• Are there safety limits on what the agent may advise?
• How will manuals be kept up to date?

• Mixing up product versions. Label every manual.
• Inventing repair steps. The agent should say when it doesn't know.

Customers chat from a signed-in portal and should be recognized, so the agent can look up or create cases for the right contact.

1. The portal signs the customer in.
2. Your servers verify the session and look up the matching CRM contact.
3. The verified identity is passed to the chat, along with display context such as name and plan.
4. The agent uses scoped CRM tools for that verified contact only.

Passing context saves the customer from repeating themselves. Verifying it on the server is what makes it safe.

• Who signs the customer in?
• How is the CRM contact matched on the server?
• Can one account have several contacts, or one person several organizations?
• What happens if the lookup fails?

• Trusting a contact ID sent from the browser. Anyone can change it. Never use it alone to show or change private records.

Most support conversations are simple, but a few lead to case creation, which must be accurate.

1. A light, fast agent answers questions from trained knowledge.
2. If the issue isn't resolved, it collects and confirms the needed details.
3. It passes a focused request to a case specialist on a stronger model.
4. The specialist checks the details are complete and correct, then either asks for what's missing or creates the case with a scoped tool.
5. The confirmed reference is returned.

The front line stays fast and inexpensive, and the stronger model is used only where accuracy matters most. See Cost and model choice.

• Which fields are required?
• When is creating a case allowed?
• How is identity verified?
• What happens if the CRM is unavailable?

• A specialist that only passes the request along. Its job is to check, then act.

Tickets should be assigned to specific people or queues based on product, category or business unit, with some left unassigned.

1. A new or reclassified ticket triggers the agent.
2. The agent reads the ticket through live CRM access.
3. It applies the routing rules written into its instructions.
4. It updates the owner or queue, or leaves the ticket unassigned for a person.

Routing rules are business decisions. Keeping them explicit makes them easy to review and change.

• What are the exact user IDs and queues?
• Are there special cases, or after-hours coverage?
• What should happen when the product is unclear?

• Guessing employee IDs from names. Use the real mapping, owned by the business, and retest whenever it changes.

Unresolved support requests should be emailed to the team, and the business wants to be able to confirm each one was delivered.

1. An unresolved conversation or escalation starts a Loop.
2. The Loop builds a summary with a link to the case.
3. The "Send an email" step sends it, and the run records that the email channel accepted it.
4. Delivery events from your mail provider are matched to the message.
5. Bounced or undelivered messages alert a backup recipient.
6. The run is closed only when the agreed evidence arrives.

The email step confirms the message was accepted for sending, not that it reached an inbox. Proof of delivery needs a second source.

• What does "delivered" mean here: accepted, delivered to a mailbox, opened, or acknowledged by a person?
• How quickly must it arrive, and what's the fallback?
• Who is alerted outside business hours?

• Reporting "sent" as "delivered". If your mail provider can't supply delivery events, name that as a dependency in the design.