Permissões no Tigy: quem pode editar, testar e revisar agentes?

Faça um mapa de responsabilidades

Liste quem mantém prompts, documentos, ferramentas, telefonia e revisão de chamadas. Para cada pessoa, anote a tarefa e o recurso necessário. Use esse mapa como referência ao conceder acesso, sem assumir que um nome de papel libera todas as ações.

Convide para o workspace correto

Abra a área de pessoas do workspace, use o convite e confira email, papel e permissões oferecidas pelo formulário. Acompanhe o estado do convite e peça que a pessoa aceite com a conta correta. Um convite pendente não estabelece acesso efetivo.

Verifique o acesso ao agente

Papéis como proprietário, administrador e membro coexistem com permissões de recursos. Confira as ações permitidas pela interface. Testar, revisar registros e alterar ferramentas são responsabilidades diferentes; valide a combinação necessária com a conta da pessoa.

Investigue uma recusa

Confira conta autenticada, convite aceito, workspace selecionado e recurso pedido. Acesso de leitura não implica edição. Registre a ação recusada sem compartilhar senha, token ou dados de chamadas em um canal público.

Revise ao mudar a equipe

Quando uma responsabilidade termina, ajuste ou retire o acesso na área de pessoas. Antes disso, revise integrações dependentes daquela conta. Remover um membro e excluir um workspace são operações distintas: preserve os recursos que a equipe continua usando.

Como escolher acesso para quem revisa ou mantém agentes?

Uma pessoa que revisa chamadas pode precisar consultar registros; quem mantém instruções precisa editar o agente correspondente. Administração do workspace e alteração de credenciais são responsabilidades adicionais. Use a combinação oferecida pela interface, sem inferir uma matriz fixa de permissões apenas pelo nome do papel.

Para cada pessoa, registre tarefa, recurso e ação necessária. Teste uma ação permitida e outra que deve continuar restrita. Se houver recusa, confira conta, convite aceito, workspace e recurso antes de ampliar acesso administrativo. Essa verificação produz evidência de acesso efetivo.

Descreva o trabalho antes de escolher o papel

Permissões devem acompanhar responsabilidades concretas. Uma pessoa que revisa qualidade precisa encontrar conversas e compreender resultados. Quem mantém o agente precisa editar instruções e fontes pertinentes. Quem cuida de integrações pode precisar alterar ferramentas ou credenciais. A administração da cobrança é outra responsabilidade. Conceder o mesmo acesso amplo a todos porque trabalham na operação ignora essas diferenças e dificulta revisar o que cada pessoa realmente deve fazer.

Em uma equipe fictícia, uma analista acompanha chamadas para identificar respostas incorretas. Ela não precisa necessariamente alterar ferramentas de escrita. Um colega mantém uma integração de agenda e precisa da ação correspondente, mas isso não implica que deve administrar toda a equipe. Use as opções disponíveis na interface para relacionar as tarefas ao acesso. A documentação do Tigy descreve papéis como proprietário, administrador e membro, junto de permissões por recurso; o resumo efetivo precisa ser conferido no produto.

Faça uma matriz simples de pessoa, tarefa e recurso. Em vez de “precisa de acesso”, escreva “revisar execuções deste agente” ou “editar documentos utilizados por este atendimento”. Essa especificidade evita elevar o papel da conta apenas para resolver uma ação recusada cuja causa ainda não foi entendida. Também ajuda a explicar por que alguém pode entrar no workspace e ainda não editar determinado agente.

Registre um responsável pela decisão de acesso e a condição que motiva revisão. Mudança de função, encerramento de projeto e alteração na integração são momentos úteis. A matriz deve representar o trabalho atual, não acumular toda permissão já concedida. O objetivo é permitir que cada pessoa execute sua responsabilidade com clareza, mantendo restrições coerentes para ações que não pertencem ao seu papel operacional.

Acompanhe o convite e confirme a conta utilizada

Um convite enviado ainda precisa ser aceito pela conta correta. Antes de investigar permissão de edição, confira essa etapa. A documentação orienta abrir a área de pessoas do workspace, informar o email, selecionar papel e permissões oferecidos, enviar e acompanhar o estado. Se a pessoa usa outra conta para aceitar ou entra em outro workspace, a falha observada pode parecer uma restrição de recurso, embora a origem seja a identidade ou o contexto errado.

Em um exemplo fictício, a equipe convida uma colaboradora pelo email profissional, mas ela testa com a conta pessoal que já estava conectada. A primeira verificação deve ser a identidade ativa e o convite correspondente. Não resolva esse desencontro concedendo administração à conta pessoal sem avaliar o objetivo. O ajuste deve preservar a relação entre pessoa, conta e trabalho autorizado pela equipe.

Depois da aceitação, confirme o workspace selecionado e o recurso específico. Uma pessoa pode ter acesso a mais de um ambiente, com agentes parecidos. Testar um agente no workspace errado produz uma conclusão enganosa sobre o convite. Anote o recurso e a tarefa que deve funcionar. A partir daí, revise as permissões efetivas na interface e confirme se a ação desejada está incluída.

