Routing Returning Customers to the Same Agent (Contact, Case, and Mobile Methods)
Overview
This tutorial explains how to configure routing so returning customers are connected with the most relevant agent upon each subsequent call or chat. This routing strategy helps maintain continuity between customers and agents and can improve customer satisfaction by reconnecting customers with someone familiar with their issue.
|
Bright Pattern provides a built-in method for routing a returning customer to the agent who handled their most recent interaction. This is done using the scenario variable $(item.continuationUserId). In cases where this method is insufficient, the following three custom routing methods can be used
| |
Downloadable Scenarios
You can download the completed scenarios used in this tutorial. See Method 3 below for scenarios related to that method. Note that these are example scenarios and not intended for use in a production environment.
After downloading:
- Go to Contact Center Administrator > Scenarios.
- Click Import Scenario.
- Upload the file and open the scenario to review the configuration.
Three Methods for Custom Routing
1. Using a contact record (store the last agent who handled them).
2. Using case ownership (route based on the agent assigned to an open or recent case).
3. Routing customers back to the agent who previously contacted them when they call the company number.
Routing Pattern Used in all Three Methods
After determining a target agent ID, your scenario should follow logic similar to this:
1. Check if the target agent is logged in and available.
2. If available: Route interaction to that agent.
3. If not available: Team or skill-based routing (route using a skill that represents the agent's team).
4. If no agents with that skill are available: Apply your normal overflow or fallback routing.
Because Bright Pattern routing is skill-based, fallback to a “team” requires representing teams through skills and skill groups rather than direct team-based routing.
Method 1: Routing Using Contact-Level Agent Linking
In some scenarios, organizations may need more control over how the “previous agent” is determined. For example, you may want to apply a custom time window, or maintain routing history across multiple interaction types.
In these situations, the scenario can store agent information in custom contact fields and use those fields for routing decisions.
The following contact-based method uses activity history to route returning customers to their most recent agent. Use this method when the default Service Continuation behavior is insufficient.
Business Case
When a customer who previously contacted your organization reaches out again, the interaction can be offered to the agent who most recently handled or attempted to handle that customer - provided that interaction occurred within a defined time window. This approach improves continuity, reduces repeat explanations, and creates a more personalized customer experience.
How This Method Works
1. The system identifies the customer using available identifiers (such as phone number or chat identity). Customers can be identified automatically using Bright Pattern’s identification settings, which support matching incoming interactions against the internal contact database or configured external databases.
2. The contact’s activity history is checked to determine the last responsible agent and the time of the qualifying interaction.
3. If the last interaction falls within a configured time window, the system attempts to route the interaction to that agent.
4. If the agent is unavailable, skill-based fallback routing is applied.
Step 1: Create Custom Contact Fields
In Contact Center Administrator > Case & Contact Management > Custom Fields, create fields such as:
- Last Agent ID (text)
- Last Agent Interaction Time (date/time)
These fields store the most recent qualifying agent association for the contact. This information is typically derived from activity records linked to the contact and written by scenario or integration logic.
Step 2: Define Which Activities Update the Last Agent
The “last agent” used for routing should be based on the most recent qualifying activity associated with the contact. Depending on business requirements, qualifying activities may include:
- Inbound interactions handled by an agent
- Manual outbound call attempts made by an agent (whether answered or not)
- Preview campaign call attempts (whether answered or not)
When a qualifying activity occurs, update the contact fields with:
- The handling agent’s ID
- The date and time of the interaction
This makes the most recent qualifying agent association available for use in later routing decisions.
Scenario Logic for Contact-Based Agent Routing
The following scenario demonstrates one possible implementation. Production environments may require additional exits and error handling. In your inbound scenario, routing should follow this decision process:
1. Attempt to identify the customer using their phone number or other available identifiers.
In most scenarios, Bright Pattern automatically identifies contacts using built-in authentication methods such as ANI for voice calls or messenger identifiers for chat channels.
If additional or custom identification logic is required, the Identify Contact scenario block can be used to search for a contact using a specific identifier such as phone number, messenger ID, or a custom contact field.
Note that if the Identify Contact block is used anywhere in the scenario, automatic contact identification is disabled for that scenario. In that case, the contact must be explicitly identified on all scenario paths using this block.
2. If no contact is found (this branch is on the "not found" exit of the Identify Contact block):
- Route the customer to any agent using standard routing. After the interaction, capture the identifier of the agent who handled the interaction (
$(user.id)), along with the interaction time ($(system.dateTime)) - Use a Create Object block to create a new Contact in the database. Populate with:
- Object type: Contact
- Contact fields: Populate any available customer details, such as first name, last name, phone number, and email address
- Last Agent ID: (
$(user.id)) - Last Agent Interaction time: (
$(system.dateTime))
3. If a contact is found but no last agent information is stored:
- Use an If scenario block to check whether last agent information is associated with the contact
- If no last agent information is stored, handle the interaction using normal routing
- After the interaction, capture the identifier of the agent who handled the interaction (
$(user.id)), along with the interaction time ($(system.dateTime)). - Use an Update Object block to write those values to the contact record in the database. Populate with the following properties:
- Object type: Contact
- Record ID: The ID of the existing contact record, typically returned by the previous Identify Contact block
- Last Agent ID: (
$(user.id)) - Last Agent Interaction Time: (
$(system.dateTime))
4. If a contact is found and last agent information exists:
- Check whether the interaction falls within the allowed time window (see step 3, below)
- If not, continue with normal routing
- If yes, attempt to route to the stored agent
Route to the stored agent by using the Find Agent and Connect Call blocks. Configure Agent Skills Required in the Find Agent block to select the specific agent wait condition, then search for $(contact.LastAgentID). See route to a specific agent for more information.
Step 3: Apply a Time Window for Agent Reconnect
Agent-specific routing should occur only if the previous interaction is recent enough to remain relevant.
In your inbound scenario:
1. Retrieve Last Agent Interaction Time from the contact using the variable $(contact.LastInteractionTime)
2. Compare it to the current date/time using the variable $(system.dateTime)
3. If the interaction is older than your defined threshold (for example, 24 hours), skip agent-specific routing and proceed with normal routing logic. This can be done using an If block with two branches:
- If the previous interaction falls within the allowed time window:
- Route the customer to the stored agent
- If the previous interaction falls outside the allowed time window:
- Continue with normal routing so the customer can be connected to any available agent
In the screenshots below, the If block is configured to compare the current time with the time of the customer's last interaction using the variables $(system.dateTime) and $(contact.LastInteractionTime). If the elapsed time is less than the defined threshold (i.e. 24 hours), the scenario continues with last-agent routing. Otherwise, the interaction follows the standard routing path.
Step 4: Route to the Last Agent
If a last agent ID is present and the interaction is within the allowed interval, route to the stored agent using the "specific agent" wait condition of the Find Agent block.
Step 5: Configure Fallback Routing
Team membership is not available as a routing condition in the Find Agent block. Instead, if the preferred agent is not available, the scenario should continue to one of several fallback options.
First, configure a Find Agent block to search for the stored agent by User ID and set the Interval property to define how long the scenario should wait for that specific agent to become available. If the agent is not available within that interval, use the corresponding conditional exit to continue with your selected fallback routing method. You can then choose any of the following fallback options:
Route using a skill that represents the agent’s team
Create one skill per team, assign the appropriate team skill to each agent, and route the interaction to that skill in the scenario. See assigning skills to agents for more information. This allows the interaction to be offered to agents in the same operational group, although it is implemented through skills rather than true team-based routing.
Route to a general queue or apply standard routing logic
If agent-specific routing is not required after the preferred agent is unavailable, the scenario can continue to the normal service, queue, or overflow path.
Identification Requirements and Limitations
Agent reconnect routing works only when the system can confidently associate the interaction with a single contact record.
If multiple contacts share the same phone number or other identifier, the system may not be able to determine the last responsible agent, and the interaction will follow standard routing instead.
Maintaining clean, deduplicated contact data improves the effectiveness of this routing method.
If no contact match is found, a new contact can be created, but agent reconnect routing will only be possible if agent information is stored to the contact associated with the customer.
Method 2: Routing Using Case Ownership
This method routes customers based on the agent assigned to an open or recent case associated with the contact. If a customer has an ongoing support case and contacts the center again, the interaction can be routed directly to the agent responsible for that case.
Step 1: Identify the Contact
As in Method 1, match the incoming interaction to an existing contact using phone number or other identifier.
Step 2: Search for Relevant Cases
Using your CRM or case management integration:
1. Search for open or recent cases associated with the contact. For example, after the contact has been identified, a Bright Pattern Search Object block can be used to search the internal database for Case records where Reporter ID matches the contact’s ID and Status equals "Open". The block can then return the relevant case fields, such as the assigned agent, into a recordset for use in subsequent routing logic.
For example, to search for open cases associated with the identified contact:
- Add a Bright Pattern Search Object block.
- Set Object type to Case.
- Add search conditions such as:
- Reporter ID =
$(contact.id) - Status =
Open
- Reporter ID =
- Add Return fields for the values you want to use later, such as:
- case ID
- assigned agent ID or owner field
- status
- Set a Recordset name, for example:
openCases
2. Select the most relevant case (for example, the most recently updated open case). Return the Assigned Agent ID field in the Search Object block’s Return fields, then use that returned value as the target agent ID.
This agent becomes the target for initial routing.
Step 3: Apply Standard Routing Logic
Use an If block to check if the case already has an assigned agent.
1. If an assigned agent is found:
- Attempt to route the interaction directly to that agent
2. If the assigned agent is not available:
- Configure fallback routing to route to the agent's team or a general queue. See Method 1, step 5 for more details.
3. If no suitable case or assigned agent is found:
- Continue with your default routing logic
Method 3: Routing Customers Back to the Agent Who Previously Contacted Them When They Call the Company Number
This method is often used when field technicians place outbound calls from mobile devices through the company’s phone system, so the company’s main number appears as the caller ID. If a customer misses the call and later calls the main number back, the scenario can identify the previous agent and route the return call directly to that technician instead of sending it to a general queue. This method uses two different scenarios- one to store the technician's ID on the contact record, and a second that uses that stored ID to route the return call back to the same technician.
Downloadable Scenarios
Step 1: Store the Field Technician’s Information When the Outbound Call Is Made
Before return-call routing can work, the system must save the identity of the technician who placed the outbound call.
1. Ensure the called customer is associated with a contact record in the internal database.
2. When the outbound call is placed through the company phone system, capture the technician’s user ID.
3. Store that user ID on the contact record in a custom contact field such as Last Agent ID
5. Use a Create Object block if no contact record exists yet, or an Update Object block if the contact already exists. Configure the following properties:
- Object type: Contact
- Record ID: the identified contact record ID, if updating an existing contact
- Last Agent ID:
$(user.id) - Last Agent Interaction Time:
$(system.dateTime)
Step 2: Identify the Customer on the Return Call
When the customer later calls the company’s main number:
1. Use the caller’s phone number to identify the contact record.
2. Retrieve the stored Last Agent ID value from that contact.
3. Optional: Retrieve the stored Last Agent Interaction Time value if you want to enforce a recency window.
4. If no contact is found, or no stored technician ID exists, continue with normal routing.
Step 3: Attempt Routing to the Technician
1. Use a Find Agent block to search for the stored technician by User ID.
2. Configure the block to wait for that specific agent for the desired interval.
3. If the technician becomes available, route the return call to that technician.
Step 4: Configure Fallback Routing
1. If the technician is not available, continue to a fallback path. Route using a skill that represents the appropriate field support group or continue with the normal queue/overflow path.
2. If no matching fallback agents are available, continue with standard routing.
Summary
All three methods use the same core routing approach. The difference is where the system gets the “correct” agent from:
| Method | Agent Source |
|---|---|
| Contact-level linking | Stored in contact custom fields |
| Case routing | Assigned agent on an open or recent case |
| Field/mobile scenario | Agent associated with the contact after an outbound field call |
By choosing the method that matches your workflow, you can create a more personalized and efficient customer experience while still maintaining reliable fallback routing when specific agents are unavailable.