Em uma caixa compartilhada do Front, o responsável é a pessoa atribuída, e só existe uma por vez. Todos os outros que comentam, são mencionados com @ ou se inscrevem são ajudantes. A pegadinha é que a responsabilidade muda sem ninguém clicar em Assign: responder a uma conversa sem responsável faz de você o dono, se colocar como Out of office devolve suas conversas à fila quando os clientes respondem, e um ajuste de inatividade pode remover a atribuição de threads silenciosos. Decida esses três ajustes de propósito, escolha load balancing em vez de round robin se sua equipe algum dia ficar totalmente off-line, e a pergunta "quem está com isso?" desaparece. Se você quer que toda conversa nova chegue com um próximo passo já redigido, a eesel trabalha como colega de IA dentro do Front e pode receber conversas atribuídas como qualquer outra pessoa.
O que significa "responsabilidade" em uma caixa compartilhada do Front?
No Front, responsabilidade é atribuição. O próprio centro de ajuda do Front diz isso sem rodeios: atribuir conversas dá "every message a clear owner", e "a conversation can only be assigned to one user at a time." Uma vez atribuída, ela aparece na seção Assigned to me dessa pessoa.
Eu construo agentes de IA que trabalham dentro de helpdesks como o Front, então passo muito tempo lendo como cada ferramenta de caixa compartilhada decide quem é responsável por uma conversa. A resposta do Front é mais clara que a maioria: um responsável, mais quantos ajudantes você quiser. Ajudantes são pessoas que:
- Comentam no thread (só a sua equipe vê os comentários).
- São mencionadas com @, o que puxa a conversa para a visão delas.
- Se inscrevem, o que move a conversa para a seção Subscribed delas quando há atividade nova.
Essa separação importa porque as regras de inscrição do Front dizem que o responsável não pode se desinscrever: "you must unassign or reassign the conversation first." Ajudantes podem saltar fora quando quiserem. O responsável não pode simplesmente desaparecer em silêncio.
Essa é a teoria. Na prática, o motivo pelo qual as equipes buscam esse tema é que uma conversa que achavam atribuída acabou não estando. Veja de onde isso vem.
O que muda o responsável sem ninguém clicar em Assign?
Cinco coisas movem ou removem o responsável em uma caixa compartilhada do Front, e só uma delas é uma pessoa reatribuindo de propósito.
1. A primeira pessoa a responder se torna o responsável
Os canais do Front têm um ajuste chamado Assign conversations on first reply. Com ele ativado, "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." Ele vem ativado por padrão.
É um bom padrão para equipes pequenas. Também é por isso que, em uma caixa entre equipes, um vendedor que responde rapidamente "let me check with support" acaba responsável por uma disputa de cobrança durante três semanas. Dois detalhes da documentação do Front: só é acionado em conversas sem responsável, e só funciona quando você envia a partir do Front, não de fora.
2. Out of office devolve conversas à fila
Quando um colega é colocado em Out of office, "any replies they receive to conversations that originated in a shared inbox will automatically get unassigned." Conversas que não recebem uma resposta nova continuam atribuídas a essa pessoa. As atribuições automáticas pausam, mas um colega ainda pode atribuir manualmente.
Busy é diferente. Segundo o guia de status de colegas do Front, Busy pausa novas atribuições por regra, mas conversas continuam atribuídas quando há atividade nova. Então a regra prática para qualquer passagem de bastão no suporte é: Busy para uma pausa de almoço, Out of office quando você encerra o dia. Cinza, ou seja sem dispositivo conectado, não pausa nada, então um colega que fecha o notebook sem mudar o status ainda pode receber atribuições por regra.
3. O temporizador de inatividade remove a atribuição de conversas silenciosas
Caixas compartilhadas têm um ajuste de caixa chamado Unassign conversation if inactive for. Você define um período, e quando uma conversa que ficou silenciosa por mais tempo que esse período recebe uma mensagem nova, o Front remove a atribuição. Você também pode escolher Never. Se os ajustes de bump da sua empresa contam também as mensagens de saída, elas também acionam isso; se não, só as de entrada acionam, conforme as notas do Front sobre bump.
Isso surpreende muita gente, e pode confundir seu acompanhamento de SLA, porque nada acontece no momento em que o temporizador se esgota. O responsável só desaparece quando o cliente finalmente escreve de volta.
4. Outra pessoa arquiva
Arquivar parece uma ação compartilhada, mas o Front rastreia visualizações separadamente. Do guia de status de conversa: "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." O responsável a mantém na sua lista mesmo depois que um colega organiza a visão compartilhada. É uma rede de segurança, não um bug, mas explica por que responsáveis veem coisas que o resto da equipe considera resolvidas.
5. Uma regra ou um admin reatribui
O caso de propósito. Como a atribuição por grupo em outros helpdesks, regras podem atribuir, remover a atribuição e reatribuir, e regras de load balancing podem reatribuir uma conversa que foi solta porque seu responsável ficou Out of office ou Busy, desde que a regra tenha um gatilho Assignee is removed (documentação de load balancing).
O único interruptor que sobrepõe quase tudo isso é o ajuste de caixa compartilhada Keep assignments when teammate is out of office or busy. Ao ativá-lo, conversas novas ainda podem ser atribuídas a colegas indisponíveis, as existentes permanecem com atividade nova, e o ajuste de remoção por inatividade fica desativado.
O que acontece com a responsabilidade em cada situação?
Aqui está a mesma lógica como consulta rápida. Escolha a situação que você está tentando explicar à sua equipe.
Como os ajudantes ajudam sem assumir a responsabilidade?
As equipes do Front mais organizadas separam "isso é meu" de "estou só ajudando aqui", e o Front dá as ferramentas para a segunda parte. O truque é que ajudantes devem comentar, não responder.
A detecção de colisão em tempo real do Front ajuda aqui: se um colega está redigindo uma resposta em uma caixa compartilhada, você vê um indicador de que ele está respondendo, e o conteúdo do rascunho é compartilhado enquanto ele digita. Isso evita a resposta duplicada. Mas não decide quem é o responsável pelo thread, por isso os ajustes acima importam.
Avaliadores no G2 descrevem o benefício quase com as mesmas palavras:
"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."
Mais um detalhe de inscrição que vale a pena saber: a preferência pessoal Unsubscribe on unassign só se aplica quando você remove sua própria atribuição manualmente. Quando uma regra remove sua atribuição, você continua inscrito até se desinscrever você mesmo. É por isso que pessoas que estavam em Out of office voltam a uma seção Subscribed cheia de threads que já não são mais delas.
Round robin ou load balancing: qual mantém a responsabilidade clara?
Se uma regra atribui suas conversas, o método decide o que acontece quando ninguém está por perto. A comparação dos dois do Front é direta sobre a diferença.
| Round Robin | Load Balancing | |
|---|---|---|
| Quem recebe a próxima conversa | O próximo colega on-line na sequência | O colega com menos conversas compartilhadas abertas e atribuídas |
| Todos off-line | Sem responsável, e sem fila | Em fila até alguém ter espaço |
| Colega volta a ficar on-line | Sem recuperação de conversas puladas | Recebe primeiro a conversa mais antiga sem resposta |
| Limite por pessoa | Nenhum | Limite por workspace, máximo e padrão 100 |
| Conversas em snooze contam para o limite | n/a | Não |
| Plano | Rules (Starter permite até 10) | Professional e acima |
Fontes: round robin vs. load balancing, regras de load balancing, preços do Front.
Dois detalhes do load balancing surpreendem muita gente. Primeiro, os limites são por workspace, então no próprio exemplo do Front, Hector tem 4 em um workspace e 5 em outro, somando até 9 conversas ao mesmo tempo. Segundo, o motor de regras do Front "does not re-assess rule conditions when a conversation reaches the front of a load balancing assignment queue." Uma conversa que desde então ganhou uma tag diferente ainda é atribuída pela regra que ela correspondeu originalmente.
Minha opinião: round robin funciona bem para uma equipe sempre coberta no horário da caixa. Se sua equipe algum dia fica totalmente off-line (noites, fins de semana, uma equipe pequena espalhada por fusos horários), load balancing é a escolha mais segura, porque round robin simplesmente deixa essas conversas sem responsável. Load balancing precisa do Professional a US$ 65 por assento por mês na cobrança anual, e o recurso de turnos que troca status automaticamente está no Enterprise (US$ 105 por assento por mês).
A mesma troca aparece em configurações de round robin do Zendesk, round robin do Freshdesk e round robin do Gorgias.
Qual modelo de responsabilidade sua equipe deveria escolher?
Existem três modelos que funcionam no Front. Qual se encaixa depende do tamanho da equipe e de com que frequência todos ficam off-line ao mesmo tempo.
| Modelo | Como o responsável é definido | Ajustes para checar | Serve para |
|---|---|---|---|
| Reivindicar respondendo | Quem responde primeiro | Auto-atribuição na primeira resposta ativada, ajudantes comentam em vez de responder | 2 a 5 pessoas, mesmo horário |
| Atribuído por regra | Regra de load balancing nas entradas | Limites de atribuição, gatilho Assignee is removed, disciplina com Out of office | Volume constante, turnos ou fusos horários |
| Responsável por triagem | Uma pessoa atribui toda manhã ou hora | Auto-atribuição na primeira resposta desativada, remoção por inatividade definida | Equipes mistas (suporte mais vendas ou operações) |
Qualquer que seja sua escolha, anote três decisões por escrito e compartilhe com a equipe, porque são elas que causam o "pensei que você estava com isso":
- Responder reivindica a conversa? Se não, desative Assign conversations on first reply em cada canal compartilhado.
- O que Out of office faz? Ou você deixa remover a atribuição (o padrão), ou ativa Keep assignments when teammate is out of office or busy. Escolha um, e diga à equipe qual status usar no fim de um turno.
- Quanto tempo um thread atribuído pode ficar em silêncio? Defina Unassign conversation if inactive for para um número real ou para Never, não para o que alguém escolheu de qualquer jeito durante a configuração.
Regras podem deixar isso organizado, mas mais regras não é sempre melhor. Um avaliador do G2 resumiu bem essa troca:
"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."
Se o modelo do Front não está funcionando para sua equipe, minha lista de alternativas ao Front e meu resumo de tickets para equipes pequenas são o próximo passo.
Se você ainda está decidindo se o modelo de caixa compartilhada do Front ou uma fila de tickets se encaixa melhor, meu guia caixa compartilhada vs. tickets e minha comparação Front vs. Hiver cobrem as diferenças estruturais. O Front também tem status de ticket opcionais (Open, Waiting, Resolved) para caixas compartilhadas, que ajudam a acompanhar o progresso mas não mudam quem é o responsável por uma conversa.
Onde um colega de IA se encaixa na responsabilidade do Front?
Um colega de IA no Front funciona melhor como mais um responsável ou ajudante, seguindo as mesmas regras que todo mundo, em vez de um sistema separado que a equipe precisa vigiar. É assim que a integração do Front da eesel é construída: ela pode receber conversas atribuídas, deixar uma resposta redigida como comentário interno para uma pessoa enviar, aplicar tags, atribuir a um colega específico ou arquivar. Ela também pode entrar em ação quando um colega digita @eesel em um comentário, o que se encaixa no modelo "ajudantes comentam, responsáveis respondem" acima.
A suíte nativa Front AI do Front, com Autopilot e Copilot, é a outra via se você preferir ficar com um único fornecedor.
Uma limitação honesta da documentação do Front da eesel: a eesel atribui a um colega nomeado específico, não a uma equipe ou grupo. O roteamento para um grupo continua dependendo das suas regras do Front, então sua configuração de load balancing continua fazendo o trabalho.
O padrão que vejo funcionar melhor com mais frequência é o que a Xap usa no Freshdesk: tickets de estudantes mal direcionados recebem uma resposta de encaminhamento completa redigida como nota interna, e uma pessoa a envia. A eesel nunca responde a um estudante diretamente. A Adverscale é a versão com menção: um agente escreve @eesel em uma nota, o colega de IA responde perguntas do dia a dia, e tudo fora do escopo recebe uma nota explicando por que parou (escalonamento de IA feito do jeito chato e confiável), mais uma atribuição ao grupo certo. Em 2.400 tickets por mês, isso deixou 2.700 notas internas para a equipe. Ambos são em outros helpdesks, mas a ideia de responsabilidade se transfere direto para o Front: a IA faz a primeira passada, e o responsável continua sendo uma pessoa.
Se sua equipe configura as coisas a partir de um terminal, a CLI da eesel permite que um agente de código como o Claude Code conecte o Front com npx @eesel/cli integrations connect front, verifique o que foi sincronizado, e teste um rascunho de comentário interno em uma conversa de teste antes de qualquer automação entrar em produção. Aprovar a própria conexão do Front ainda precisa de uma pessoa com permissão para autorizar apps no Front.
Teste a eesel na sua caixa compartilhada do Front
Se sua equipe do Front não para de perguntar "quem está com isso?", a solução começa com os três ajustes acima. A eesel adiciona a próxima camada: toda conversa nova é lida, redigida e, se você quiser, atribuída ao colega certo antes que alguém precise reivindicá-la, com o rascunho esperando como comentário interno para que o responsável continue decidindo o que sai. Ela aprende com suas conversas passadas do Front e com o centro de ajuda, e você pode começar só com rascunhos. Teste a eesel na sua caixa do Front, ou compare opções no meu resumo da melhor IA para o Front.