Now Assist for CSM - Complaint Case Intake AI Agent

PriyamvadhaM · yesterday

Automate complaint intake and case creation through a structured, conversational AI Agent built for product and location-based grievances

The Complaint Case Intake AI Agent identifies, validates, and records customer complaints through the Virtual Agent. Rather than relying on agents to manually extract complaint details during intake, this AI Agent conducts a guided conversation with the customer: classifying the complaint as product-related or location-related, verifying entities against system records, checking for duplicate open complaints, capturing related parties, and creating a structured Complaint Case record, all with minimal effort for the customer or the service rep (human agent).

This AI agent is specifically designed to activate only when a customer expresses dissatisfaction or requests formal resolution. It will not respond to general product questions, order status inquiries, positive feedback, or informational requests. This targeting ensures the AI agent remains focused on its core functionality and does not create cases for interactions that aren't complaints.

Key Capabilities

Intelligent complaint detection: Activates only when the customer expresses dissatisfaction or requests formal complaint filing, and ignores general inquiries, order status requests, positive feedback, etc.
Product and location complaint classification: Automatically determines whether the complaint is product-related or location-related from the customer's query, and asks a targeted clarifying question only when the type cannot be inferred.
Entity verification against system records: Validates the product or location mentioned by the customer against Install Base and CMDB records (for products) or the cmn_location table (for locations) before creating the case.
Duplicate complaint detection: Searches for similar open complaints matching the same contact or consumer, and the same product or location, before creating a new case, thereby offering the customer an option to add a follow-up note instead.
Related party identification and capture: Extracts third-party names mentioned in the complaint (staff members, witnesses, 'wrongdoers' etc.), verifies them in the system, assigns the appropriate party type, and links them to the complaint case record.
Structured case creation with full field population: Creates the Complaint Case record with all required fields: complaint type, product or location, short description, description, issue date, expected outcome, primary address, and related parties—in a single agentic workflow.
Customer confirmation before submission: Displays all extracted complaint details to the customer for review and correction before creating the record, ensuring accuracy without requiring agents to intervene.

Tools in the agent: a snapshot

Agent	Type of tool	Tool	Execution mode
Complaint Case Intake AI Agent	Script	Related Parties Identification	Autonomous
		Update fields
		Create new related parties related list
		List related parties type
		Get Logged In user details
		Convert date
		Verify fields
		Create complaint case record
		Verify product and location
	RAG	Search similar complaint cases	Autonomous

Further detail on these tools are in the 'Tools in the agent: Details' section.

Implementation

Install or update the Now Assist for CSM app.
Install the Now Assist for Complaint Case (CSM) app and ensure you're in the Complaint Case AI Agent Collection application scope.
Configure the Virtual Agent topic or flow that invokes this agent.
Verify that Install Base records (for product complaints) and cmn_location records (for location complaints) are populated and accessible to the agent's execution context.
Configure related party types in the sn_customerservice_related_party_configuration table for the sn_complaint_case table to enable accurate party type selection.
Test the agent across both product and location complaint scenarios, including cases with missing fields, future dates, unrecognized products, and duplicate open complaints before production rollout.

Prerequisites

Customer contact or consumer records present for logged-in users
Install Base (sn_install_base) plugin active for product verification (recommended)
Location records populated in cmn_location for location complaint verification
Related party configuration records set up for sn_complaint_case

How It Works

When a customer initiates a conversation through the Virtual Agent and expresses dissatisfaction, the agent executes the following workflow:

Retrieves the logged-in user's account, contact or consumer information, current date, and primary address from the system.
Analyzes the customer's query to classify the complaint as product-related (type 1) or location-related (type 2), asking a targeted clarifying question only when classification cannot be inferred.
Extracts the product or location name from the query and verifies it against system records. If no exact match is found, the agent surfaces similar results for the customer to select from.
Extracts all case fields from the initial query without prompting where possible: short description, issue date, expected outcome, and full description.
Converts and validates the issue date to GlideDateTime format, rejecting future dates and asking for re-entry when needed.
Displays all extracted complaint details to the customer for review and confirmation, with the ability to correct any field before submission.
Validates all field formats and data types before submission using the Verify Fields tool.
Searches for similar open complaints matching the same contact or consumer and the same product or location, offering the customer the option to append a follow-up note instead of creating a duplicate.
Creates the Complaint Case record with all validated fields, including primary address and any custom address provided by the customer.
Identifies third-party names mentioned in the complaint, verifies them in the system, assigns party types, and creates related party records linked to the case.
Confirms the case number to the customer as plain text.

What Makes the Complaint Case Intake AI Agent Different

