Introduction

The “Last Agent” component in wolkvox Studio allows you to identify the last agent who assisted a customer by querying their interaction history across different channels, such as voice calls, chats, and email.

This component retrieves information about the agent who handled the most recent interaction, the time elapsed since that interaction, the channel used, and the associated skill (agent queue). This information can be used to build flows that prioritize service continuity with the same agent.

For example, if a customer contacts the company again after speaking with an agent, the flow can identify who previously assisted them and attempt to assign the new interaction to that agent, provided they are available and meet the skill's assignment conditions.

The component does not directly perform the transfer or automatically assign the previous agent. Its purpose is to retrieve and store information about the most recent interaction in variables that can subsequently be used by other components in the flow.

The component is located in the “Statistics” group in wolkvox Studio and is available in Voice Flow, Chat Flow, Interaction Flow, and Agentic Engine routing points.

What is the “Last Agent” component used for?

This component allows you to implement different service and routing strategies:

• Service continuity: attempt to have a customer assisted again by the agent who handled their most recent interaction.
• Personalized routing: use the last agent's identifier as a reference to route a call, chat, or interaction.
• Cross-channel continuity: identify the agent who previously assisted the customer, even when the previous interaction occurred through a different channel.
• Reduction of unnecessary transfers: encourage customers to continue their requests with an agent who is already familiar with their needs.
• Customer experience optimization: reduce the need to repeat information when the previous agent is available to resume assistance.
• Recent interaction history lookup: identify the channel, elapsed time, and skill associated with the previous interaction to use this information in flow decisions.

Configuration

To use the “Last Agent” component in a wolkvox Studio flow, follow these steps:

1. Access wolkvox Studio from wolkvox Manager and open the routing point where you want to implement the functionality. In the left component panel, select the “Statistics” group. 
2. Locate the “Last Agent” component and drag it onto the flow design canvas.
3. Connect the component to the other elements in the flow according to the service process you want to configure.
4. Double-click the component with the left mouse button to open its configuration panel. The panel contains four fields with the variables used to store information about the customer's most recent interaction.

Component variables

The component uses the following variables:

These variables allow you to access the information retrieved by the component and use it in other wolkvox Studio elements.

Important: the $skill_last_call variable is informational and does not automatically change the skill to which the new interaction will be routed. The destination must be defined using the corresponding transfer components.

7. Verify the names of the variables you will subsequently use in the flow.
8. Click the “Save” button to save the component configuration.
9. Configure the following components in the flow to use the retrieved variables. For example, you can evaluate whether a previous agent exists and use their identifier in a transfer.
10. Save and compile the flow to apply the changes.

How does the “Last Agent” component work?

When a customer enters a flow containing this component, wolkvox performs a search to identify their most recent interaction and retrieve the information associated with the corresponding agent.

To perform the search, the system uses the available information to identify the customer, such as their identifier, phone number, or interaction sender.

For WhatsApp, the phone number search uses the last seven digits of the number. For email interactions, the session sender is used.

The general process includes the following stages:

1. Customer entry: the customer initiates a new communication through an enabled channel.
2. Interaction history lookup: the component searches the available sources for previous interactions associated with the customer.
3. Identification of the most recent interaction: it compares the records found to determine which corresponds to the most recent interaction according to its search rules.
4. Information storage: it stores the agent identifier, elapsed minutes, channel, and skill in the configured variables.
5. Flow continuation: subsequent components can use these variables to decide how to route the interaction.
6. Assignment: if a transfer with a preferred agent is configured, the router checks whether that agent meets the conditions required to receive the interaction.

Note: if the customer sends a message in a chat that is still open with an agent, the new message continues within that conversation. In this case, the incoming flow is not executed again to search for the last agent.

Which interactions does it query and how does it identify the most recent one?

The component can compare information from different channels:

The component selects the interaction with the lowest calculated minute value. If two records have the same value, the following priority order applies:

1. Voice.
2. Email.
3. Chat.

Important information about emails: the 300-minute adjustment means that, for comparison purposes, an email may be considered five hours more recent than a call or chat that occurred at the same time.

