<\/p>\n\n\n\n
Welcome! This post is about building an Agentforce Service Agent that can respond to customer questions about order updates, tracking information, returns, and refunds. That part sounds simple enough. A customer asks, \u201cWhere is my order?\u201d The agent looks up the order. The agent answers.<\/p>\n\n\n\n
And yet.<\/p>\n\n\n\n
And yet, and yet, and yet.<\/p>\n\n\n\n
The dangerous part of customer service automation is not that the agent might fail to answer. That failure is visible. The customer notices. The support team notices. Someone fixes the configuration.<\/p>\n\n\n\n
The more dangerous failure is when the agent answers too early, with too much confidence, using data the customer has not been verified to receive.<\/p>\n\n\n\n
A customer asking for a tracking number is not just asking for a tracking number. They are asking the system to expose fulfillment data. A customer asking about a refund is not just asking about a refund. They are asking the system to expose payment status, return eligibility, order history, and sometimes account-level information.<\/p>\n\n\n\n
So the first principle for this build is straightforward:<\/p>\n\n\n\n
\nThe agent should not answer private order, return, refund, or tracking questions until the customer has been verified.<\/p>\n<\/blockquote>\n\n\n\n
The second principle is equally important:<\/p>\n\n\n\n
\nWhen the conversation escalates, the human agent should not have to reconstruct the conversation from scratch.<\/p>\n<\/blockquote>\n\n\n\n
That means the agent should do two jobs at once:<\/p>\n\n\n\n
\n
- Help the customer directly when it can safely do so.<\/li>\n\n\n\n
- Prepare the human agent when escalation becomes necessary.<\/li>\n<\/ol>\n\n\n\n
The second job is where the Case object becomes useful. Instead of treating the Case as a passive record created after the conversation goes poorly, we can use it as the shared workspace between Agentforce and the human service team.<\/p>\n\n\n\n
The result is an Agentforce solution that:<\/p>\n\n\n\n
\n
- Greets the customer by name when phone or email context is already available.<\/li>\n\n\n\n
- Verifies the customer before disclosing order, tracking, return, or refund details.<\/li>\n\n\n\n
- Answers supported questions using Salesforce data, external order systems, carrier APIs, refund systems, and knowledge.<\/li>\n\n\n\n
- Writes customer tone, recommended response, and case brief onto the Case record.<\/li>\n\n\n\n
- Displays that intelligence in a Lightning Web Component card.<\/li>\n\n\n\n
- Changes the card color based on customer sentiment:\n
\n
- Red for angry or frustrated customers.<\/li>\n\n\n\n
- Yellow for disappointed or moderately unhappy customers.<\/li>\n\n\n\n
- Green for happy or satisfied customers.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
Let\u2019s build it.<\/p>\n\n\n\n
<\/span><\/span>Agentforce For Service<\/h2>\n\n\n\n
Agentforce should not be designed as a prettier chatbot.<\/p>\n\n\n\n
That sentence is worth sitting with for a moment, because many AI service implementations go wrong at exactly this point. A traditional chatbot is usually designed around decision trees. The designer tries to predict the customer\u2019s phrasing, route the customer through a fixed path, and hope that the available menu options map well enough to the customer\u2019s real problem.<\/p>\n\n\n\n
Agentforce should instead be designed around work.<\/p>\n\n\n\n
The customer has a job to be done:<\/p>\n\n\n\n
\n
- Find my order.<\/li>\n\n\n\n
- Tell me where the package is.<\/li>\n\n\n\n
- Explain why the package is delayed.<\/li>\n\n\n\n
- Start a return.<\/li>\n\n\n\n
- Check whether I am eligible for a refund.<\/li>\n\n\n\n
- Tell me when my refund will arrive.<\/li>\n\n\n\n
- Escalate me to a human because this is not acceptable.<\/li>\n<\/ul>\n\n\n\n
The human support agent also has a job to be done:<\/p>\n\n\n\n
\n
- Understand the customer quickly.<\/li>\n\n\n\n
- Know what the customer already asked.<\/li>\n\n\n\n
- Know what the AI already answered.<\/li>\n\n\n\n
- Understand the customer\u2019s emotional state.<\/li>\n\n\n\n
- Respond with the right tone.<\/li>\n\n\n\n
- Avoid repeating verification steps unnecessarily.<\/li>\n\n\n\n
- Resolve the case.<\/li>\n<\/ul>\n\n\n\n
Agentforce sits between these two jobs. The solution works when the agent respects both.<\/p>\n\n\n\n
<\/span><\/span>The Problem With \u201cJust Answer The Customer\u201d<\/h3>\n\n\n\n
Let\u2019s imagine a customer starts a chat:<\/p>\n\n\n\n
\nWhere is my order?<\/p>\n<\/blockquote>\n\n\n\n
A naive AI implementation might immediately search for a recent order based on the chat session, find the order, and respond:<\/p>\n\n\n\n
\nYour order #10004567 shipped yesterday and is currently in Mumbai. The tracking number is TRK92839102.<\/p>\n<\/blockquote>\n\n\n\n
That sounds useful.<\/p>\n\n\n\n
It is also exactly the kind of response that should make an architect nervous.<\/p>\n\n\n\n
What if the chat was started by someone using a shared device? What if the email on the chat form was mistyped? What if the phone number belongs to a family member? What if multiple contacts share the same account? What if the order contains sensitive delivery information?<\/p>\n\n\n\n
The agent has to pause before it helps.<\/p>\n\n\n\n
That pause is not a bad customer experience. Done correctly, it is the foundation of a trustworthy customer experience.<\/p>\n\n\n\n
Verifying The Customer Before Answering<\/h3>\n\n\n\n
The verification rule for this solution is:<\/p>\n\n\n\n
\n
- If phone or email is available from the channel context, use it to identify a possible Contact.<\/li>\n\n\n\n
- If a single matching Contact is found, greet the customer by name.<\/li>\n\n\n\n
- If the customer is not yet verified, ask for the missing verification detail.<\/li>\n\n\n\n
- If neither phone nor email is available, ask for both email and phone number.<\/li>\n\n\n\n
- Do not disclose private order, return, refund, tracking, or account data until verification succeeds.<\/li>\n\n\n\n
- If verification fails too many times, escalate to a human agent.<\/li>\n<\/ul>\n\n\n\n
That gives us a nice decision table:<\/p>\n\n\n\n
Available Context<\/th> Agent Greeting<\/th> Verification Step<\/th><\/tr><\/thead> Phone matches one Contact<\/td> \u201cHi Priya\u201d<\/td> Ask for email<\/td><\/tr> Email matches one Contact<\/td> \u201cHi Priya\u201d<\/td> Ask for phone<\/td><\/tr> Phone and email match same Contact<\/td> \u201cHi Priya\u201d<\/td> Mark verified<\/td><\/tr> No phone or email<\/td> Generic greeting<\/td> Ask for email and phone<\/td><\/tr> Multiple matches<\/td> Generic greeting<\/td> Ask for email and phone<\/td><\/tr> Mismatch<\/td> Generic greeting<\/td> Escalate or retry<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The goal is to avoid making the customer repeat information when the system already has enough context, while still protecting private information.<\/p>\n\n\n\n
Designing The Agent Around Work, Not Around Prompts<\/h3>\n\n\n\n
The temptation with AI projects is to start with the prompt.<\/p>\n\n\n\n
That\u2019s backwards.<\/p>\n\n\n\n
For this use case, start with the concepts:<\/p>\n\n\n\n
\n
- Customer identity.<\/li>\n\n\n\n
- Verification status.<\/li>\n\n\n\n
- Order status.<\/li>\n\n\n\n
- Tracking status.<\/li>\n\n\n\n
- Return eligibility.<\/li>\n\n\n\n
- Refund status.<\/li>\n\n\n\n
- Sentiment.<\/li>\n\n\n\n
- Escalation readiness.<\/li>\n\n\n\n
- Human agent recommendation.<\/li>\n<\/ul>\n\n\n\n
Once those concepts are named, the implementation becomes cleaner. Each concept maps to data, an action, a field, a subagent, or a component.<\/p>\n\n\n\n
This is the same reason good Apex code tends to improve when we stop stuffing everything into one method. Concepts want shape. If we do not give them shape intentionally, they still show up, just scattered across flows, prompts, Apex classes, screen components, and case comments.<\/p>\n\n\n\n
The Architecture<\/h2>\n\n\n\n
Here\u2019s the architecture for the solution:<\/p>\n\n\n\n
flowchart LR\n Customer[Customer<br\/>Voice, Chat, Messaging] --> Channel[Digital Engagement \/ Voice Channel]\n\n Channel --> Context[Channel Context<br\/>Phone, Email, Name, Session Id]\n Context --> Agent[Agentforce Service Agent]\n\n Agent --> Verify[Verification Subagent]\n Agent --> Order[Order Status Subagent]\n Agent --> ReturnRefund[Returns & Refunds Subagent]\n Agent --> Escalation[Escalation Summary Subagent]\n\n Verify --> A1[Action: Verify Customer]\n Order --> A2[Action: Get Order Updates]\n Order --> A3[Action: Get Tracking Info]\n ReturnRefund --> A4[Action: Check Return Eligibility]\n ReturnRefund --> A5[Action: Get Refund Status]\n Escalation --> A6[Action: Generate Case Brief]\n Escalation --> A7[Action: Update Case Intelligence]\n\n A1 --> CRM[(Salesforce CRM<br\/>Contact, Account, Case)]\n A2 --> OMS[(Order Management<br\/>Order Summary \/ External OMS)]\n A3 --> Carrier[(Carrier API<br\/>FedEx, UPS, DHL, Shiprocket)]\n A4 --> Policy[(Knowledge \/ Return Policy)]\n A5 --> Payment[(Payment \/ Refund System)]\n A6 --> Case[(Case Object)]\n A7 --> Case\n\n Case --> LWC[LWC Case Assist Card<br\/>Tone, Recommendation, Brief]\n LWC --> Human[Human Service Agent]\n Human --> Customer\n<\/code><\/pre>\n\n\n\nThe diagram is intentionally simple. The actual implementation might include Data Cloud, MuleSoft, Named Credentials, Platform Events, Omni-Channel, Service Cloud Voice, Messaging for In-App and Web, and external order systems. Those details matter, but the conceptual flow remains the same:<\/p>\n\n\n\n
\n
- Customer enters through a channel.<\/li>\n\n\n\n
- Agent receives the message and available context.<\/li>\n\n\n\n
- Agent verifies the customer.<\/li>\n\n\n\n
- Agent retrieves the right operational data.<\/li>\n\n\n\n
- Agent responds if it can.<\/li>\n\n\n\n
- Agent escalates if needed.<\/li>\n\n\n\n
- Agent writes guidance to the Case.<\/li>\n\n\n\n
- Human agent sees the LWC card and responds appropriately.<\/li>\n<\/ol>\n\n\n\n
Data Model<\/h2>\n\n\n\n
For this implementation, we\u2019ll assume the following Salesforce data model:<\/p>\n\n\n\n
Standard Objects<\/h3>\n\n\n\n
\n
- Contact<\/li>\n\n\n\n
- Account<\/li>\n\n\n\n
- Case<\/li>\n\n\n\n
- Order Summary or Order<\/li>\n\n\n\n
- Order Item Summary or Order Product<\/li>\n\n\n\n
- Return Order, if Salesforce Order Management is used<\/li>\n\n\n\n
- Knowledge Article, for return and refund policy content<\/li>\n<\/ul>\n\n\n\n
External Systems<\/h3>\n\n\n\n
\n
- Order Management System<\/li>\n\n\n\n
- Shipping carrier API<\/li>\n\n\n\n
- Payment gateway or refund processor<\/li>\n\n\n\n
- ERP, if order fulfillment lives outside Salesforce<\/li>\n<\/ul>\n\n\n\n
Custom Fields On Case<\/h3>\n\n\n\n
Create the following fields on Case:<\/p>\n\n\n\n
Field Label<\/th> API Name<\/th> Type<\/th> Purpose<\/th><\/tr><\/thead> Customer Tone<\/td> Customer_Tone__c<\/td> Picklist<\/td> Angry, Frustrated, Disappointed, Neutral, Happy, Satisfied<\/td><\/tr> Sentiment Level<\/td> Sentiment_Level__c<\/td> Picklist<\/td> Red, Yellow, Green<\/td><\/tr> Agent Recommendation<\/td> Agent_Recommendation__c<\/td> Long Text Area<\/td> Suggested response approach for human agent<\/td><\/tr> Agent Brief<\/td> Agent_Brief__c<\/td> Long Text Area<\/td> Summary of conversation, order context, and unresolved issue<\/td><\/tr> Verification Status<\/td> Verification_Status__c<\/td> Picklist<\/td> Not Started, Pending, Verified, Failed<\/td><\/tr> Verified Contact<\/td> Verified_Contact__c<\/td> Lookup(Contact)<\/td> Contact verified during conversation<\/td><\/tr> Last Verified Email<\/td> Last_Verified_Email__c<\/td> Email<\/td> Email used for verification<\/td><\/tr> Last Verified Phone<\/td> Last_Verified_Phone__c<\/td> Phone<\/td> Phone used for verification<\/td><\/tr> Escalation Reason<\/td> Escalation_Reason__c<\/td> Long Text Area<\/td> Why the agent escalated<\/td><\/tr> Last Agent Action<\/td> Last_Agent_Action__c<\/td> Text<\/td> Last action executed by Agentforce<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n You could put some of this data on a related custom object instead of Case. For example,
Agent_Assist_Insight__c<\/code> could track multiple snapshots over time. That is useful when you want history across a long case lifecycle.<\/p>\n\n\n\nFor this blog post, I\u2019ll keep the design focused on the Case object because the user requirement is to show the brief, tone, and recommendations as an LWC card on Case.<\/p>\n\n\n\n
Agentforce Subagents<\/h2>\n\n\n\n
Create one Agentforce Service Agent and break its responsibility into subagents.<\/p>\n\n\n\n
1. Customer Verification Subagent<\/h3>\n\n\n\n
Purpose:<\/p>\n\n\n\n
Verify customer identity before any private information is disclosed.<\/p>\n\n\n\n
Instructions:<\/p>\n\n\n\n
You verify the customer before private information is shared.\n\nIf the channel context contains a phone number or email address, use it to identify the customer.\n\nIf a single matching Contact is found, greet the customer by first name.\n\nIf only phone is available, ask the customer to provide their email address.\n\nIf only email is available, ask the customer to provide their phone number.\n\nIf neither phone nor email is available, ask for both email and phone number.\n\nDo not reveal order, refund, return, shipment, address, payment, or account-specific information until the Verify Customer action returns verified = true.\n\nIf verification fails two times, escalate to a human agent and update the Case brief.\n<\/code><\/pre>\n\n\n\nThis subagent owns the gate.<\/p>\n\n\n\n
Everything else depends on it.<\/p>\n\n\n\n
2. Order Status Subagent<\/h3>\n\n\n\n
Purpose:<\/p>\n\n\n\n
Answer order update and tracking questions after verification.<\/p>\n\n\n\n
Instructions:<\/p>\n\n\n\n
You answer questions about order status, shipment status, delivery estimates, delays, and tracking numbers.\n\nBefore answering, confirm that Verification Status is Verified.\n\nUse Get Order Updates for order status.\n\nUse Get Tracking Info for shipment and carrier events.\n\nIf there are multiple recent orders, ask the customer which order they mean.\n\nIf order data is unavailable, apologize briefly, explain that the order details need review, and escalate to a human agent.\n\nNever invent tracking numbers, delivery dates, refund dates, or carrier statuses.\n<\/code><\/pre>\n\n\n\n3. Returns And Refunds Subagent<\/h3>\n\n\n\n
Purpose:<\/p>\n\n\n\n
Answer return eligibility, return process, refund amount, and refund timing questions.<\/p>\n\n\n\n
Instructions:<\/p>\n\n\n\n
You answer questions about return eligibility, return process, refund status, refund timing, and refund policy.\n\nBefore answering, confirm that Verification Status is Verified.\n\nUse Check Return Eligibility before saying whether an item can be returned.\n\nUse Get Refund Status before saying whether a refund was issued.\n\nUse Knowledge only for general policy explanations.\n\nFor account-specific refund status, use system data only.\n\nIf the customer is angry, disappointed, or mentions legal action, escalation, repeated failed attempts, missing refund, or damaged product, update the Case with a recommendation for a human agent.\n<\/code><\/pre>\n\n\n\n4. Escalation Summary Subagent<\/h3>\n\n\n\n
Purpose:<\/p>\n\n\n\n
Prepare the human agent.<\/p>\n\n\n\n
Instructions:<\/p>\n\n\n\n
You summarize the conversation for a human support agent.\n\nWrite a concise case brief.\n\nClassify customer tone as Angry, Frustrated, Disappointed, Neutral, Happy, or Satisfied.\n\nMap the customer tone to a sentiment level:\n- Red for Angry or Frustrated\n- Yellow for Disappointed or Neutral\n- Green for Happy or Satisfied\n\nWrite a recommended response strategy for the human agent.\n\nThe recommendation should include:\n- whether the agent should apologize\n- whether the agent should acknowledge delay or inconvenience\n- what information the agent should confirm\n- the next best action\n- what not to repeat if the customer has already provided it\n<\/code><\/pre>\n\n\n\nThis is the part that changes the service experience for human agents. Instead of opening a Case and reading a long transcript, the agent sees a colored card with a brief and recommendation.<\/p>\n\n\n\n
Actions<\/h2>\n\n\n\n
The Agentforce actions are the contract between the agent\u2019s reasoning and your business systems.<\/p>\n\n\n\n
For this solution, create these actions:<\/p>\n\n\n\n
Action<\/th> Type<\/th> Purpose<\/th><\/tr><\/thead> Verify Customer<\/td> Apex or Flow<\/td> Match phone and email to Contact<\/td><\/tr> Get Order Updates<\/td> Apex, Flow, or API<\/td> Retrieve order status<\/td><\/tr> Get Tracking Info<\/td> Apex or MuleSoft API<\/td> Retrieve shipment tracking<\/td><\/tr> Check Return Eligibility<\/td> Flow or Apex<\/td> Determine return eligibility<\/td><\/tr> Get Refund Status<\/td> Apex or API<\/td> Retrieve refund status<\/td><\/tr> Generate Case Brief<\/td> Prompt Template or Apex<\/td> Summarize customer issue<\/td><\/tr> Update Case Intelligence<\/td> Apex or Flow<\/td> Write tone, recommendation, and brief to Case<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The action descriptions matter. A vague action description gives the agent too much room to choose incorrectly.<\/p>\n\n\n\n
Poor description:<\/p>\n\n\n\n
Gets customer information.\n<\/code><\/pre>\n\n\n\nBetter description:<\/p>\n\n\n\n
Verifies whether the customer-provided email and phone number belong to a single Contact. Use this action before sharing order, shipment, return, refund, address, or payment information.\n<\/code><\/pre>\n\n\n\nPoor description:<\/p>\n\n\n\n
Gets order info.\n<\/code><\/pre>\n\n\n\nBetter description:<\/p>\n\n\n\n
Retrieves order status, fulfillment status, estimated delivery date, and order summary for a verified Contact. Use only after customer verification succeeds.\n<\/code><\/pre>\n\n\n\nThe description is not documentation for humans only. It is part of how the agent decides what tool to use.<\/p>\n\n\n\n
A Naive Approach To Customer Service Automation<\/h2>\n\n\n\n
Let\u2019s start with the kind of implementation that looks acceptable in a demo:<\/p>\n\n\n\n
public with sharing class OrderAnswerService {\n public static String answerOrderQuestion(String email) {\n Contact contact = [\n SELECT Id, Name\n FROM Contact\n WHERE Email = :email\n LIMIT 1\n ];\n\n Order latestOrder = [\n SELECT Id, Status, Tracking_Number__c\n FROM Order\n WHERE AccountId = :contact.AccountId\n ORDER BY CreatedDate DESC\n LIMIT 1\n ];\n\n return 'Your latest order is ' + latestOrder.Status +\n '. Tracking number: ' + latestOrder.Tracking_Number__c;\n }\n}\n<\/code><\/pre>\n\n\n\nThis is useful as a warning, not as a pattern.<\/p>\n\n\n\n
There are several problems here:<\/p>\n\n\n\n
\n
- Email alone may not be enough to verify the customer.<\/li>\n\n\n\n
- The query assumes one matching Contact.<\/li>\n\n\n\n
- It assumes the latest order is the order the customer means.<\/li>\n\n\n\n
- It exposes a tracking number immediately.<\/li>\n\n\n\n
- It has no escalation behavior.<\/li>\n\n\n\n
- It writes nothing useful back to Case.<\/li>\n\n\n\n
- It gives the human agent no context if the customer gets transferred.<\/li>\n<\/ol>\n\n\n\n
The issue is not that the code is short. Short code is often good. The issue is that the important concepts are missing.<\/p>\n\n\n\n
There is no verification concept. There is no ambiguity concept. There is no customer tone concept. There is no human handoff concept.<\/p>\n\n\n\n
Those concepts will still exist in the real world. The customer will still be frustrated. The Contact match will still be ambiguous. The order will still be delayed. The human agent will still need a summary.<\/p>\n\n\n\n
The system simply will not represent those realities well.<\/p>\n\n\n\n
Moving Verification Into A First-Class Concept<\/h2>\n\n\n\n
Let\u2019s give verification a shape.<\/p>\n\n\n\n
A simplified Apex action could look like this:<\/p>\n\n\n\n
public with sharing class VerifyCustomerAction {\n public class Request {\n @InvocableVariable(required=false)\n public String email;\n\n @InvocableVariable(required=false)\n public String phone;\n\n @InvocableVariable(required=false)\n public String caseId;\n }\n\n public class Response {\n @InvocableVariable\n public Boolean verified;\n\n @InvocableVariable\n public String contactId;\n\n @InvocableVariable\n public String contactName;\n\n @InvocableVariable\n public String status;\n\n @InvocableVariable\n public String message;\n }\n\n @InvocableMethod(label='Verify Customer')\n public static List<Response> verify(List<Request> requests) {\n List<Response> responses = new List<Response>();\n\n for (Request req : requests) {\n Response res = new Response();\n\n if (String.isBlank(req.email) || String.isBlank(req.phone)) {\n res.verified = false;\n res.status = 'Pending';\n res.message = 'Email and phone are required before private information can be shared.';\n responses.add(res);\n continue;\n }\n\n List<Contact> contacts = [\n SELECT Id, Name, Email, Phone, MobilePhone\n FROM Contact\n WHERE Email = :req.email\n AND (Phone = :req.phone OR MobilePhone = :req.phone)\n LIMIT 2\n ];\n\n if (contacts.size() == 1) {\n Contact matchedContact = contacts[0];\n\n res.verified = true;\n res.contactId = matchedContact.Id;\n res.contactName = matchedContact.Name;\n res.status = 'Verified';\n res.message = 'Customer verified.';\n\n updateCaseVerification(req.caseId, matchedContact, req.email, req.phone, 'Verified');\n } else if (contacts.isEmpty()) {\n res.verified = false;\n res.status = 'Failed';\n res.message = 'No matching customer was found for the provided email and phone.';\n updateCaseVerification(req.caseId, null, req.email, req.phone, 'Failed');\n } else {\n res.verified = false;\n res.status = 'Ambiguous';\n res.message = 'Multiple customers matched. Human review is required.';\n updateCaseVerification(req.caseId, null, req.email, req.phone, 'Failed');\n }\n\n responses.add(res);\n }\n\n return responses;\n }\n\n private static void updateCaseVerification(\n String caseId,\n Contact contact,\n String email,\n String phone,\n String status\n ) {\n if (String.isBlank(caseId)) {\n return;\n }\n\n Case c = new Case(\n Id = caseId,\n Verification_Status__c = status,\n Last_Verified_Email__c = email,\n Last_Verified_Phone__c = phone\n );\n\n if (contact != null) {\n c.Verified_Contact__c = contact.Id;\n }\n\n update c;\n }\n}\n<\/code><\/pre>\n\n\n\nThis action does not answer the customer\u2019s question. That\u2019s the point.<\/p>\n\n\n\n
It answers a more important system question first:<\/p>\n\n\n\n
\nAre we allowed to answer the customer\u2019s question?<\/p>\n<\/blockquote>\n\n\n\n
That distinction is what keeps the agent safe.<\/p>\n\n\n\n
Order And Tracking Actions<\/h2>\n\n\n\n
Once verification succeeds, the order subagent can retrieve order data.<\/p>\n\n\n\n
A simplified order status response might look like this:<\/p>\n\n\n\n
public with sharing class GetOrderUpdatesAction {\n public class Request {\n @InvocableVariable(required=true)\n public String contactId;\n\n @InvocableVariable(required=false)\n public String orderNumber;\n }\n\n public class Response {\n @InvocableVariable\n public Boolean success;\n\n @InvocableVariable\n public String orderNumber;\n\n @InvocableVariable\n public String orderStatus;\n\n @InvocableVariable\n public String fulfillmentStatus;\n\n @InvocableVariable\n public String estimatedDeliveryDate;\n\n @InvocableVariable\n public String message;\n }\n\n @InvocableMethod(label='Get Order Updates')\n public static List<Response> getUpdates(List<Request> requests) {\n List<Response> responses = new List<Response>();\n\n for (Request req : requests) {\n Response res = new Response();\n\n List<Order> orders = [\n SELECT Id, OrderNumber, Status, Fulfillment_Status__c, Estimated_Delivery_Date__c\n FROM Order\n WHERE AccountId IN (\n SELECT AccountId\n FROM Contact\n WHERE Id = :req.contactId\n )\n ORDER BY CreatedDate DESC\n LIMIT 5\n ];\n\n if (orders.isEmpty()) {\n res.success = false;\n res.message = 'No recent orders were found for the verified customer.';\n } else if (String.isBlank(req.orderNumber) && orders.size() > 1) {\n res.success = false;\n res.message = 'Multiple recent orders were found. Ask the customer which order they mean.';\n } else {\n Order selectedOrder = selectOrder(orders, req.orderNumber);\n\n if (selectedOrder == null) {\n res.success = false;\n res.message = 'The requested order was not found for the verified customer.';\n } else {\n res.success = true;\n res.orderNumber = selectedOrder.OrderNumber;\n res.orderStatus = selectedOrder.Status;\n res.fulfillmentStatus = selectedOrder.Fulfillment_Status__c;\n res.estimatedDeliveryDate = String.valueOf(selectedOrder.Estimated_Delivery_Date__c);\n res.message = 'Order details retrieved.';\n }\n }\n\n responses.add(res);\n }\n\n return responses;\n }\n\n private static Order selectOrder(List<Order> orders, String orderNumber) {\n if (String.isBlank(orderNumber) && orders.size() == 1) {\n return orders[0];\n }\n\n for (Order o : orders) {\n if (o.OrderNumber == orderNumber) {\n return o;\n }\n }\n\n return null;\n }\n}\n<\/code><\/pre>\n\n\n\nIn a production implementation, I would usually avoid putting external carrier logic directly inside this class. The cleaner approach is to create separate services:<\/p>\n\n\n\n
\n
OrderLookupService<\/code><\/li>\n\n\n\nTrackingService<\/code><\/li>\n\n\n\nReturnEligibilityService<\/code><\/li>\n\n\n\nRefundStatusService<\/code><\/li>\n\n\n\nCaseInsightService<\/code><\/li>\n<\/ul>\n\n\n\nThat keeps each concept isolated.<\/p>\n\n\n\n
Case Intelligence<\/h2>\n\n\n\n
Now we get to the feature that helps the human agent.<\/p>\n\n\n\n
When the conversation escalates, the agent should update the Case with:<\/p>\n\n\n\n
\n
- Customer tone<\/li>\n\n\n\n
- Sentiment level<\/li>\n\n\n\n
- Recommended response<\/li>\n\n\n\n
- Brief summary<\/li>\n\n\n\n
- Escalation reason<\/li>\n\n\n\n
- Last action taken<\/li>\n<\/ul>\n\n\n\n
Example Case brief:<\/p>\n\n\n\n
Customer asked for the status of order #10004567. Customer was verified using email and phone. Agent retrieved tracking and found the package delayed by two days. Customer became frustrated because this is the second delay and requested a human agent.\n<\/code><\/pre>\n\n\n\nExample recommendation:<\/p>\n\n\n\n
Start by apologizing for the repeated delay. Do not ask the customer to repeat email or phone verification because verification is already complete. Confirm that the package is delayed by two days, explain the current carrier scan, and offer either continued tracking support or a return\/refund review if the customer no longer wants the item.\n<\/code><\/pre>\n\n\n\nExample tone:<\/p>\n\n\n\n
Frustrated\n<\/code><\/pre>\n\n\n\nExample sentiment level:<\/p>\n\n\n\n
Red\n<\/code><\/pre>\n\n\n\nThis is the kind of summary that saves time in the console. The human agent can enter the conversation already knowing what happened, what not to repeat, and how carefully to phrase the next response.<\/p>\n\n\n\n
A simplified update action:<\/p>\n\n\n\n
public with sharing class UpdateCaseIntelligenceAction {\n public class Request {\n @InvocableVariable(required=true)\n public String caseId;\n\n @InvocableVariable(required=true)\n public String customerTone;\n\n @InvocableVariable(required=true)\n public String agentBrief;\n\n @InvocableVariable(required=true)\n public String agentRecommendation;\n\n @InvocableVariable(required=false)\n public String escalationReason;\n\n @InvocableVariable(required=false)\n public String lastAgentAction;\n }\n\n public class Response {\n @InvocableVariable\n public Boolean success;\n\n @InvocableVariable\n public String message;\n }\n\n @InvocableMethod(label='Update Case Intelligence')\n public static List<Response> updateCase(List<Request> requests) {\n List<Response> responses = new List<Response>();\n\n for (Request req : requests) {\n Response res = new Response();\n\n Case c = new Case(\n Id = req.caseId,\n Customer_Tone__c = req.customerTone,\n Sentiment_Level__c = mapToneToSentiment(req.customerTone),\n Agent_Brief__c = req.agentBrief,\n Agent_Recommendation__c = req.agentRecommendation,\n Escalation_Reason__c = req.escalationReason,\n Last_Agent_Action__c = req.lastAgentAction\n );\n\n update c;\n\n res.success = true;\n res.message = 'Case intelligence updated.';\n responses.add(res);\n }\n\n return responses;\n }\n\n private static String mapToneToSentiment(String tone) {\n if (tone == 'Angry' || tone == 'Frustrated') {\n return 'Red';\n }\n\n if (tone == 'Disappointed' || tone == 'Neutral') {\n return 'Yellow';\n }\n\n if (tone == 'Happy' || tone == 'Satisfied') {\n return 'Green';\n }\n\n return 'Yellow';\n }\n}\n<\/code><\/pre>\n\n\n\nYou might wonder why the sentiment mapping exists in Apex if the agent can classify the tone itself.<\/p>\n\n\n\n
The answer is consistency.<\/p>\n\n\n\n
The agent can classify the emotional tone. The system should own the mapping from tone to UI behavior.<\/p>\n\n\n\n
That way, if the business later decides that \u201cNeutral\u201d should be green instead of yellow, you change deterministic logic, not a prompt.<\/p>\n\n\n\n
Creating The Case Assist Card<\/h2>\n\n\n\n
The Case Assist Card is a Lightning Web Component placed on the Case record page. It reads the Case fields and displays the AI-generated guidance.<\/p>\n\n\n\n
The component has three jobs:<\/p>\n\n\n\n
\n
- Make the customer tone visible.<\/li>\n\n\n\n
- Make the recommendation visible.<\/li>\n\n\n\n
- Make the brief visible.<\/li>\n<\/ol>\n\n\n\n
The color is not decoration. It is operational priority.<\/p>\n\n\n\n
A red card tells the human agent:<\/p>\n\n\n\n
\nSlow down. Acknowledge the customer\u2019s frustration first. Do not respond like this is a routine order update.<\/p>\n<\/blockquote>\n\n\n\n
A yellow card tells the human agent:<\/p>\n\n\n\n
\nThe customer is not fully satisfied. Be careful, concise, and helpful.<\/p>\n<\/blockquote>\n\n\n\n
A green card tells the human agent:<\/p>\n\n\n\n
\nThe customer is satisfied or calm. Continue with a standard helpful tone.<\/p>\n<\/blockquote>\n\n\n\n
LWC HTML<\/h3>\n\n\n\n
<template>\n <lightning-card title=\"Agentforce Case Assist\" icon-name=\"standard:bot\">\n <div class={cardClass}>\n <div class=\"header\">\n <div>\n <p class=\"label\">Customer Tone<\/p>\n <p class=\"tone\">{customerTone}<\/p>\n <\/div>\n\n <div>\n <p class=\"label\">Verification<\/p>\n <p class=\"status\">{verificationStatus}<\/p>\n <\/div>\n <\/div>\n\n <div class=\"section\">\n <p class=\"label\">Recommended Response<\/p>\n <p>{agentRecommendation}<\/p>\n <\/div>\n\n <div class=\"section\">\n <p class=\"label\">Case Brief<\/p>\n <p>{agentBrief}<\/p>\n <\/div>\n\n <template if:true={escalationReason}>\n <div class=\"section\">\n <p class=\"label\">Escalation Reason<\/p>\n <p>{escalationReason}<\/p>\n <\/div>\n <\/template>\n <\/div>\n <\/lightning-card>\n<\/template>\n<\/code><\/pre>\n\n\n\nLWC JavaScript<\/h3>\n\n\n\n
import { LightningElement, api, wire } from 'lwc';\nimport { getRecord } from 'lightning\/uiRecordApi';\n\nimport CUSTOMER_TONE from '@salesforce\/schema\/Case.Customer_Tone__c';\nimport SENTIMENT_LEVEL from '@salesforce\/schema\/Case.Sentiment_Level__c';\nimport AGENT_RECOMMENDATION from '@salesforce\/schema\/Case.Agent_Recommendation__c';\nimport AGENT_BRIEF from '@salesforce\/schema\/Case.Agent_Brief__c';\nimport VERIFICATION_STATUS from '@salesforce\/schema\/Case.Verification_Status__c';\nimport ESCALATION_REASON from '@salesforce\/schema\/Case.Escalation_Reason__c';\n\nconst FIELDS = [\n CUSTOMER_TONE,\n SENTIMENT_LEVEL,\n AGENT_RECOMMENDATION,\n AGENT_BRIEF,\n VERIFICATION_STATUS,\n ESCALATION_REASON\n];\n\nexport default class AgentforceCaseAssistCard extends LightningElement {\n @api recordId;\n\n @wire(getRecord, { recordId: '$recordId', fields: FIELDS })\n caseRecord;\n\n get fieldValues() {\n return this.caseRecord?.data?.fields;\n }\n\n get customerTone() {\n return this.fieldValues?.Customer_Tone__c?.value || 'Not evaluated';\n }\n\n get sentimentLevel() {\n return this.fieldValues?.Sentiment_Level__c?.value || 'Yellow';\n }\n\n get agentRecommendation() {\n return this.fieldValues?.Agent_Recommendation__c?.value || 'No recommendation generated yet.';\n }\n\n get agentBrief() {\n return this.fieldValues?.Agent_Brief__c?.value || 'No case brief generated yet.';\n }\n\n get verificationStatus() {\n return this.fieldValues?.Verification_Status__c?.value || 'Not Started';\n }\n\n get escalationReason() {\n return this.fieldValues?.Escalation_Reason__c?.value;\n }\n\n get cardClass() {\n const sentiment = this.sentimentLevel.toLowerCase();\n\n if (sentiment === 'red') {\n return 'assist-card red';\n }\n\n if (sentiment === 'green') {\n return 'assist-card green';\n }\n\n return 'assist-card yellow';\n }\n}\n<\/code><\/pre>\n\n\n\nLWC CSS<\/h3>\n\n\n\n
.assist-card {\n border-radius: 0.75rem;\n padding: 1rem;\n border-left: 0.5rem solid;\n}\n\n.assist-card.red {\n background: #fff1f1;\n border-left-color: #ba0517;\n}\n\n.assist-card.yellow {\n background: #fff8e6;\n border-left-color: #dd7a01;\n}\n\n.assist-card.green {\n background: #eefaf1;\n border-left-color: #2e844a;\n}\n\n.header {\n display: flex;\n justify-content: space-between;\n gap: 1rem;\n margin-bottom: 1rem;\n}\n\n.section {\n margin-top: 1rem;\n}\n\n.label {\n font-size: 0.75rem;\n text-transform: uppercase;\n color: #5c5c5c;\n font-weight: 700;\n margin-bottom: 0.25rem;\n}\n\n.tone,\n.status {\n font-size: 1rem;\n font-weight: 700;\n}\n<\/code><\/pre>\n\n\n\nLWC Meta XML<\/h3>\n\n\n\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<LightningComponentBundle xmlns=\"http:\/\/soap.sforce.com\/2006\/04\/metadata\">\n <apiVersion>61.0<\/apiVersion>\n <isExposed>true<\/isExposed>\n <targets>\n <target>lightning__RecordPage<\/target>\n <\/targets>\n <targetConfigs>\n <targetConfig targets=\"lightning__RecordPage\">\n <objects>\n <object>Case<\/object>\n <\/objects>\n <\/targetConfig>\n <\/targetConfigs>\n<\/LightningComponentBundle>\n<\/code><\/pre>\n\n\n\nPlace this component on the Case Lightning Record Page used by service agents.<\/p>\n\n\n\n
I usually prefer placing it near the top of the right sidebar. It should be visible without forcing the agent to scroll, but it should not replace the core case details, activity timeline, or related records.<\/p>\n\n\n\n
The End-To-End Flow<\/h2>\n\n\n\n
Let\u2019s walk through a real conversation.<\/p>\n\n\n\n
Scenario 1: Phone Number Available From Voice<\/h3>\n\n\n\n
The customer calls from a known phone number.<\/p>\n\n\n\n
The system finds one matching Contact:<\/p>\n\n\n\n
Phone: +91 98765 43210\nMatched Contact: Priya Shah\n<\/code><\/pre>\n\n\n\nThe agent starts:<\/p>\n\n\n\n
Hi Priya, I can help with your order. For security, please confirm the email address on your account before I share order details.\n<\/code><\/pre>\n\n\n\nPriya provides the email.<\/p>\n\n\n\n
The Verify Customer action returns:<\/p>\n\n\n\n
{\n \"verified\": true,\n \"contactName\": \"Priya Shah\",\n \"status\": \"Verified\"\n}\n<\/code><\/pre>\n\n\n\nNow the agent can answer:<\/p>\n\n\n\n
Thanks, Priya. Your order #10004567 has shipped and is currently in transit. The latest carrier update shows that it reached the Mumbai sorting facility today. The estimated delivery date is June 22.\n<\/code><\/pre>\n\n\n\nNo escalation is needed. The Case can still be updated with a green sentiment if a Case exists:<\/p>\n\n\n\n
Tone: Satisfied\nSentiment: Green\nBrief: Customer asked for order status and was given the current shipment update.\nRecommendation: No human action required unless the customer asks a follow-up question.\n<\/code><\/pre>\n\n\n\nScenario 2: Chat Without Email Or Phone<\/h3>\n\n\n\n
The customer starts chat with:<\/p>\n\n\n\n
Where is my refund? I have been waiting for days.\n<\/code><\/pre>\n\n\n\nNo phone or email is available.<\/p>\n\n\n\n
The agent responds:<\/p>\n\n\n\n
I can help check that. Before I access refund details, please provide the email address and phone number used on the order.\n<\/code><\/pre>\n\n\n\nThe customer provides both.<\/p>\n\n\n\n
Verification succeeds.<\/p>\n\n\n\n
The refund status action finds that the refund is pending because the returned item has not completed warehouse inspection.<\/p>\n\n\n\n
The agent responds:<\/p>\n\n\n\n
Thanks for verifying your details. Your return was received, and the refund is currently waiting for warehouse inspection to complete. Once inspection is completed, the refund will be released to the original payment method.\n<\/code><\/pre>\n\n\n\nThe customer responds:<\/p>\n\n\n\n
That is not acceptable. I was told this would be done already.\n<\/code><\/pre>\n\n\n\nNow the agent should update the Case:<\/p>\n\n\n\n
Tone: Frustrated\nSentiment: Red\nBrief: Customer asked about refund status. Customer was verified. Refund is pending because warehouse inspection is incomplete. Customer is frustrated because they expected the refund to be completed already.\nRecommendation: Apologize for the delay. Acknowledge that the customer was previously told the refund would be completed. Do not ask for email or phone again. Confirm whether warehouse inspection can be expedited or whether a manual refund review is available.\nEscalation Reason: Customer is frustrated about refund delay and wants human review.\n<\/code><\/pre>\n\n\n\nThe human agent opens the Case and immediately sees a red card.<\/p>\n\n\n\n
That is the point of the LWC.<\/p>\n\n\n\n
It turns conversation context into action context.<\/p>\n\n\n\n
Agent Greeting Logic<\/h2>\n\n\n\n
The greeting experience deserves special attention because it shapes customer trust.<\/p>\n\n\n\n
Use this hierarchy:<\/p>\n\n\n\n
If Contact Is Found By Phone<\/h3>\n\n\n\n
Hi {FirstName}, I can help with that. For security, please confirm the email address on your account.\n<\/code><\/pre>\n\n\n\nIf Contact Is Found By Email<\/h3>\n\n\n\n
Hi {FirstName}, I can help with that. For security, please confirm the phone number on your account.\n<\/code><\/pre>\n\n\n\nIf Contact Is Found By Phone And Email<\/h3>\n\n\n\n
Hi {FirstName}, I can help with that.\n<\/code><\/pre>\n\n\n\nThen continue to the relevant task.<\/p>\n\n\n\n
If No Contact Is Found<\/h3>\n\n\n\n
I can help with that. Before I access order or refund details, please provide the email address and phone number used on the order.\n<\/code><\/pre>\n\n\n\nIf Multiple Contacts Are Found<\/h3>\n\n\n\n
I need to verify a few details before accessing order information. Please provide the email address and phone number used on the order.\n<\/code><\/pre>\n\n\n\nAvoid saying:<\/p>\n\n\n\n
I found multiple accounts with that phone number.\n<\/code><\/pre>\n\n\n\nThat reveals too much. The customer does not need to know how many records matched.<\/p>\n\n\n\n
Prompt Template For Case Brief<\/h2>\n\n\n\n
You can create a prompt template for the escalation summary. The exact implementation depends on your org\u2019s AI setup, but the instruction should be structured.<\/p>\n\n\n\n
Example prompt:<\/p>\n\n\n\n
You are generating a service handoff summary for a human support agent.\n\nUse the conversation transcript, verified customer details, order data, refund data, and case context.\n\nReturn the following fields:\n\nCustomer Tone:\nChoose one: Angry, Frustrated, Disappointed, Neutral, Happy, Satisfied.\n\nAgent Brief:\nWrite 2 to 4 sentences. Include what the customer asked, what was verified, what data was found, what the agent already said, and what remains unresolved.\n\nAgent Recommendation:\nWrite specific guidance for the human agent. Include how to respond, what to acknowledge, what to check next, and what not to ask again.\n\nEscalation Reason:\nWrite one sentence explaining why the conversation is being escalated.\n\nRules:\n- Do not invent order, tracking, refund, or policy details.\n- Do not include sensitive payment details.\n- Do not ask the human agent to repeat completed verification.\n- Keep the recommendation operational and concise.\n<\/code><\/pre>\n\n\n\nThis is one of those places where brevity is a feature. A verbose AI summary is only slightly better than no summary. A human agent needs usable guidance, not a transcript rewritten in paragraph form.<\/p>\n\n\n\n
Recommended Agentforce Build Steps<\/h2>\n\n\n\n
Here is the practical build sequence.<\/p>\n\n\n\n
Step 1: Prepare Case Fields<\/h3>\n\n\n\n
Create the Case fields listed earlier.<\/p>\n\n\n\n
Add them to the Case page layout, but do not rely on the layout alone. The LWC is the primary user experience for these fields.<\/p>\n\n\n\n
Step 2: Build Verification Logic<\/h3>\n\n\n\n
Implement verification using Flow or Apex.<\/p>\n\n\n\n
Use Apex if:<\/p>\n\n\n\n
\n
- Matching rules are complex.<\/li>\n\n\n\n
- You need normalization for phone numbers.<\/li>\n\n\n\n
- You need custom logging.<\/li>\n\n\n\n
- You need to query multiple objects.<\/li>\n\n\n\n
- You need deterministic handling for ambiguous matches.<\/li>\n<\/ul>\n\n\n\n
Use Flow if:<\/p>\n\n\n\n
\n
- Matching is straightforward.<\/li>\n\n\n\n
- Admins will own future updates.<\/li>\n\n\n\n
- You want a low-code implementation.<\/li>\n<\/ul>\n\n\n\n
Step 3: Build Order, Tracking, Return, And Refund Actions<\/h3>\n\n\n\n
Create actions with clear boundaries.<\/p>\n\n\n\n
Do not create one giant \u201cCustomer Service Action\u201d that does everything. That makes agent reasoning harder to test and harder to debug.<\/p>\n\n\n\n
Better:<\/p>\n\n\n\n
\n
Verify Customer<\/code><\/li>\n\n\n\nGet Recent Orders<\/code><\/li>\n\n\n\nGet Order Status<\/code><\/li>\n\n\n\nGet Tracking Details<\/code><\/li>\n\n\n\nCheck Return Eligibility<\/code><\/li>\n\n\n\nGet Refund Status<\/code><\/li>\n\n\n\nUpdate Case Intelligence<\/code><\/li>\n<\/ul>\n\n\n\nStep 4: Create The Agentforce Service Agent<\/h3>\n\n\n\n
Create the service agent and define its role:<\/p>\n\n\n\n
You are a customer service agent for ecommerce order support. You help verified customers with order updates, shipment tracking, returns, and refunds. You must verify the customer before sharing private information. When escalation is needed, you prepare a concise case brief and response recommendation for the human support agent.\n<\/code><\/pre>\n\n\n\nStep 5: Create Subagents<\/h3>\n\n\n\n
Create the four subagents:<\/p>\n\n\n\n
\n
- Customer Verification<\/li>\n\n\n\n
- Order Status<\/li>\n\n\n\n
- Returns And Refunds<\/li>\n\n\n\n
- Escalation Summary<\/li>\n<\/ul>\n\n\n\n
Attach the relevant actions to each subagent.<\/p>\n\n\n\n
Step 6: Ground The Agent<\/h3>\n\n\n\n
Ground the agent with:<\/p>\n\n\n\n
\n
- Return policy knowledge articles.<\/li>\n\n\n\n
- Refund timing policy.<\/li>\n\n\n\n
- Shipping delay policy.<\/li>\n\n\n\n
- Order status definitions.<\/li>\n\n\n\n
- Internal escalation policy.<\/li>\n\n\n\n
- Contact, Case, and Order data.<\/li>\n\n\n\n
- External order, carrier, and refund APIs where required.<\/li>\n<\/ul>\n\n\n\n
Separate general policy answers from customer-specific answers.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
\n
- \u201cWhat is your return policy?\u201d can be answered from Knowledge.<\/li>\n\n\n\n
- \u201cIs my order eligible for return?\u201d requires verified customer and order data.<\/li>\n\n\n\n
- \u201cWhere is my refund?\u201d requires verified customer and refund data.<\/li>\n<\/ul>\n\n\n\n
Step 7: Add Guardrails<\/h3>\n\n\n\n
Add instructions that prevent unsafe responses:<\/p>\n\n\n\n
Do not disclose order details before verification.\n\nDo not disclose tracking numbers before verification.\n\nDo not disclose refund status before verification.\n\nDo not expose full delivery addresses.\n\nDo not expose full payment details.\n\nDo not claim a refund has been issued unless refund data confirms it.\n\nDo not promise delivery by a date unless the order or carrier system provides that date.\n\nIf the customer asks for something outside your allowed scope, escalate to a human agent.\n<\/code><\/pre>\n\n\n\nStep 8: Build And Deploy The LWC<\/h3>\n\n\n\n
Deploy the LWC to the Case record page.<\/p>\n\n\n\n
Test the visual states:<\/p>\n\n\n\n
\n
- Red card for Angry or Frustrated.<\/li>\n\n\n\n
- Yellow card for Disappointed or Neutral.<\/li>\n\n\n\n
- Green card for Happy or Satisfied.<\/li>\n<\/ul>\n\n\n\n
Step 9: Connect To Channels<\/h3>\n\n\n\n
Deploy the agent to the relevant channels:<\/p>\n\n\n\n
\n
- Messaging for Web<\/li>\n\n\n\n
- Messaging for In-App<\/li>\n\n\n\n
- Experience Cloud<\/li>\n\n\n\n
- Service Cloud Voice<\/li>\n\n\n\n
- Partner or customer portal<\/li>\n<\/ul>\n\n\n\n
Pass available context into the agent session:<\/p>\n\n\n\n
\n
- Phone number<\/li>\n\n\n\n
- Email<\/li>\n\n\n\n
- Contact Id, if known<\/li>\n\n\n\n
- Case Id, if already created<\/li>\n\n\n\n
- Messaging session Id<\/li>\n\n\n\n
- Voice call Id<\/li>\n<\/ul>\n\n\n\n
Step 10: Monitor And Improve<\/h3>\n\n\n\n
Track:<\/p>\n\n\n\n
\n
- Verification success rate.<\/li>\n\n\n\n
- Escalation rate.<\/li>\n\n\n\n
- Deflection rate.<\/li>\n\n\n\n
- Average handle time after escalation.<\/li>\n\n\n\n
- Human agent edits to AI recommendation.<\/li>\n\n\n\n
- Sentiment distribution.<\/li>\n\n\n\n
- Cases where the agent selected the wrong action.<\/li>\n\n\n\n
- Cases where the LWC recommendation was ignored.<\/li>\n<\/ul>\n\n\n\n
The best feedback loop is not \u201cDid the AI answer?\u201d It is \u201cDid the AI reduce the amount of work needed to resolve the customer\u2019s issue safely?\u201d<\/p>\n\n\n\n
Testing The Agent<\/h2>\n\n\n\n
Testing an Agentforce implementation requires more than happy-path testing.<\/p>\n\n\n\n
Here are the scenarios I would include before production.<\/p>\n\n\n\n
Verification Tests<\/h3>\n\n\n\n
Scenario<\/th> Expected Result<\/th><\/tr><\/thead> Phone available, one Contact found<\/td> Greet by name and ask for email<\/td><\/tr> Email available, one Contact found<\/td> Greet by name and ask for phone<\/td><\/tr> Phone and email match same Contact<\/td> Mark verified<\/td><\/tr> Email and phone do not match<\/td> Do not disclose data<\/td><\/tr> Multiple Contacts match<\/td> Ask for more detail or escalate<\/td><\/tr> Customer refuses verification<\/td> Escalate<\/td><\/tr> Customer provides order number before verification<\/td> Ask for verification first<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Order Tests<\/h3>\n\n\n\n
Scenario<\/th> Expected Result<\/th><\/tr><\/thead> One recent order<\/td> Provide order status<\/td><\/tr> Multiple recent orders<\/td> Ask which order<\/td><\/tr> No orders found<\/td> Explain and escalate if needed<\/td><\/tr> Delayed shipment<\/td> Explain delay using available data<\/td><\/tr> Tracking unavailable<\/td> Do not invent tracking<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Return And Refund Tests<\/h3>\n\n\n\n
Scenario<\/th> Expected Result<\/th><\/tr><\/thead> Return eligible<\/td> Explain next step<\/td><\/tr> Return window expired<\/td> Explain policy and escalation option<\/td><\/tr> Refund issued<\/td> Provide confirmed status<\/td><\/tr> Refund pending<\/td> Explain current stage<\/td><\/tr> Refund data unavailable<\/td> Escalate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Sentiment Tests<\/h3>\n\n\n\n
Customer Message<\/th> Expected Tone<\/th> Sentiment<\/th><\/tr><\/thead> \u201cThis is ridiculous. I want someone now.\u201d<\/td> Angry<\/td> Red<\/td><\/tr> \u201cI\u2019m frustrated. This is the second delay.\u201d<\/td> Frustrated<\/td> Red<\/td><\/tr> \u201cThat\u2019s disappointing.\u201d<\/td> Disappointed<\/td> Yellow<\/td><\/tr> \u201cOkay, thanks for checking.\u201d<\/td> Satisfied<\/td> Green<\/td><\/tr> \u201cGreat, that helps.\u201d<\/td> Happy<\/td> Green<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n LWC Tests<\/h3>\n\n\n\n
Case Field State<\/th> Expected Card<\/th><\/tr><\/thead> Sentiment Level = Red<\/td> Red card<\/td><\/tr> Sentiment Level = Yellow<\/td> Yellow card<\/td><\/tr> Sentiment Level = Green<\/td> Green card<\/td><\/tr> No sentiment yet<\/td> Yellow default<\/td><\/tr> No recommendation yet<\/td> Empty-state message<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Common Implementation Mistakes<\/h2>\n\n\n\n
Mistake 1: Letting The Agent Verify And Answer In One Step<\/h3>\n\n\n\n
Verification should happen before customer-specific answers. Combining verification and order lookup in one action makes the system harder to reason about and harder to audit.<\/p>\n\n\n\n
Mistake 2: Treating Knowledge As Customer Data<\/h3>\n\n\n\n
Knowledge is good for general policy. It is not enough for customer-specific refund status.<\/p>\n\n\n\n
The agent can answer:<\/p>\n\n\n\n
Refunds are generally processed after returned items pass inspection.\n<\/code><\/pre>\n\n\n\nBut it should not answer:<\/p>\n\n\n\n
Your refund will arrive tomorrow.\n<\/code><\/pre>\n\n\n\nUnless a trusted system says so.<\/p>\n\n\n\n
Mistake 3: Writing Long Case Summaries<\/h3>\n\n\n\n
A long summary is another transcript. The Case brief should be short, structured, and operational.<\/p>\n\n\n\n
The human agent should understand three things within seconds:<\/p>\n\n\n\n
\n
- What happened?<\/li>\n\n\n\n
- How does the customer feel?<\/li>\n\n\n\n
- What should I do next?<\/li>\n<\/ol>\n\n\n\n
Mistake 4: Making Color The Only Signal<\/h3>\n\n\n\n
Color helps, but color alone is not enough. The card should also show the tone text: Angry, Frustrated, Disappointed, Neutral, Happy, or Satisfied.<\/p>\n\n\n\n
That supports accessibility and avoids ambiguity.<\/p>\n\n\n\n
Mistake 5: Mapping Sentiment In The Prompt Only<\/h3>\n\n\n\n
Let the agent classify tone, but map tone to card color in deterministic logic.<\/p>\n\n\n\n
Prompts are good for interpretation. Code is better for policy.<\/p>\n\n\n\n
Wrapping Up<\/h2>\n\n\n\n
The interesting part of this Agentforce build is not that the agent can answer order questions. That is useful, but it is not the deeper design point.<\/p>\n\n\n\n
The deeper point is that customer service automation needs memory, judgment, safety, and handoff readiness.<\/p>\n\n\n\n
Verification gives the agent permission to answer.<\/p>\n\n\n\n
Actions give the agent trusted business data.<\/p>\n\n\n\n
Subagents give the work shape.<\/p>\n\n\n\n
Case fields give the conversation a durable home.<\/p>\n\n\n\n
The LWC card gives the human agent immediate context.<\/p>\n\n\n\n
The color gives the agent a visual cue before they type the next response.<\/p>\n\n\n\n
When these pieces are designed together, Agentforce becomes more than a front-line bot. It becomes a participant in the service process. It helps the customer when the path is safe and clear. It helps the human agent when the path needs judgment.<\/p>\n\n\n\n
That is where the implementation starts to feel less like \u201cAI support\u201d and more like a proper service architecture.<\/p>\n\n\n\n
The goal is not to replace the human agent.<\/p>\n\n\n\n
The goal is to make sure that when the human agent enters the conversation, they enter with context, empathy, and the next best action already in front of them.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Welcome! This post is about building an Agentforce Service Agent that can respond to customer questions about order updates, tracking information, returns,…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[34,33],"tags":[],"class_list":["post-180","post","type-post","status-publish","format-standard","hentry","category-agentforce","category-salesforce"],"_links":{"self":[{"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/posts\/180","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/comments?post=180"}],"version-history":[{"count":2,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/posts\/180\/revisions"}],"predecessor-version":[{"id":182,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/posts\/180\/revisions\/182"}],"wp:attachment":[{"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/media?parent=180"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/categories?post=180"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thebnmhub.com\/cgl\/wp-json\/wp\/v2\/tags?post=180"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}