Un número compartido necesita una forma clara de trabajar
Define un responsable, incluso cuando colaboran varias personas
Reparte por el motivo del contacto y conserva una salida para las excepciones
Transfiere el contexto, no solo el chat
Mantén las reglas del canal dentro del proceso del equipo
Prueba un recorrido completo antes de ampliar el uso
Lleva a la demostración un caso que tu equipo pueda evaluar
WhatsApp multiagente describe una forma de atender un mismo canal con varias personas. El problema que debe resolver es concreto: saber quién responde, qué asunto sigue pendiente y cómo continúa la conversación cuando cambia el responsable. Abrir el mismo chat en más dispositivos no define esas reglas. Antes de elegir una herramienta, escribe el proceso que quieres que siga el equipo.
Imagina una tienda en línea con consultas sobre disponibilidad, entregas y cambios. Es un ejemplo, no un caso de cliente de imBee. Una persona puede contestar una pregunta sobre un producto, mientras otra necesita consultar un pedido. Si ambas responden sin acordar quién lleva el caso, el cliente puede recibir instrucciones distintas. El objetivo de una bandeja compartida es dar al equipo una forma de coordinar ese trabajo.
Conviene separar tres capas. La aplicación WhatsApp Business es un producto de Meta. WhatsApp Business Platform ofrece las API de mensajería. Una plataforma de atención añade la organización del equipo alrededor del canal. Según su página de producto, imBee ofrece esa capa de bandeja compartida. El alcance depende del plan y de la configuración que se acuerden.
Número y cuenta Responsable y contexto Decisión y siguiente paso
| Capa | Pregunta que debe responder | Qué comprobar |
|---|---|---|
| Canal de WhatsApp | ¿Con qué número y cuenta hablamos? | Titularidad, acceso y ruta de conexión |
| Bandeja del equipo | ¿Quién lleva esta conversación? | Asignación, estado y contexto disponible |
| Proceso de atención | ¿Qué debemos hacer después? | Responsabilidad, derivación y criterio de cierre |
No elijas la API solo por una cifra de empleados. Revisa cómo se reparten los casos, si hay cambios de turno y qué información necesita cada persona. La opción más sencilla que permite controlar tu proceso es un mejor punto de partida que una lista de funciones que nadie ha probado.
Empieza con una regla fácil de recordar: cada conversación abierta tiene un responsable visible. Esa persona puede pedir ayuda, pero sigue encargada de explicar al cliente el siguiente paso hasta que otra persona acepte la transferencia. Ser responsable no significa resolver todo en solitario. Significa que el caso no queda sin dueño entre dos equipos.
En el ejemplo de la tienda, el equipo de atención puede necesitar una confirmación del almacén. El almacén aporta la información y el responsable de atención responde al cliente. Si hace falta pasar el caso a otra persona, la transferencia debe indicar qué se sabe, qué falta comprobar y quién tiene que actuar. No basta con escribir «revísalo» y dejar el chat abierto.
Define estos acuerdos antes del piloto:
La bandeja omnicanal de imBee describe asignación, colaboración y contexto de conversación. Pide que te muestren el recorrido que necesitas con tu configuración. Una demostración útil permite distinguir la respuesta al cliente de una nota interna y comprobar qué ve cada participante.
También conviene acordar una regla para las ausencias. Si el responsable deja de estar disponible, alguien debe revisar el caso y reasignarlo. El cliente no debería tener que repetir su consulta porque el turno anterior acabó. El acuerdo operativo importa tanto como el botón que cambia una asignación.
Una regla de reparto debe representar una decisión real del negocio. Puedes separar preguntas comerciales, consultas sobre pedidos y solicitudes de cambio. En una operación pequeña, quizá una sola cola con un responsable sea suficiente. Añade rutas cuando una diferencia de trabajo justifique el cambio, no para imitar la estructura de una empresa más grande.
Para el ejemplo de la tienda, escribe primero el recorrido en papel. Una pregunta de disponibilidad va a atención comercial. Un pedido que necesita investigación pasa al equipo autorizado para consultarlo. Una solicitud poco clara vuelve a una persona que decide dónde enviarla. Estas son propuestas de proceso, no reglas que ya estén activadas en una cuenta.
El motivo conocido tiene un destino. La excepción conserva un responsable.
Una regla útil incluye:
El reparto por turnos o entre varias personas puede ayudar a distribuir trabajo, pero no demuestra por sí solo que cada caso llegue al especialista correcto. Una conversación corta sobre un horario y una incidencia que exige revisar un pedido no requieren el mismo esfuerzo. Revisa las excepciones junto con la carga de trabajo.
La página de Chatbot & Automation describe asignaciones basadas en reglas. Eso no significa que cualquier condición de tu negocio funcione sin preparación. Confirma los datos disponibles, la regla que se configurará y la salida cuando falle. Mantén una opción humana para preguntas que el flujo no pueda resolver.
Una transferencia debe permitir continuar sin reconstruir toda la conversación. Utiliza una nota breve con el motivo, la comprobación realizada, el compromiso comunicado y la acción pendiente. Escribe solo lo necesario para que la persona siguiente pueda trabajar. El historial ayuda, pero no sustituye una explicación clara de lo que falta.
Este ejemplo es ficticio: «El cliente pide cambiar la talla de su pedido. Se ha confirmado qué artículo recibió. Falta comprobar disponibilidad y aplicar nuestra política de cambios. Atención debe responder después de la confirmación del almacén». La nota no promete una devolución, una reserva ni una modificación automática. Separa lo confirmado de lo que todavía requiere una decisión.
Comprueba además dónde se escribe la nota. Una instrucción para un compañero no debe enviarse al cliente por error. En una prueba, pide a dos participantes que diferencien la comunicación interna y la respuesta externa. Después, cambia de responsable y revisa que la persona siguiente pueda identificar el paso pendiente.
Si necesitas datos del CRM o de la tienda, define el campo y la acción que deben viajar con el caso. «Integrar el CRM» es demasiado amplio. Una pregunta más útil sería: «¿Puede la persona autorizada consultar el estado de este pedido y comprobar cuándo se actualizó?». La página de integraciones de imBee describe conexiones, pero cada conector, permiso y flujo debe verificarse por separado.
No confundas consultar información con modificarla. Ver un pedido no demuestra que se pueda cancelar o reembolsar desde la conversación. Si una acción requiere otro sistema o una aprobación, conserva ese paso en el procedimiento y en la explicación que recibe el cliente.
Organizar varios agentes no cambia las reglas de WhatsApp. La política vigente distingue la ventana de atención de 24 horas y el uso de plantillas aprobadas fuera de ella. Esa ventana regula qué tipo de mensaje se puede enviar; no debe presentarse como una promesa de coste cero.
Antes de iniciar mensajes, revisa el permiso del destinatario y el propósito de la comunicación. La descripción oficial de funciones de la plataforma diferencia mensajes iniciados por el cliente y por la empresa. Una conversación sobre un pedido no convierte automáticamente a la persona en destinataria de cualquier promoción.
Puedes mantener el control con decisiones pequeñas: una finalidad por mensaje, un responsable para revisar el texto y una forma de atender las solicitudes de baja. Cuando interviene una automatización, muestra una salida clara hacia una persona. Comprueba ese recorrido en la prueba; no basta con que aparezca en una presentación.
Define también qué información necesita cada función. El equipo comercial puede necesitar contexto distinto del equipo que gestiona una incidencia. Evita copiar datos innecesarios en notas, archivos o herramientas externas. Usa ejemplos ficticios durante la demostración y acuerda después los permisos, la conservación y las condiciones de acceso para la operación real.
Un supervisor debe poder explicar por qué el equipo inicia una conversación y quién puede continuarla. Ese criterio evita que una bandeja compartida se convierta en una lista de contactos usada sin un propósito claro. No es una declaración de cumplimiento legal universal; es una forma de revisar el proceso antes de ponerlo en marcha.
El primer piloto puede centrarse en un motivo de contacto, como consultar la disponibilidad de un producto. Elige un recorrido que el equipo conozca y que permita comprobar recepción, asignación, colaboración y cierre. Añade después una excepción que obligue a intervenir a otra persona. La prueba debe mostrar cómo se trabaja cuando la pregunta no encaja en el camino ideal.
Usa una cuenta y un destinatario autorizados para la prueba. Escribe por adelantado qué debe ocurrir y conserva el resultado observado. No registres «funciona» como única evidencia. Anota quién recibió el caso, qué información apareció, cómo se transfirió y qué tuvo que hacer el cliente para continuar.
Resultado esperado Resultado observado Pendiente de corregir
| Prueba propuesta | Resultado esperado | Evidencia que conviene conservar |
|---|---|---|
| Consulta nueva | Un responsable identificado | Asignación y estado observados |
| Consulta sin motivo claro | Revisión humana | Destino real de la excepción |
| Colaboración interna | Ayuda sin mensaje accidental al cliente | Nota interna y respuesta diferenciadas |
| Cambio de turno | La siguiente persona puede continuar | Nota de transferencia y acción pendiente |
| Dato de otro sistema | Se consulta el campo acordado | Campo, permiso y actualización comprobados |
| Petición de hablar con alguien | Una persona recibe el caso | Recorrido completo de la transferencia |
Revisa las diferencias entre lo esperado y lo observado. Una asignación incorrecta puede requerir cambiar la regla. Una nota poco clara puede requerir mejorar el procedimiento. No todos los fallos se arreglan añadiendo otra automatización. A veces la solución es decidir quién hace una comprobación que antes nadie había asumido.
Cuando midas el piloto, define cada indicador. El tiempo hasta la primera respuesta, el tiempo de resolución y las transferencias repetidas responden a preguntas distintas. No uses una respuesta automática de recepción como prueba de que una incidencia se resolvió. Tampoco atribuyas a la plataforma una mejora que no hayas observado en tus propios casos.
Prepara una página con el motivo de contacto, el número que deseas usar, los participantes y la información necesaria. Incluye una consulta normal, una excepción y un cambio de responsable. Esa página da al equipo una base concreta para comparar herramientas sin depender de una demostración genérica.
Si el número ya se usa en una aplicación o con otro proveedor, confirma la ruta de conexión antes de modificarlo. El alta de una cuenta, la conexión de un número y la organización de los agentes son decisiones distintas. No borres una cuenta ni anuncies una fecha de cambio hasta que la ruta aplicable y sus efectos estén confirmados.
Pide a imBee que muestre recepción, reparto, nota interna, transferencia y cierre con ese caso. Confirma las funciones disponibles en el plan, el conector necesario y la atención que recibirás durante la puesta en marcha. La decisión debe basarse en lo que el equipo puede comprobar. Habla con imBee sobre tu recorrido de atención.
No. Multiagente describe cómo varias personas atienden un canal. La API es la conexión de mensajería de la plataforma de Meta. La bandeja y los procedimientos añaden la asignación, la colaboración y el control del trabajo. Comprueba las tres partes.
Cuando cuesta saber quién responde, se pierden tareas al cambiar de turno o las personas necesitan colaborar sobre un caso. No existe una cifra universal de empleados que obligue a cambiar. Parte del proceso que necesitas controlar y lleva una consulta realista a la demostración para comprobar ese recorrido.
La colaboración puede ser necesaria, pero conviene mantener un responsable visible. Comprueba cómo se pide ayuda, qué ve cada participante y cómo se diferencia una nota interna de la respuesta que recibe el cliente. Acuerda además quién confirma la información antes de enviarla y quién retoma el caso después.
Define un destino de revisión humana. Prueba una consulta ambigua y comprueba quién la recibe. No consideres completa una regla que solo funciona cuando el cliente escribe exactamente la frase prevista. Revisa también qué ocurre si la persona encargada de esa excepción no está disponible.
No necesariamente. Puedes empezar por controlar recepción, responsabilidad y transferencia. Añade automatización cuando exista una tarea concreta y una salida para las excepciones. El flujo más sencillo que resuelve el problema es un buen primer piloto. Después decide qué paso repetitivo conviene automatizar a partir de lo observado.
No lo supongas. Consultar datos y modificarlos son capacidades diferentes. Define el conector, el campo, el permiso y la acción requerida. Pide una prueba del recorrido que necesitas antes de incluirlo en tu procedimiento. Incluye el comportamiento cuando el sistema no responde o la información no aparece.
Solicita una propuesta para tu número, equipo y recorrido. Confirma el plan, las funciones configuradas y las condiciones de mensajería de la cuenta. Este artículo no modifica precios ni fija una cuota de agentes. Lleva el mismo caso de prueba a cada evaluación para comparar el alcance propuesto.
En una demostración del producto, hablaremos de tus canales, tu equipo y tus necesidades de transferencia de conversaciones.
