Supervisors needed a real-time control board showing per-agent performance metrics (ASA, AHT, active chats, chats closed today, chat age) and the ability to intervene directly on individual agents' conversations — mirroring Highbot's current supervisor view.
Full supervisor control board implemented. Shows each agent's live KPIs: Average Speed of Answer (ASA), Average Handle Time (AHT), active chat count, closed-today count, and per-conversation age (flagging chats open >1 hour). Supervisors can click into any agent, view their conversation list, and transfer or take over chats without leaving the board.
Shift handoffs required transferring chats one at a time. Supervisors (Jesús, Fernando) needed a way to bulk-reassign all of an agent's active conversations in a single action — critical for shift handoffs and emergency coverage.
Bulk reassignment is now available from the supervisor control board. Supervisors can select an agent and move all of their active chats to another agent in one step. Partial selection (individual chats) is also supported. A confirmation step is shown before executing. Only supervisors/coordinators have access.
Incoming chats were being assigned to agents who were not actively logged in, leaving conversations stuck with no one to respond. Jesús had to use Highbot externally to rescue chats stuck on unavailable agents.
The routing system now only assigns chats to agents who are currently logged in and marked available. If no eligible agent is available, the chat queues or triggers a supervisor notification. Supervisors can also forcibly reassign or take over any chat regardless of current assignee.
The chat list showed a running unread count that never cleared. Agents couldn't tell at a glance which chats had new user messages vs. which had already been handled.
Unread badge resets to zero when an agent opens a conversation. If the user sends a new message after the agent has read the chat, the counter increments correctly. Chats with unread messages are visually highlighted in the list for quick prioritization.
Operations managers needed to reassign any conversation (from any agent) to any other agent — or take it themselves — for real-time workload balancing. Regular agents should not have this capability.
Admin-only reassignment is live. Admins see a "Reassign" action in the conversation view; a searchable agent picker opens, and the conversation moves immediately with a real-time WebSocket update to both the source and target agent's dashboards. Non-admin agents receive a 403 if they attempt this. Existing agent-to-agent transfer (CON-86) is unchanged.
Disabling an agent's account was completely blocking their login. Operations managers couldn't put someone "on pause" from routing without also revoking all their dashboard access.
"Disabled" now means excluded from routing only — disabled agents can still log in, view conversations, and use the dashboard. They simply don't appear in auto-assignment or manual-assignment dropdowns. Re-enabling restores them to the routing pool immediately with no re-login required.
QA Round 3 found 5 conversations ending in status: expired with no close_reason or closed_at set — making them invisible to analytics and the supervisor board's "closed today" counts.
The stale-cleanup path now writes close_reason: "stale_session_auto_end" and closed_at: <now> on every auto-ended conversation. Distinct from the inactivity path's reason so analytics can tell them apart. Forward-fix only (existing orphans not mutated).
When a service had no operator assigned and was >2 hours away, the bot was telling users their operator would be confirmed "máximo 2 horas antes" — a promise the system couldn't guarantee.
The "máximo 2 horas antes" sentence is now suppressed when the service is more than 2 hours away and the operator is still N/A. The bot instead replies: "Aún no tiene operador asignado. Te confirmaremos cuando esté disponible." No SLA promise is made.
QA found 3 conversations dead-ending when users typed inputs like "Mañana 25 de abril" on April 23 — where the relative word and explicit date contradict each other. The bot silently picked one date and returned no results.
When the user provides both a relative word and an explicit date that don't match, the bot now detects the conflict and asks for clarification: "¿Te refieres a mañana (viernes 24 de abril) o al sábado 25 de abril?" Single-form inputs and all prior date-parser fixes are unaffected.
5 QA conversations showed the bot opening with "Operador confirmado para hoy" but then listing services where some operators were N/A — confusing users who expected all operators to be confirmed.
When a response contains a mix of real and unassigned operators, the header is now neutral: "Estos son tus servicios para hoy. Algunos aún están pendientes de operador." Unassigned services show "Operador aún no asignado — te confirmaremos antes del servicio." All-real and all-N/A paths are unchanged.
Jesús Salazar flagged cases where clearly neutral interactions were scored negative by the AI sentiment analysis, skewing dashboard analytics and agent prioritization.
Sentiment scoring prompt and criteria have been reviewed and adjusted to account for the transport service context (e.g., a service in alert status doesn't indicate negative sentiment). Neutral conversations now score correctly.
QA Round 3 found that internal comodín operator names (e.g., "Dider", "Carlos Castro", "Guillermo Castro", "John Alexander Cruz") are still being surfaced to users in chat messages — even after the prior fix for José Martínez (CON-92). These are internal dispatch placeholders that must never be visible to end users.
Fix is in progress. Awaiting the complete and final list of comodín operator names from the ETSG operations team before implementation can be finalized — we need to ensure the fix covers all current placeholders, not just the ones found in QA.
Please share the complete list of all wildcard / comodín operator names currently in use (e.g., Dider Roberto, Carlos Castro, Guillermo Castro, John Alexander Cruz — any others?). This is blocking the fix from shipping.
Decision: Not Discussed
This item was not raised in the May 21 meeting. The complete list of comodín operator names from ETSG is still pending and blocking the fix. See carry-forward section below.
CI now runs automated tests on every pull request (backend, frontend type/lint, frontend tests). However, nothing prevents merging a failing PR to main because the datastudios GitHub org is on the free plan, which does not allow branch protection on private repositories.
We recommend upgrading the GitHub organization to the Team plan (~$12/month for 3 seats). This unlocks branch protection across all private repos and prevents merging red builds to main — a quality gate needed before production go-live. Please confirm approval to proceed.
Before go-live, the team needs to validate that outgoing difusiones (broadcast/bulk WhatsApp messages sent from the platform) are working correctly end-to-end.
Schedule a difusiones test session with the ETSG operations team. We will coordinate the test from our side — please confirm who should be included and the preferred time.
Decision: In Progress — Testing this week
Carlos confirmed difusiones must be ready before go-live (used for weekend service notifications and novedad management). Jesús Salazar will test internally with the call center team on May 21–22. Carlos also asked about registering new Meta templates — Diego to document the registration process.
After the fixes from QA Round 3, the team needs one final structured QA session before production go-live — with a larger group of agents and a longer testing window to surface any remaining edge cases under realistic load.
Coordinate the final QA round: confirm participating agents, availability windows, and target date. We recommend a minimum of 5–7 agents over at least a full business day. This round should be the final gate before full production cutover.
Decision: Superseded by migration timeline
Rather than a dedicated QA round, the team agreed on a direct migration schedule: infrastructure tested by Wed May 27 → migration Wed–Fri May 28–29 → staff training & platform familiarization first week of June → go-live second week of June.
Bring these up for status on the next call (Wed May 27).