Unlike a standard Virtual Agent topic that collects a fixed set of fields and creates a record, this agent operates as a fully agentic workflow with conditional branching, entity verification, duplicate detection, and multi-step confirmation. Each stage is governed by explicit instructions that the agent must complete before advancing.

Complaint Detection Logic

The agent uses semantic analysis of the customer's query to determine whether an interaction qualifies as a complaint. It specifically looks for expressions of dissatisfaction, descriptions of negative experiences, or explicit requests to file or report a complaint. It will not activate on general product questions, order status inquiries, positive feedback, or informational requests—preventing unnecessary case creation and preserving complaint case quality.

Complaint Type Classification

Complaint type is always stored as an INTEGER: 1 for product complaints and 2 for location complaints. This is a mandatory field for the sn_complaint_case record and must never be passed as a string. The agent infers the type from the customer's query using contextual reasoning—for example, distinguishing between "my router is broken" (product) and "the air conditioning at my office isn't working" (location) and asks a single targeted clarifying question only when the type cannot be confidently determined.

Note: The agent is designed to be flexible. Some complaints may initially appear product-related but are actually location-related (or vice versa). The agent can adjust the complaint type based on customer feedback during the verification step.

Product and Location Verification

Product verification checks against Install Base tables (sn_install_base_item and sn_install_base_sold_product) first, scoped to the logged-in user's contact, consumer, or account context. If Install Base is not active or returns no results, the agent falls back to a direct query against cmdb_model. For location complaints, the agent queries the cmn_location table directly.

In both cases, if an exact match is not found, the agent surfaces similar results so the customer can select the correct entity rather than failing the interaction. The verified system ID is stored exactly as returned by the tool—this is the value passed to the case record, not a display name.

Note: If your organization does not use Install Base, ensure the cmdb_model table is populated with customer-facing product records for the fallback lookup to function correctly.

Short Description Generation

The agent generates the short description as a focused third-person summary of the main issue only, formatted as a single sentence of no more than 15 words. Location names, dates, and customer-identifying information are intentionally excluded. For example, "Product X malfunctioning after normal use" rather than "Product X at Boston store malfunctioning yesterday." This ensures short descriptions are usable for duplicate detection and case routing without irrelevant noise.

Issue Date Handling

The agent accepts issue dates in any format: natural language ("yesterday", "last Monday"), full text ("November 13th 2025"), or numeric ("11/13/2025")—and converts them to YYYY-MM-DD format before calling the Convert Date tool. The tool validates that the date is not in the future and returns a GlideDateTime-compatible value. Future dates are rejected with an empathetic message asking the customer to re-enter. The agent will not proceed to field validation until a valid past or current date is confirmed.

Customer Confirmation Step

Before creating the case, the agent displays all extracted fields to the customer in a structured format—short description, issue date, expected outcome, description, complaint type, product or location, and primary address. This step is mandatory and cannot be skipped. If the customer requests corrections, the agent updates only the specified fields, re-validates changed fields (date, product, or location) using the appropriate tools, and re-displays the updated information for confirmation. This loop continues until the customer explicitly confirms accuracy.

Note: If the customer provides a custom address not in their profile, the address is appended to the case description field with a "Primary Address Correspondence:" prefix by the Create Record tool. The primary_address field is left empty in this scenario, and an agent is notified to verify and update it.

Duplicate Complaint Detection

After field validation, the agent searches for similar open complaints using the short description as the query. Results are filtered to match the same contact or consumer sys_id AND the same product or location sys_id, and are limited to cases not in Resolved or Closed state. If a matching case is found, the customer is notified of the existing open complaint number (as plain text, never as a hyperlink) and offered the option to add a follow-up work note instead of creating a new case.

Note: This step is designed to be non-blocking. If the search tool fails, times out, or returns an error, the agent skips immediately to case creation rather than halting the workflow. Complaint case creation is always the primary goal.

Related Party Processing

The agent extracts third-party person names from the complaint description—staff members, witnesses, or other involved parties—and explicitly excludes the complainant from this list. Identified names are verified against the customer_contact or csm_consumer table depending on the logged-in user's entity type. For each verified name, the agent infers the appropriate related party type from context and confirms it with the customer, displaying the full list of available types when inference is not possible. Related party records are created in sn_customerservice_related_party linked to the complaint case sys_id.

Note: The agent notifies the customer about related party outcomes in all scenarios - whether parties were added, not found, or partially added. This notification step is mandatory and cannot be skipped.

Tools in the agent: Details

The agent uses eight script-based tools executed autonomously, plus one search retriever:

