Symptom or Need

The client reports that some agents do not appear in login or status change reports, despite having successfully logged into the Wolkvox Agent tool and having managed chat interactions.

The novelty arises especially when the agent:

• Log in to Wolkvox Agent.
• It remains in a single state throughout the day.
• It does not perform auxiliary state changes and logs off and closes the tool without transitioning to another state.
• As a result, the agent is not correctly reflected in the reporting associated with states or logins.

Context / Scenarios

Scenarios in which the novelty occurs

1. The agent logs in.
2. It remains in Ready state.
3. He only responds to chats.
4. At no point during the connection is the state manually changed.
5. Close AgentBox or end the day without making any status changes.
6. The agent remains in the call skill throughout the entire shift without receiving any interaction and without making manual status changes.

In this case:

• The initial state is not fully printed to the database.
• There is no subsequent transition that closes the active state.
• The agent may not appear in login reports or statuses.

The platform records states in the database only when a transition to a new state occurs.

Correct functional scenario

1. The agent logs in.
2. Switch to Ready state.
3. Receives a call and automatically switches to Talk.
4. The call ends and switches to ACW.
5. Then switch back to Ready.

In this flow, all states are correctly recorded in the database because each one is "closed" by the next state change.

Answer / Solution

This case does not correspond to a platform failure nor does it require escalation, as the behavior is as expected due to the tool's state logging logic.

The recommendation for the client is:

• Ensure that agents perform at least one auxiliary status change during the workday.
• Before logging out, switch to a different state (Break, Training, Ready, etc.) to force the closure and logging of the previous state.
• This ensures that the information is correctly stored in the database and visible in reports.

Possible Causes

• The agent remained in a single state throughout the entire day.
• There were no subsequent state transitions.
• The AgentBox was closed directly from the active state.
• Operation focused solely on chat channels, where there are no automatic changes as happens in voice (Talk / ACW).
• The initial state was never "closed" by another state.

Considerations

• In voice campaigns, this novelty is not usually evident because calls generate automatic state changes.
• The situation is more frequent in chat-only operations.
• Reporting depends on the correct persistence of transition events.
• The system records the previous state when a new state change occurs.

Example : Ready → Talk → Ready is registered.

Talk → ACW → Talk is registered.

ACW → Ready → ACW is registered.

• If there is no next state, the current state remains open and may not be fully reflected in the reports.

Recommendations

• Instruct agents to make status changes during the day when they are only operating chats.
• Before logging off, manually switch to another auxiliary state.
• Socialize this behavior with supervisors and operational staff.
• Validate end-of-day closing procedures to avoid inconsistencies in reporting.
• Do not escalate the case as a platform incident, as it corresponds to the expected functioning of the system.