For example, if an email was sent two hours ago, the $minuts_last_call variable may return approximately -180, due to the subtraction of 300 minutes. This result is part of the comparison logic and does not mean that the interaction occurred in the future.

Considerations about the query period

Although the component is used to identify recent interactions and includes 24-hour searches, the effective query period depends on the flow type and the information source being queried.

• In voice flows: calls are queried from the current day's records, and the chats considered are limited to the last 24 hours.
• In chat and interaction flows: the query may retrieve the most recent record from certain sources even if it is more than 24 hours old.

For this reason, if you need to establish a strict time limit for routing a customer back to the same agent, you must consider these differences when designing and validating your flow.

How to use the last agent to transfer an interaction?

Once the component retrieves the information, you can use the $id_last_agent variable to attempt to route the new interaction to the previous agent.

To do this, you must configure a transfer component after “Last Agent”, specifying the destination skill and using the retrieved identifier as the preferred agent when the transfer type supports it.

The process works as follows:

1. The “Last Agent” component retrieves the identifier of the agent who previously assisted the customer.
2. The flow continues to the configured transfer component.
3. The transfer uses $id_last_agent as the preferred agent reference.
4. The router verifies that the agent belongs to the corresponding skill and meets the conditions required to receive the new interaction.
5. If the agent meets the conditions, the interaction is assigned to them.
6. If the agent is unavailable or does not meet the requirements, the system may assign the interaction to another available agent in the same skill.

Important: identifying the last agent does not guarantee that the new interaction will be assigned to the same person. Assignment depends on availability, skill membership, handling capacity, and the configured distribution rules.

Assignment in Chat Flow

In chat flows, the identified agent can be used as the preferred agent when transferring the interaction to a skill.

For the previous agent to receive the new chat, conditions such as the following are evaluated:

• The agent must be in Ready or Talk status, according to the conditions supported by the router.
• The agent must belong to the configured skill and meet its status requirements.
• The agent must have available capacity to receive an additional chat, according to the maximum number of active chats allowed.
• The queue priority rules must allow the assignment.

If the preferred agent does not meet the conditions, the router continues evaluating the other agents in the skill, considering their level and the time elapsed since they last received a conversation.

If no agent is available, the chat remains in the queue until it can be assigned. If the session no longer exists while waiting, it may be recorded as abandoned.

Assignment in Interaction Flow

In interaction flows, such as those used to manage emails or comments on social media posts, the last agent can also be used as the preferred agent for assignment.

The router checks that the agent:

• Is in Ready or Talk status, according to the conditions supported for interactions.
• Belongs to the destination skill and is enabled to receive interactions.
• Has available capacity according to the maximum number of simultaneous interactions allowed.

When these conditions are met, the interaction is assigned to the agent and appears in their interaction inbox.

If the preferred agent is unavailable, the router searches for another agent in the skill who meets the distribution conditions.

If no agent can receive the interaction, it remains on hold until the router evaluates it again.

Assignment in Voice Flow

In voice flows, the last agent's identifier must be explicitly used in the IVR transfer configuration to attempt to route the call back to the same agent.

Keep in mind: the call distributor does not automatically use the $id_last_agent variable simply because it exists in the flow.

If the IVR transfers the call only to a skill, distribution will follow that queue's rules, without guaranteeing preference for the last agent.

Therefore, to implement service continuity in voice, you must use the previous agent's identifier in the corresponding transfer destination or mechanism.

What happens if the customer has no previous interaction?

When the component does not find records of a previous interaction associated with the customer, the $id_last_agent variable remains empty.

In this case, the flow can continue with a standard transfer to the configured skill without specifying a preferred agent.

The interaction will be assigned according to the usual distribution rules and agent availability within that skill.

To handle this scenario, you can use condition evaluation components, such as “If Then” or “Case”, to determine whether the variable contains an identifier before attempting a personalized transfer.

Examples of using the “Last Agent” component

Example 1. Service continuity on WhatsApp

A customer contacts the company through WhatsApp at 9:00 a.m. and is assisted by an agent named Ana, who subsequently closes the conversation.

At 11:00 a.m., the same customer sends another message.

