Resumo

  • No Premium, Guest entra na contagem de usuários cobráveis. No Ultimate, convidados que cumprem as condições ficam de fora; há também uma exceção para Guest com apenas a permissão adicional read_code.
  • O cargo da pessoa e o rótulo “somente leitura” não resolvem a cobrança. Importam as permissões efetivas e outras funções atribuídas dentro do alcance da assinatura.
  • Um novo usuário cobrável pode ocupar um assento já comprado e disponível. Quando há excesso, reduzir o acesso depois não apaga o pico registrado no período de cobrança.

O departamento de compras consegue discutir o preço por usuário durante semanas. Um administrador consegue mudar quem conta como usuário pago em poucos cliques. Os dois estão mexendo na mesma despesa, embora raramente usem a mesma tela.

O GitLab oferece um exemplo particularmente nítido dessa divisão de trabalho. Pela documentação de assentos consultada em 30 de outubro de 2026, quem recebe a função Guest é cobrável no Premium. No Ultimate, essa pessoa pode ficar fora da contagem, desde que cumpra as condições da isenção. O convidado não mudou de identidade. Mudou o contrato que define o preço de sua participação.

A diferença ganha interesse quando se abre a lista de permissões. O Ultimate vende mais funcionalidades e também uma maneira de deixar determinados participantes fora do denominador. Para avaliar a compra, contar cabeças é pouco. É preciso saber o que cada cabeça pode fazer.

A cortesia vem com uma lista de operações

A função Guest comum permite participação limitada, como interagir em questões e épicos. A explicação sobre convidados e a matriz de permissões mostram os limites: ela não oferece o acesso habitual ao código de repositórios privados nem permite enviar alterações ao código. Quem precisa ler o repositório pode receber Reporter. Reporter é uma função cobrável, mesmo sem a possibilidade de fazer push.

“Só vai olhar” é uma descrição de intenção. A licença exige uma descrição técnica.

No Ultimate, existe uma exceção expressa. Uma função personalizada baseada em Guest, cuja única permissão adicional seja read_code, não consome assento. O acesso para ler código pode, portanto, ser concedido por uma função que entra na conta ou por essa combinação estreita que fica de fora.

Basta acrescentar outras permissões além da exceção para passar a consumir um assento. Não adianta batizar uma função mais ampla de “convidado de revisão”. O nome é decoração; as capacidades são o contrato em funcionamento. Funções personalizadas estendem uma função de base e não retiram seus poderes. Começar com uma base larga e procurar um nome modesto não devolve a isenção.

Isso também explica por que separar funcionários de prestadores não basta. Um prestador pode precisar de operações cobráveis. Uma pessoa da casa pode cumprir seu trabalho com acesso limitado. A pergunta útil é concreta: ela precisa comentar uma questão, ler código ou executar operações adicionais? A resposta determina qual acesso comprar e conceder.

Se o trabalho exige a função mais ampla, a empresa tem motivo para pagar por ela. Tentar esconder essa necessidade compartilhando contas, distribuindo cópias sem autorização ou abrindo código privado cria outro custo, menos organizado que uma linha na fatura. A oportunidade econômica está em evitar permissões desnecessárias, preservando as necessárias.

A conta acompanha a pessoa além daquela tela

Há uma segunda armadilha na aparência do convidado. Um projeto pode mostrá-lo como Guest, enquanto outro lhe concede uma função superior dentro do mesmo alcance de cobrança. No GitLab.com, a análise passa pelo namespace da assinatura. O crachá local não demonstra que a pessoa inteira está isenta.

Também não se deve somar cada associação como se fosse um assento distinto. A mesma pessoa em vários projetos e subgrupos de um mesmo grupo superior contratado é contada uma vez. A tarefa é reconciliar funções por usuário, dentro da fronteira correta, e não multiplicar linhas de uma exportação de membros.

No Self-Managed, essa fronteira abrange a instância. A documentação chama atenção para a criação de projetos que pode atribuir Maintainer ou Owner ao usuário, consumindo assento. Um procedimento que só examina o grupo contratado no GitLab.com não cobre automaticamente uma instalação própria. Antes de discutir se o número está certo, é preciso concordar sobre onde a contagem começa e termina.

Esse detalhe torna o controle de acesso uma espécie de cadastro comercial distribuído. A equipe que convida alguém para um projeto pode não enxergar o conjunto de funções que determina seu tratamento financeiro. A economia de uma isenção depende de uma visão que atravessa o projeto.

Despromover não faz o calendário andar para trás

Um usuário que se torna cobrável primeiro pode ocupar um assento disponível entre os já comprados. Nesse caso, a alteração de permissão muda a ocupação, sem gerar automaticamente uma cobrança adicional. O susto financeiro começa quando o total ultrapassa a quantidade contratada.

Para esse excesso, interessa o máximo de usuários cobráveis no período. Retirar uma função depois não elimina o pico já ocorrido. Uma auditoria feita no fim do mês pode encontrar poucos usuários ativos e ainda assim deixar intacta a quantidade usada na conciliação.

O movimento inverso também merece precisão. O GitLab não soma para sempre toda pessoa que já passou pela organização. Assentos podem ser reutilizados dentro da capacidade adquirida. O indicador relevante é o pico aplicável, não uma lista histórica de todos os convidados.

A conciliação de excesso é trimestral ou anual conforme a elegibilidade. A trimestral usa o máximo do trimestre e o cálculo proporcional ao prazo restante da assinatura previsto nas regras. O ajuste anual cobra a tarifa anual pelos usuários adicionados. Um orçamento que suponha universalmente cobrança diária, ou conciliação trimestral para todo contrato, começa com uma conta inventada.

A gestão da assinatura acrescenta outra data à discussão: a redução da quantidade de assentos comprados ocorre na renovação. A empresa controla uma permissão hoje, mas pode só conseguir reduzir a compra em outro momento. A facilidade operacional do clique não encurta o compromisso comercial.

O plano mais caro vende uma porta de entrada gratuita

Na tabela pública de preços, o Premium custa US$ 29 por usuário por mês, com faturamento anual; o Ultimate depende de proposta comercial. A quantidade menor de usuários cobráveis no plano superior, sozinha, não prova economia. Faltam o preço efetivamente cotado para o Ultimate e a distribuição real das permissões para fechar essa conta.

O mecanismo comercial, porém, é visível. Uma faixa mais alta do produto pode acomodar mais gente na borda do trabalho sem cobrar assento por cada participante. Quando essas pessoas passam a precisar de capacidades adicionais, a fronteira paga volta a aparecer. A empresa compra funcionalidades e uma definição de quem entra no cálculo.

Isso dá valor a um desenho de acesso bem feito. Uma função estreita pode ser suficiente, mais fácil de controlar e mais barata. Uma função ampla pode ser indispensável. Tratar ambas como decisões explícitas é melhor que deixar a escolha depender da preferência do administrador que recebeu o pedido naquele dia.

A negociação sobre software costuma terminar na expressão “preço por usuário”. No GitLab, vale insistir na última palavra. O fornecedor define o usuário cobrável; a organização o produz quando distribui funções. Compras pode conseguir um bom desconto e continuar sem ver quem está aumentando a quantidade.