O Confluence tem 25 pessoas. A conta do aplicativo pode chamar 100

Resumo

• A Atlassian apresenta um exemplo em que um aplicativo do Confluence passa do preço de 25 usuários ao de 100 ao entrar no Teamwork Collection, em um site com 100 usuários do Jira.
• O pacote conta uma só vez cada usuário dos produtos incluídos. Aplicativos do Marketplace seguem suas próprias licenças e podem receber uma base de cobrança mais ampla nessa mudança.
• Cobrança por instância, assinatura Enterprise com várias instâncias e o modelo Forge por usuários autorizados tratam de limites diferentes. A oferta disponível e a cotação determinam o que a empresa pode comprar.

O pedido parece ser de organização: reunir produtos da Atlassian numa Collection. Mas o exemplo que a própria empresa publica dá ao pedido um segundo efeito. Uma ferramenta já instalada passa do preço para 25 pessoas ao preço para 100. O responsável pelo pacote acabou de mexer também na compra de outro fornecedor.

A sequência aparece na documentação de cobrança do Marketplace. Há um Confluence Cloud com 25 usuários e um aplicativo instalado. A assinatura migra para o Teamwork Collection no mesmo site em que o Jira tem 100 usuários. O aplicativo recebe o preço de 100.

São quatro vezes mais pessoas na base. A tabela da ferramenta, suas faixas e seus descontos dirão quanto isso representa em dinheiro. Para compras, o dado urgente é a mudança de quantidade: a proposta principal precisa vir acompanhada da nova cotação do aplicativo.

O fornecedor da ferramenta não precisou apresentar uma nova função para que o alcance vendido mudasse. A licença acompanhou a reorganização dos produtos. Esse é o tipo de detalhe capaz de transformar uma reunião sobre simplificação em outra conversa sobre quem autorizou a despesa.

A linha da Collection não fecha a conta dos aplicativos

Pela explicação das Collections, quem tem acesso a pelo menos um produto incluído é um usuário faturável. A mesma pessoa conta uma vez, ainda que acesse vários desses produtos. No Teamwork Collection, itens incluídos como Jira, Confluence e Loom aparecem reunidos em uma linha de assinatura.

Para a empresa, essa proposta é fácil de apresentar. O funcionário que trabalha em várias ferramentas continua sendo uma pessoa. Reunir produtos pode simplificar a compra e tornar a fatura menos fragmentada.

Os aplicativos do Marketplace mantêm uma relação de licença própria. A Atlassian informa que sua cobrança depende da licença e da ligação com o produto em que estão instalados, e que levá-los para uma Collection pode alterar o preço. A remoção de duplicidades dentro do pacote e a ampliação da base de um aplicativo podem ocorrer na mesma operação.

Esse encontro exige uma planilha maior do que a linha principal da proposta. Uma equipe pode calcular a vantagem de juntar os produtos da Atlassian e deixar de fora os aplicativos que já fazem parte do trabalho. A oferta fica simples justamente onde a comparação deveria ficar completa.

O detalhe interessa sobretudo às ferramentas especializadas. O responsável por uma área pode ter aprovado um aplicativo para resolver um problema delimitado. Mais tarde, uma reorganização da plataforma muda o tamanho da licença que o acompanha. A necessidade continua pequena; a compra passa a carregar um grupo maior.

O exemplo de 500 usuários mostra o que está à venda

O guia dos modelos de cobrança Forge descreve o modelo padrão como uma cobrança por todos os usuários da instância que hospeda o aplicativo. O número de pessoas que realmente o utiliza pode ser menor.

A ilustração oficial usa uma instância Jira com 500 usuários e um aplicativo usado por 50. Com o preço didático de 2 dólares por usuário ao mês, a conta soma 1.000 dólares para os 500. São números escolhidos pela documentação para explicar a regra: a população licenciada acompanha a instância anfitriã.

Para uma equipe pequena dentro de uma organização grande, isso muda a conversa sobre valor. Demonstrar que uma ferramenta melhora o trabalho do grupo é uma parte da aprovação. A outra é justificar uma licença dimensionada para mais gente. Um produto pode ser útil e ainda encontrar uma porta comercial estreita.

O modelo amplo também pode ter utilidade quando o objetivo é oferecer a ferramenta a todos sem manter uma seleção separada de pessoas. Cada compra deve relacionar o alcance desejado com o alcance vendido. Um relatório de atividade mostra quem usou; a licença diz qual população está sendo comprada.

A Atlassian descreve outra possibilidade em seu guia de adoção da cobrança por usuários: o administrador escolhe quem recebe acesso ao aplicativo, e a organização paga por esse grupo autorizado. O critério passa a ser a concessão de acesso à ferramenta específica. Cliques e frequência de uso continuam sendo medidas diferentes.