Use um teste pequeno e reversível para validar a tarefa permitida. Se a pessoa só precisa revisar, não teste exclusão ou alteração de ferramenta para demonstrar acesso. Também verifique uma restrição relevante que deve permanecer. A validação deve mostrar que o trabalho autorizado funciona, sem transformar a correção do convite em ampliação indiscriminada de capacidade. Essa sequência permite diagnosticar acesso bloqueado com evidência, em vez de depender de sucessivas mudanças de papel até o erro desaparecer.

Verifique acesso ao recurso e dependências da integração

Acesso ao workspace não comprova todas as permissões sobre agentes, ferramentas e documentos. A pessoa pode conseguir visualizar um recurso sem editar ou excluir. O Tigy apresenta opções e resumos de acesso que devem orientar a configuração. Não suponha uma matriz fixa de papéis além do que a interface e a documentação oferecem para aquela instalação. Verifique a ação concreta no recurso concreto.

Em uma equipe fictícia, a pessoa consegue editar instruções, mas não alterar uma ferramenta. Confira se sua conta tem acesso a esse recurso. Se a ferramenta se conecta a outro sistema, peça ao responsável pela integração que confira também a autorização dessa conexão. Nunca copie chaves de acesso em um pedido de suporte ou captura de tela; descreva a etapa e a mensagem de erro sem expor segredos.

Separe o acesso da pessoa ao Tigy do acesso da conexão a um serviço externo. A ferramenta pode depender de uma conta ou chave administrada por outra equipe. Dar acesso ao agente a um colega não transfere essas responsabilidades automaticamente. Liste as conexões necessárias e quem cuida de cada uma para encontrar a causa de uma recusa.

Depois de um ajuste, repita a ação autorizada e confira que as restrições relevantes continuam. Se a correção alterou uma credencial, verifique a integração com dados de teste apropriados. Não use um pedido real que grava ou envia informação apenas para confirmar que o botão voltou a funcionar. A validação precisa acompanhar o risco da ação e a finalidade do acesso, mostrando que o recurso pode ser mantido sem abrir capacidades desnecessárias.

Planeje a mudança de acesso sem interromper a operação

Quando alguém muda de função ou deixa a equipe, revise o acesso e as dependências antes de remover sua participação. Confira quem mantém as integrações e as credenciais dos serviços externos utilizados pelas ferramentas. Um agente pode continuar respondendo a perguntas e falhar apenas quando tenta usar uma ferramenta cuja credencial perdeu acesso. Por isso, a revisão precisa incluir o atendimento completo, não somente a presença do agente no workspace.

Em um exemplo fictício, uma pessoa mantinha a integração de agenda e outra passa a assumir a tarefa. Identifique credenciais, permissões e destinos relacionados. Faça a transição conforme as opções disponíveis e o processo da equipe. Depois teste consulta e ação com um cenário adequado. Não entregue a senha pessoal do antigo responsável como solução de continuidade; a integração deve ter uma forma de manutenção autorizada pela organização.

Diferencie remover um membro, excluir uma conta e excluir o workspace. Retirar participação não exige apagar o espaço compartilhado com agentes, ferramentas, documentos e outras pessoas. Uma exclusão de workspace tem alcance maior e deve ser escolhida somente quando esse recurso realmente precisa ser encerrado. A área de membros e permissões é o caminho documentado para revisar a participação da equipe.

Registre o acesso que mudou e o trabalho que continua com outro responsável. Quando a remoção afeta uma integração, confirme o estado final em vez de presumir que a ausência da pessoa na lista prova conclusão de todas as dependências. Uma revisão cuidadosa preserva continuidade sem manter acesso pessoal desnecessário. O resultado desejado é uma equipe que sabe quem pode alterar cada recurso e quem responde por sua manutenção, com permissões alinhadas à responsabilidade atual.

Use revisões periódicas para conferir o acesso efetivo

Uma revisão de acesso pode ser curta se parte de tarefas e recursos conhecidos. Confira quem ainda realiza cada responsabilidade, quais contas permanecem ativas e quais permissões já não têm finalidade. Projetos temporários podem deixar acesso esquecido depois do encerramento. Alterações no atendimento podem exigir uma nova tarefa para alguém que antes só revisava resultados. Atualize a configuração com base nessa realidade.

Inclua um teste de tarefa permitida e de restrição relevante quando houver mudança. A interface mostra o acesso configurado; uma verificação prática mostra se ele atende ao trabalho. Se uma ação falha, investigue identidade, convite, workspace, recurso e dependências antes de ampliar papel. A recusa pode representar uma restrição correta ou um contexto errado, e a correção depende dessa diferença.

Combine permissões com proteção da conta. Autenticação ajuda a identificar quem entra; permissões determinam o que essa identidade pode fazer. Ativar dois fatores não elimina a necessidade de revisar acesso ao recurso. Reduzir um papel não substitui cuidado com credenciais externas. Essas medidas tratam partes diferentes da operação e devem permanecer coordenadas, especialmente para quem pode alterar instruções ou ferramentas de escrita.

Acompanhe mudanças que causaram interrupção, acessos que precisaram de ampliação temporária e contas cuja responsabilidade não está clara. Use esses achados para melhorar a matriz de tarefas e a transição de manutenção. O objetivo não é criar uma revisão extensa para qualquer edição, mas tornar acesso explicável e verificável. Uma equipe pequena também se beneficia de saber por que cada pessoa possui determinada capacidade e como retirar ou alterar essa capacidade sem perder o atendimento que precisa continuar.