Get Logged In User Details: Retrieves user sys_id, account or consumer context, current date, primary address, and all accessible locations.
Verify Product and Location: Validates product names against Install Base and CMDB, and location names against cmn_location. Returns exact sys_ids and similar alternatives.
Convert Date: Converts YYYY-MM-DD input to GlideDateTime format and validates that the date is not in the future.
Verify Fields: Validates all field types (sys_id format, integer, string) and checks that the issue date is not in the future before case creation.
Search Similar Complaint Cases: Queries open complaint cases matching the short description, then filters by contact/consumer and product/location sys_ids.
Create Complaint Case Record: Creates the sn_complaint_case record with all validated fields. Automatically appends custom address to the description field when provided.
List Related Parties Type: Returns available related party configuration records for sn_complaint_case scoped to the logged-in user's entity type.
Related Parties Identification: Verifies third-party names against customer_contact or csm_consumer records and returns sys_ids.
Create New Related Parties Related List: Creates records in sn_customerservice_related_party linking the verified party, party type configuration, and complaint case sys_id.
Update Fields: Appends work notes to an existing complaint case when the customer chooses to follow up on an open case rather than create a new one.

Grounding the AI Agent

We recommend that you clone or duplicate the out-of-the-box agent to ground it in the use cases relevant to your organization
Refer to our ServiceNow CRM AI Academy session on the framework and techniques for grounding AI agents in your CRM

Key Best Practices

Ensure Install Base records are scoped to the correct contact, consumer, or account to prevent the agent from surfacing products from other accounts during verification.
Keep location names in cmn_location consistent with how customers are likely to refer to them. Inconsistent naming leads to failed exact matches and requires customers to select from similar results.
Configure related party types in sn_customerservice_related_party_configuration with descriptive names. The agent infers the type from context—vague type names reduce inference accuracy and require more customer interaction.
Do not modify the complaint_type field to accept string values in the case record schema. The agent strictly passes integers and the Verify Fields tool will flag string values as invalid.
Test the duplicate detection step with cases in various states. Only New, WIP, and other non-terminal states should be surfaced as potential duplicates; resolved and closed cases should not block new complaint creation.
Monitor the agent's related party step for cases where customer-provided names are not found in the system. Recurring mismatches may indicate a need to update contact or consumer records, or to broaden the related party identification logic.
Case numbers must always be communicated to customers as plain text. Never display case numbers as hyperlinks or clickable links—this applies to both new cases and existing open cases surfaced during duplicate detection.

Formal Learning

Now Learning: Now Assist for CSM Essentials Path

Measured Success and Outcomes

Outcome	Value to Operations	Key Metric
Faster complaint intake	Eliminates manual agent effort to collect and validate complaint details during intake	Average handle time for complaint intake
Reduced duplicate cases	Surfaces existing open complaints before creating new records, reducing duplicate case volume	% reduction in duplicate complaint cases
Improved case data quality	Validates entities, dates, and field formats before submission, reducing incomplete or inaccurate records	% of complaint cases created with all required fields populated
Related party completeness	Captures third-party involvement at intake rather than through follow-up investigation	% of complaint cases with related parties linked at creation
Customer self-service for complaints	Customers can file structured complaint cases without requiring a live agent interaction	% of complaint cases created via Virtual Agent vs. agent-assisted

Frequently Asked Questions

Where can the agent be accessed? The Complaint Case Intake AI Agent can only be invoked through the Virtual Agent. It is not available as a workspace button or standalone action.
What types of complaints does the agent handle? The agent handles product-based complaints (defective products, performance issues) and location-based complaints (facility maintenance, inventory shortages, staff behavior at a location).
What happens if the agent cannot identify the product or location? If an exact match is not found, the agent surfaces similar results from the system for the customer to select. If no similar results are found, the agent asks the customer to provide the correct name.
Will the agent create a duplicate case if one already exists? No. Before creating a new case, the agent searches for open complaints matching the same contact or consumer and the same product or location. If a match is found, the customer is offered the option to add a follow-up note to the existing case instead.
Can customers provide a custom address not in their profile? Yes. If the customer selects "Enter a different address" during the confirmation step, the agent captures the address and appends it to the case description field. The primary_address field is left empty, and an agent is notified to verify and update it.
What happens if a related party name is not found in the system? The agent notifies the customer that the name could not be verified, offers spelling correction suggestions, and asks whether to proceed without that party. If the customer says no, the workflow ends. If yes, only verified names are added as related parties.
Does the agent ask many clarifying questions? No. The agent is designed to extract all possible information from the customer's initial query before asking any questions. It only requests information that cannot be reasonably determined from what the customer has already provided.
What if the customer provides a future date for the issue? The agent rejects future dates and asks the customer to re-enter a valid past or current date. It will not proceed to case creation until a valid date is provided.