Há uma fronteira de disponibilidade a respeitar. Os documentos consultados apresentam esse recurso como EAP, com construção, implantação e testes em ambientes fora de produção. Publicação no Marketplace, configuração de preços, revisões e aprovação aparecem como atualizações futuras. O guia também contém requisitos de aplicativos publicados e condições de transição em produção; uma compra atual precisa confirmar qual modelo está efetivamente habilitado no aplicativo.

Mesmo no desenho proposto, a escolha comercial continua com o parceiro. Ele decide adotar o modelo, pode ajustar preços e leva seus clientes existentes para a nova modalidade quando o aplicativo faz a transição. O recurso se destina a Forge; aplicativos Connect precisam adotar Forge antes. Reduzir uma lista de permissões do lado do comprador só terá o efeito financeiro pretendido se a licença vendida acompanhar essa lista.

Essa possibilidade pode facilitar a entrada de ferramentas especializadas em empresas grandes. O fornecedor também pode cobrar um preço unitário diferente quando a base se estreita. Menos pessoas na conta e menos dinheiro no total se encontram na cotação, com duas variáveis ainda abertas à negociação.

Instalar no lugar certo é uma decisão de quantidade

A quantidade aplicável a aplicativos do Jira merece atenção própria. No exemplo oficial de um site com 100 usuários Jira e 80 agentes Jira Service Management, o Marketplace usa a maior quantidade, 100. Somar os grupos e chegar a 180 seria fazer outro cálculo. Se a assinatura Jira de 100 usuários for desativada, o preço para os 80 restantes começa no ciclo seguinte.

É preciso saber qual produto anfitrião está puxando a faixa do aplicativo. A ferramenta pode ter um público local e depender comercialmente de outra quantidade no mesmo site. O desenho do ambiente ajuda a explicar a conta.

No Enterprise, a documentação de faturamento usa a organização fictícia Acme para mostrar a compra por instância. Seus 8.000 usuários Jira estão divididos em instâncias de 5.000 e 3.000 pessoas. Um aplicativo instalado na primeira recebe, nesse arranjo, a cobrança correspondente a 5.000 usuários.

A população inteira da empresa e o tamanho da licença de cada aplicativo podem, portanto, ser diferentes. A instalação de uma ferramenta especializada tem uma consequência comercial: ela escolhe o ambiente ao qual a compra ficará ligada.

Separar ambientes traz trabalho. Alguém precisa manter configurações, orientar os usuários e organizar a colaboração entre espaços. Uma licença menor deve ser comparada com essa carga operacional. Caso contrário, a economia aparece na compra do aplicativo e o custo muda para as horas de outra equipe.

Para Jira ou Confluence no Cloud Enterprise, a Atlassian também descreve a cobrança de aplicativos em várias instâncias. A organização pode reunir essas instâncias em uma assinatura Marketplace e contar uma vez cada usuário único entre elas, de acordo com a faixa escolhida no início da assinatura. Depois da compra, ainda é necessário instalar o aplicativo nas instâncias para usar suas funções.

Esse modelo trata da repetição da mesma pessoa em ambientes diferentes. A cobrança Forge por usuários autorizados trata da seleção de pessoas dentro de um ambiente. As duas propostas podem reduzir abrangências desnecessárias, mas trabalham sobre conjuntos diferentes.

A página de suporte usa o futuro ao dizer que todos os aplicativos oferecerão preços para várias instâncias. A operação concreta depende das opções disponíveis para o aplicativo escolhido. O comprador precisa encaixar o modelo documentado na oferta que realmente pode contratar.

O segundo orçamento precisa chegar antes da assinatura

O número decisivo no exemplo inicial é 100: ele surge de uma configuração de produtos que o comprador pode avaliar antes de migrar. Levar essa quantidade ao parceiro do aplicativo permite pedir o preço da situação futura enquanto o desenho da compra ainda está aberto.

É nesse ponto que a comparação fica comercialmente útil. A oferta da Collection ocupa uma linha. Cada aplicativo instalado ocupa outra, com a licença e o alcance que terá depois. A soma mostra se a vantagem oferecida no pacote sobrevive ao conjunto de ferramentas que a empresa pretende conservar.

Há razões para escolher um ambiente grande e compartilhado. Há ferramentas que precisam estar disponíveis a todos. Também há especialidades cujo valor se concentra numa equipe pequena. A cotação completa permite escolher conscientemente entre essas situações.

O aplicativo do exemplo não precisou ficar mais sofisticado para chegar ao preço de 100. Bastou mudar o contrato ao qual ele estava ligado. A reunião de compra deve enxergar os dois acontecimentos: produtos reunidos e uma licença que acaba de aumentar de tamanho.