1. The new conversation enters the chat flow.
2. The “Last Agent” component identifies that Ana previously assisted the customer.
3. The $id_last_agent variable stores Ana's identifier.
4. The $channel_last_call variable identifies the whatsapp channel.
5. The $minuts_last_call variable records approximately 120 minutes.
6. The flow transfers the chat to the Support skill, specifying Ana as the preferred agent.

Result: if Ana is available, belongs to the Support skill, and has capacity to receive the chat, the conversation is assigned to her. Otherwise, another available agent in the same skill may receive it.

Example 2. Identifying the previous agent across different channels

A customer was assisted by Sofía through a phone call 30 minutes ago. Previously, Diego had closed a chat conversation with the same customer four hours ago.

When the customer contacts the company again through WhatsApp, the component compares the previous interactions.

Because the call handled by Sofía is more recent than the chat closed by Diego, the component retrieves Sofía's identifier as the last agent.

Result: the flow can use Sofía's identifier as the preferred agent when transferring the new chat. To receive it, Sofía must meet the assignment conditions of the skill to which the conversation is being transferred.

This example demonstrates that the identified last agent does not necessarily correspond to the same channel through which the customer is initiating the new communication.

Example 3. Customer calling back

A customer calls the company again after being assisted by Pedro, an agent from the Sales department, 40 minutes ago.

1. The call enters the IVR configured in wolkvox Studio.
2. The “Last Agent” component queries the customer's interaction history.
3. It identifies Pedro as the last agent.
4. It stores his identifier in $id_last_agent, along with the voice channel and the skill associated with the previous interaction.
5. The flow uses Pedro's identifier in the configured transfer mechanism.

Result: if the transfer correctly uses the retrieved identifier and Pedro meets the handling conditions, he may receive the call again. If the call is transferred only to the Sales skill, it will be distributed according to that queue's standard rules.

Example 4. Continuity in an email interaction

Carlos sends an email to a customer to follow up on a request.

Two hours later, the customer replies to that email.

1. The new interaction enters through the email channel.
2. The component queries information related to previous interactions and sent emails.
3. It identifies Carlos as the agent associated with the most recent interaction.
4. The $id_last_agent variable stores Carlos's identifier.
5. The $channel_last_call variable records email.
6. The flow can transfer the interaction to a skill using Carlos as the preferred agent.

Result: if Carlos belongs to the configured skill and is available to receive interactions, the email is assigned to his inbox. If he does not meet the conditions, another available agent may receive it.

In this scenario, the $skill_last_call variable may remain empty if the retrieved previous interaction corresponds to a sent email. This does not prevent the flow from using the skill configured in the transfer.

Important considerations

• The component retrieves information but does not directly assign the interaction: to route the interaction to the previous agent, you must subsequently use a transfer component.
• The last agent may belong to a different channel: the component compares information from available sources, so the identified agent may have previously handled a call, chat, or email interaction.
• Availability is essential: even if the component correctly identifies the previous agent, that agent must meet the skill conditions to receive a new interaction.
• The previous skill does not automatically change the destination: the $skill_last_call variable provides information about the skill associated with the most recent interaction, but the flow must explicitly define which skill the interaction will be transferred to.
• Chats that remain open retain their assignment: if the customer continues sending messages in an active conversation, those messages continue reaching the agent handling it, without executing the last agent search again.
• Emails use a specific elapsed-time rule: the 300-minute adjustment may generate negative values in $minuts_last_call and change which interaction is considered the most recent.
• The interaction history time range may vary: not all information sources use exactly the same search period, so it is important to validate the behavior when strict time-based rules are required.
• If no previous agent is found: you can configure a standard transfer to the corresponding skill.
• Compatibility with wolkvox Studio web: the query execution is supported for Interaction Flow. In Chat Flow and Voice Flow, the web compiler implementation may proceed to the next component without retrieving the information, leaving the variables empty. Verify the behavior in the Studio version you are using before deploying a flow that depends on these variables to production.

In summary, the “Last Agent” component allows you to identify who previously assisted the customer and make that information available to the flow. When combined with a properly configured transfer and the skill's assignment rules, it facilitates the implementation of service continuity strategies without preventing another available agent from handling the interaction when necessary.