En una bandeja compartida de Front, el dueño es la persona asignada, y solo hay una a la vez. Todos los demás que comentan, son mencionados con @ o se suscriben son ayudantes. La trampa es que la propiedad cambia sin que nadie haga clic en Assign: responder a una conversación sin asignar te convierte en el dueño, ponerte en Out of office devuelve tus conversaciones a la cola cuando el cliente responde, y un ajuste de inactividad puede quitar la asignación a hilos silenciosos. Decide esos tres ajustes a propósito, elige load balancing en vez de round robin si tu equipo alguna vez se queda completamente desconectado, y la pregunta "¿quién tiene esta?" desaparece. Si quieres que cada conversación nueva llegue con un siguiente paso ya redactado, eesel trabaja como compañero de IA dentro de Front y puede recibir conversaciones asignadas como cualquier otra persona.
¿Qué significa "propiedad" en una bandeja compartida de Front?
En Front, la propiedad es la asignación. El propio centro de ayuda de Front lo dice sin rodeos: asignar conversaciones da "every message a clear owner", y "a conversation can only be assigned to one user at a time." Una vez asignada, aparece en la sección Assigned to me de esa persona.
Yo construyo agentes de IA que trabajan dentro de helpdesks como Front, así que paso mucho tiempo leyendo cómo decide cada herramienta de bandeja compartida quién es responsable de una conversación. La respuesta de Front es más clara que la mayoría: un asignado, más tantos ayudantes como quieras. Los ayudantes son personas que:
- Comentan en el hilo (los comentarios solo los ve tu equipo).
- Son mencionadas con @, lo que mete la conversación en su vista.
- Se suscriben, lo que mueve la conversación a su sección Subscribed cuando hay actividad nueva.
Esta separación importa porque, según las reglas de suscripción de Front, el asignado no puede darse de baja: "you must unassign or reassign the conversation first." Los ayudantes pueden salir cuando quieran. El dueño no puede marcharse en silencio.
Esa es la teoría. En la práctica, el motivo por el que los equipos buscan este tema es que una conversación que creían asignada resulta no estarlo. Aquí está el porqué.
¿Qué cambia al dueño sin que nadie haga clic en Assign?
Cinco cosas mueven o quitan al dueño en una bandeja compartida de Front, y solo una de ellas es una persona reasignando a propósito.
1. La primera persona en responder se convierte en el dueño
Los canales de Front tienen un ajuste llamado Assign conversations on first reply. Con él activado, "any time a teammate starts a new conversation or replies to an unassigned conversation from a shared channel, the conversation will automatically be assigned to that teammate." Está activado por defecto.
Es un buen valor por defecto para equipos pequeños. También es la razón por la que, en una bandeja entre equipos, un comercial que responde con un rápido "let me check with support" termina siendo dueño de una disputa de facturación durante tres semanas. Dos detalles de la documentación de Front: solo se activa en conversaciones sin asignar, y solo funciona si envías desde Front, no desde fuera.
2. Out of office devuelve las conversaciones a la cola
Cuando un compañero se pone en Out of office, "any replies they receive to conversations that originated in a shared inbox will automatically get unassigned." Las conversaciones que no reciben una respuesta nueva se quedan asignadas a esa persona. Las asignaciones automáticas se pausan, pero un compañero aún puede asignarlas a mano.
Busy es distinto. Según la guía de estado de compañeros, Busy pausa las asignaciones nuevas por regla, pero las conversaciones siguen asignadas cuando hay actividad nueva. Así que la regla práctica para cualquier traspaso del equipo de soporte es: Busy para la pausa de comer, Out of office cuando terminas el día. Gris, que significa sin dispositivo conectado, no pausa nada, así que un compañero que cierra el portátil sin cambiar su estado puede seguir recibiendo asignaciones por regla.
3. El temporizador de inactividad quita la asignación a conversaciones silenciosas
Las bandejas compartidas tienen un ajuste de bandeja llamado Unassign conversation if inactive for. Fijas un periodo, y cuando una conversación que ha estado en silencio más tiempo que ese periodo recibe un mensaje nuevo, Front le quita la asignación. También puedes elegir Never. Si los ajustes de bump de tu empresa cuentan también las respuestas salientes, estas también lo activan; si no, solo lo hacen las entrantes, según las notas de Front sobre bump.
Esto sorprende a mucha gente, y puede descolocar tu seguimiento de SLA, porque no pasa nada en el momento en que se agota el temporizador. El dueño solo desaparece cuando el cliente por fin vuelve a escribir.
4. Otra persona la archiva
Archivar parece una acción compartida, pero Front rastrea las vistas por separado. De la guía de estado de conversación: "If a teammate who is not the assignee changes a conversation's status from a shared inbox, then the conversation will stay open in the assignee's Assigned to me section." El dueño la conserva en su lista incluso después de que un colega limpie la vista compartida. Es una red de seguridad, no un fallo, pero explica por qué los dueños ven cosas que el resto del equipo cree terminadas.
5. Una regla o un administrador la reasigna
El caso a propósito. Como la asignación por grupo en otros helpdesks, las reglas pueden asignar, quitar la asignación y reasignar, y las reglas de load balancing pueden reasignar una conversación que quedó libre porque su dueño se puso Out of office o Busy, siempre que la regla tenga un disparador Assignee is removed (documentación de load balancing).
El único interruptor que anula casi todo esto es el ajuste de bandeja compartida Keep assignments when teammate is out of office or busy. Al activarlo, las conversaciones nuevas aún pueden asignarse a compañeros no disponibles, las existentes se mantienen con actividad nueva, y el ajuste de quitar asignación por inactividad se desactiva.
¿Qué pasa con la propiedad en cada situación?
Aquí está la misma lógica como consulta rápida. Elige la situación que intentas explicarle a tu equipo.
¿Cómo ayudan los ayudantes sin quedarse con la propiedad?
Los equipos de Front más limpios separan "esto es mío" de "solo estoy ayudando aquí", y Front te da las herramientas para la segunda parte. El truco es que los ayudantes deberían comentar, no responder.
La detección de colisiones en tiempo real de Front ayuda aquí: si un compañero está redactando una respuesta en una bandeja compartida, ves un indicador de que está respondiendo, y el contenido del borrador se comparte mientras escribe. Esto evita la respuesta duplicada. No decide quién es dueño del hilo, por lo que los ajustes de arriba importan.
Los reseñadores en G2 describen el beneficio casi con las mismas palabras:
"We can assign conversations, jump in when someone needs help, and avoid that awkward moment when two people reply to the same email. It sounds simple, but it saves a surprising amount of time."
Un detalle más de la suscripción que vale la pena saber: la preferencia personal Unsubscribe on unassign solo se aplica cuando te quitas la asignación manualmente a ti mismo. Cuando una regla te quita la asignación, sigues suscrito hasta que te das de baja tú mismo. Por eso la gente que estuvo en Out of office vuelve a una sección Subscribed llena de hilos que ya no les pertenecen.
Round robin o load balancing: ¿cuál mantiene la propiedad clara?
Si una regla asigna tus conversaciones, el método decide qué pasa cuando no hay nadie. La comparación de ambos de Front es directa sobre la diferencia.
| Round Robin | Load Balancing | |
|---|---|---|
| Quién recibe la siguiente conversación | El siguiente compañero en línea según el orden | El compañero con menos conversaciones compartidas abiertas y asignadas |
| Todos desconectados | Sin asignar, y sin cola | En cola hasta que alguien tenga hueco |
| El compañero vuelve a conectarse | No se recuperan las conversaciones saltadas | Recibe primero la conversación más antigua sin responder |
| Límite por persona | Ninguno | Límite por workspace, máximo y valor por defecto 100 |
| Las conversaciones en snooze cuentan para el límite | n/a | No |
| Plan | Rules (Starter permite hasta 10) | Professional y superior |
Fuentes: round robin vs. load balancing, reglas de load balancing, precios de Front.
Dos detalles de load balancing sorprenden a mucha gente. Primero, los límites son por workspace, así que en el propio ejemplo de Front, Hector tiene 4 en un workspace y 5 en otro, lo que suma hasta 9 conversaciones a la vez. Segundo, el motor de reglas de Front "does not re-assess rule conditions when a conversation reaches the front of a load balancing assignment queue." Una conversación que desde entonces ha cambiado de etiqueta sigue asignándose según la regla que coincidió al principio.
Mi opinión: round robin funciona bien para un equipo que siempre está cubierto en horario de bandeja. Si tu equipo se queda alguna vez completamente desconectado (noches, fines de semana, un equipo pequeño repartido en zonas horarias), load balancing es la opción más segura, porque round robin simplemente deja esas conversaciones sin asignar. Load balancing necesita Professional a 65 $ por puesto al mes con facturación anual, y la función de turnos que cambia los estados automáticamente está en Enterprise (105 $ por puesto al mes).
El mismo compromiso aparece en configuraciones de round robin de Zendesk, round robin de Freshdesk y round robin de Gorgias.
¿Qué modelo de propiedad debería elegir tu equipo?
Hay tres modelos que funcionan en Front. Cuál te conviene depende del tamaño del equipo y de con qué frecuencia todos están desconectados a la vez.
| Modelo | Cómo se fija el dueño | Ajustes que revisar | Encaja para |
|---|---|---|---|
| Reclamar respondiendo | Quien responde primero | Auto-asignación en primera respuesta activada, los ayudantes comentan en vez de responder | 2 a 5 personas, mismo horario |
| Asignado por regla | Regla de load balancing en entrantes | Límites de asignación, disparador Assignee is removed, disciplina con Out of office | Volumen constante, turnos o zonas horarias |
| Responsable de triaje | Una persona asigna cada mañana o cada hora | Auto-asignación en primera respuesta desactivada, quitar asignación por inactividad fijado | Equipos mixtos (soporte más ventas u operaciones) |
Elijas el que elijas, anota tres decisiones por escrito y compártelas con el equipo, porque son las que provocan el "pensé que lo tenías tú":
- ¿Responder reclama la conversación? Si no, desactiva Assign conversations on first reply en cada canal compartido.
- ¿Qué hace Out of office? O dejas que quite la asignación (el valor por defecto), o activas Keep assignments when teammate is out of office or busy. Elige uno, y dile al equipo qué estado usar al final de un turno.
- ¿Cuánto tiempo puede un hilo asignado estar en silencio? Fija Unassign conversation if inactive for a un número real o a Never, no a lo que alguien eligió sin pensar durante la configuración.
Las reglas pueden dejar esto ordenado, pero más reglas no siempre es mejor. Un reseñador de G2 resumió bien el compromiso:
"If you create too many rules, you end up having to check why each message ended up in a different place. We had to simplify the setup so that everyone understood how to work with it."
Si el modelo de Front no le funciona a tu equipo, mi lista de alternativas a Front y mi repaso de tickets para equipos pequeños son el siguiente paso.
Si todavía estás decidiendo si el modelo de bandeja compartida de Front o una cola de tickets te conviene más, mi guía bandeja compartida vs. tickets y mi comparativa Front frente a Hiver cubren las diferencias estructurales. Front también tiene estados de ticket opcionales (Open, Waiting, Resolved) para bandejas compartidas, que ayudan a seguir el progreso pero no cambian quién es dueño de una conversación.
¿Dónde encaja un compañero de IA en la propiedad de Front?
Un compañero de IA en Front funciona mejor como otro asignado o ayudante más, siguiendo las mismas reglas que todos los demás, en vez de como un sistema aparte que el equipo tiene que vigilar. Así está construida la integración de Front de eesel: se le pueden asignar conversaciones, dejar una respuesta redactada como comentario interno para que una persona la envíe, etiquetar, asignar a un compañero concreto o archivar. También puede entrar en acción cuando un compañero escribe @eesel en un comentario, lo que encaja con el modelo "los ayudantes comentan, los dueños responden" de arriba.
La suite nativa Front AI de Front, con Autopilot y Copilot, es la otra vía si prefieres quedarte con un solo proveedor.
Una limitación honesta de la documentación de Front de eesel: eesel asigna a un compañero concreto por nombre, no a un equipo o grupo. El enrutamiento a un grupo sigue dependiendo de tus reglas de Front, así que tu configuración de load balancing sigue haciendo su trabajo.
El patrón que veo funcionar más a menudo es el que usa Xap en Freshdesk: los tickets de estudiantes mal dirigidos reciben una respuesta de derivación completa redactada como nota interna, y una persona la envía. eesel nunca responde a un estudiante directamente. Adverscale es la versión con mención: un agente escribe @eesel en una nota, el compañero de IA responde preguntas del día a día, y todo lo que queda fuera de alcance recibe una nota explicando por qué se detuvo (escalado de IA hecho de la forma aburrida y fiable), más una asignación al grupo correcto. En 2.400 tickets al mes, eso dejó 2.700 notas internas para el equipo. Ambos casos son en otros helpdesks, pero la idea de propiedad se traslada directamente a Front: la IA hace la primera pasada, y el dueño sigue siendo una persona.
Si tu equipo configura las cosas desde una terminal, la CLI de eesel permite que un agente de código como Claude Code conecte Front con npx @eesel/cli integrations connect front, compruebe qué se sincronizó y pruebe un borrador de comentario interno en una conversación de prueba antes de que cualquier automatización se active. Aprobar la propia conexión con Front sigue necesitando a una persona con permisos para autorizar apps en Front.
Prueba eesel en tu bandeja compartida de Front
Si tu equipo de Front no deja de preguntar "¿quién tiene esta?", la solución empieza con los tres ajustes de arriba. eesel añade la siguiente capa: cada conversación nueva se lee, se redacta y, si quieres, se asigna al compañero correcto antes de que nadie tenga que reclamarla, con el borrador esperando como comentario interno para que tu dueño siga decidiendo qué sale. Aprende de tus conversaciones pasadas de Front y del centro de ayuda, y puedes empezar solo con borradores. Prueba eesel en tu bandeja de Front, o compara opciones en mi repaso de la mejor IA para Front.