Modelos de preços para uma solução multilocatário

Um bom modelo de preços garante que você permaneça lucrativo conforme o número de locatários aumenta e são adicionados novos recursos. Uma consideração importante ao desenvolver uma solução multilocatário comercial é como criar modelos de preços para seu produto. Nesta página, fornecemos diretrizes para os tomadores de decisões técnicas sobre os modelos de preços que você pode considerar e as compensações envolvidas.

Quando você determina o modelo de preços do produto, é necessário equilibrar o ROV (retorno sobre o valor) para seus clientes com o COGS (custo dos produtos vendidos) para fornecer o serviço. Oferecer modelos comerciais mais flexíveis (para uma solução) pode aumentar o ROV para os clientes, mas também pode aumentar a complexidade arquitetônica e comercial da solução (portanto, aumentar também o COGS).

Algumas considerações importantes que você deve levar em conta ao desenvolver modelos de preços para uma solução são as seguintes:

• O COGS será maior do que o lucro obtido com a solução?
• O COGS pode mudar ao longo do tempo, com base no crescimento de usuários ou alterações nos padrões de uso?
• Quão difícil é medir e registrar as informações necessárias para operar o modelo de preços? Por exemplo, se você planeja cobrar seus clientes com base no número de chamadas à API que eles fazem, mas medições das chamadas à API feitas por cada cliente foram identificadas?
• Sua rentabilidade depende da garantia de que os clientes usem sua solução de forma limitada?
• Se um cliente usa a solução em excesso, isso significa que você não é mais rentável?

Há alguns fatores importantes que influenciam sua rentabilidade:

• Modelos de preços do serviço do Azure. Os modelos de preços dos serviços do Azure ou de terceiros que compõem sua solução podem afetar quais modelos são lucrativos.
• Padrões de uso de serviço. Os usuários só podem precisar acessar sua solução durante o horário de trabalho ou podem ter apenas uma pequena porcentagem de usuários de alto volume. Você pode diminuir seu COGS reduzindo a capacidade não utilizada quando o uso é baixo?
• Crescimento do armazenamento. A maioria das soluções acumula dados ao longo do tempo. Mais dados significam um custo mais alto para armazenar e protegê-los, reduzindo sua rentabilidade por locatário. Você pode definir cotas de armazenamento ou aplicar um período de retenção de dados?
• Isolamento de locatário. O modelo de locação usado afeta o nível de isolamento que você tem entre seus locatários. Se você compartilhar seus recursos, precisará considerar como os locatários podem utilizar ou abusar demais do serviço? Como o nível de isolamento do locatário afetará seu COGS e desempenho para todos? Alguns modelos de preços não são lucrativos sem controles adicionais em torno da alocação de recursos. Por exemplo, talvez seja necessário implementar a limitação do serviço para tornar sustentável um modelo de preços simples.
• Ciclo de vida do locatário. Por exemplo, soluções com altas taxas de rotatividade de clientes ou serviços que exigem um maior esforço de integração poderão sofrer menor rentabilidade, especialmente se forem precificadas usando um modelo baseado em consumo.
• Requisitos de nível de serviço. Locatários que exigem níveis de serviço mais altos podem significar que sua solução não é mais lucrativa. É fundamental que você seja claro sobre as expectativas de nível de serviço dos clientes e quaisquer obrigações que tem, para que possa planejar seus modelos de preços de acordo.

Modelos de preço comuns

Há muitos modelos de preços comuns que geralmente são usados com soluções multilocatário. Cada um desses modelos de preços tem benefícios e riscos comerciais associados e requer considerações arquiteturais adicionais. É importante entender as diferenças entre esses modelos de preços, para que você possa garantir que sua solução permaneça lucrativa conforme ela evolui.

Observação

Você pode oferecer vários modelos para uma solução ou combinar modelos. Por exemplo, você pode fornecer um modelo por usuário para os clientes que têm números de usuário bastante estáveis e também pode oferecer um modelo de consumo para clientes que têm padrões de uso flutuantes.

Preço com base no consumo

Às vezes, um modelo de consumo é chamado de Pagamento Conforme o Uso ou PAYG. Conforme o uso do serviço aumenta, sua receita aumenta:

Quando você mede o consumo, pode considerar fatores simples, como a quantidade de dados que estão sendo adicionados à solução. Como alternativa, você pode considerar uma combinação de atributos de uso. Os modelos de consumo oferecem muitos benefícios, mas podem ser difíceis de implementar em uma solução multilocatário.

Benefícios: do ponto de vista dos clientes, há um investimento inicial mínimo necessário para usar sua solução, de modo que esse modelo tenha uma baixa barreira à entrada. Da sua perspectiva como operador de serviço, os custos de hospedagem e gerenciamento aumentam à medida que o uso dos clientes e sua receita aumentam. Esse aumento pode torná-lo um modelo de preços altamente escalonável. Os modelos de preços de consumo funcionam especialmente bem quando os serviços do Azure usados na solução também são baseados em consumo.

Complexidade e custo operacional: os modelos de consumo dependem de medidas precisas de uso e na divisão desse uso por locatário. Isso pode ser desafiador, especialmente em uma solução com muitos componentes distribuídos. Você precisa manter registros de consumo detalhados para fins de cobrança e auditoria, bem como fornecer métodos para que os clientes tenham acesso aos seus dados de consumo.

Riscos: os preços de consumo podem motivar seus clientes a reduzir o uso do sistema, a fim de reduzir seus custos. Além disso, os modelos de consumo resultam em fluxos de receita imprevisíveis. Você pode atenuar isso oferecendo reservas de capacidade, em que os clientes pagam por algum nível de consumo antecipadamente. Como provedor de serviços, você pode usar essa receita para investir em melhorias na solução, para reduzir o custo operacional ou aumentar o retorno sobre o valor adicionando recursos.

Observação

Implementar e dar suporte a reservas de capacidade pode aumentar a complexidade dos processos de cobrança em seu aplicativo. Talvez você também precise considerar como os clientes recebem reembolsos ou trocam suas reservas de capacidade, e esses processos também podem adicionar desafios comerciais e operacionais.

Preços por usuário

Um modelo de preços por usuário envolve a cobrança de clientes com base no número de pessoas que usam o serviço, conforme demonstrado no diagrama a seguir.

Modelos de preços por usuário são muito comuns, devido à sua simplicidade para implementar em uma solução multilocatário. No entanto, eles estão associados a vários riscos comerciais.

Benefícios: quando você cobra os clientes por cada usuário, é fácil calcular e prever seu fluxo de receita. Além disso, supondo que você tenha padrões de uso bastante consistentes para cada usuário, a receita aumenta na mesma taxa que a adoção do serviço, tornando-o um modelo escalonável.

Complexidade e custo operacional: modelos por usuário tendem a ser fáceis de implementar. No entanto, em algumas situações, você precisa medir o consumo por usuário, o que pode ajudá-lo a garantir que o COGS para um único usuário permaneça rentável. Medindo o consumo e associando a um determinado usuário, você poderá aumentar a complexidade operacional da solução.

Riscos: padrões de consumo de usuário diferentes podem resultar em um lucro reduzido. Por exemplo, usuários pesados da solução podem custar mais para atender do que usuários leves. Além disso, o ROV (retorno real do valor) para a solução não é refletido pelo número real de licenças de usuário adquiridas.

Preços por usuário ativo

Este modelo é semelhante ao preço por usuário. Mas, em vez de exigir um compromisso antecipado do cliente sobre o número de usuários esperados, o cliente só é cobrado pelos usuários que realmente fazem logon e usam a solução durante um período (conforme mostrado no diagrama a seguir).

Você pode medir isso em qualquer período que faça sentido. Períodos mensais são comuns, e essa métrica geralmente é registrada como usuários ativos mensais ou MAU.

Benefícios: do ponto de vista dos clientes, esse modelo requer um baixo investimento e risco, pois há um desperdício mínimo. Licenças não utilizados não podem ser cobradas. Isso o tornará particularmente atraente ao comercializar a solução ou aumentar a solução para clientes corporativos maiores. Da sua perspectiva como proprietário do serviço, o ROV é refletido com mais precisão para o cliente pelo número de usuários ativos mensais.

Complexidade e custo operacional: os modelos de usuário por ativo exigem que você registre o uso real e o disponibilize para um cliente como parte da fatura. Medir o consumo por usuário ajuda a garantir que a rentabilidade seja mantida com o COGS para um único usuário. Mas novamente requer trabalho adicional para medir o consumo de cada usuário.

Riscos: assim como os preços por usuário, há o risco de que os diferentes padrões de consumo de usuários individuais possam afetar sua rentabilidade. Em comparação com os preços por usuário, os modelos de usuário por ativo têm um fluxo de receita menos previsível. Além disso, o preço do desconto não fornece uma maneira útil de estimular o crescimento.

Preço por unidade

Em muitos sistemas, o número de usuários não é o elemento que tem o maior efeito sobre o COGS geral. Por exemplo, em soluções orientadas a dispositivos, também conhecidas como Internet das Coisas ou IoT, o número de dispositivos geralmente tem o maior impacto sobre o COGS. Nesses sistemas, um modelo de preços por unidade pode ser usado, onde você define o que é uma unidade, como um dispositivo. Confira o diagrama a seguir.

Além disso, algumas soluções têm padrões de uso altamente variáveis, em que um pequeno número de usuários tem um impacto desproporcional sobre o COGS. Por exemplo, em uma solução vendida para varejistas de lojas físicas, um modelo de preços por loja pode ser apropriado.

Benefícios: nos sistemas em que os usuários individuais não têm um efeito significativo no COGS, o preço por unidade é uma maneira melhor de representar a realidade de como o sistema é dimensionado e o impacto resultante para o COGS. Ele também pode melhorar o alinhamento aos padrões reais de uso de um cliente. Para muitas soluções de IoT, em que cada dispositivo gera uma quantidade previsível e constante de consumo, esse pode ser um modelo eficaz para dimensionar o crescimento da solução.

Complexidade e custo operacional: geralmente, o preço por unidade é fácil de implementar e tem um custo operacional bastante baixo. No entanto, o custo operacional poderá se tornar mais alto se você precisar diferenciar e acompanhar o uso por unidades individuais, como dispositivos ou lojas de varejo. Medir o consumo por unidade ajudará a garantir que sua rentabilidade seja mantida, pois você poderá determinar o COGS para uma única unidade.

Riscos: os riscos de um modelo de preços por unidade são semelhantes ao preço por usuário. Padrões de consumo diferentes de algumas unidades poderão significar que você tem uma rentabilidade reduzida, como se alguns dispositivos ou repositórios forem usuários muito mais pesados da solução do que outros.

Preço baseado no nível do recurso e do serviço

Você pode optar por oferecer sua solução com diferentes camadas de funcionalidade a diferentes pontos de preço. Por exemplo, você pode fornecer dois preços fixos mensais ou por unidade, sendo um uma oferta básica com um subconjunto de recursos disponíveis e o outro apresentando o conjunto abrangente de recursos da sua solução. Confira o diagrama a seguir.

Esse modelo também pode oferecer contratos de nível de serviço diferentes para diferentes camadas. Por exemplo, sua camada básica pode oferecer 99,9% de tempo de atividade, enquanto uma camada premium pode oferecer 99,99%. O SLA (contrato de nível de serviço) mais alto pode ser implementado usando serviços e recursos que permitem destinos de disponibilidade mais altos.

Embora esse modelo possa ser comercialmente benéfico, ele requer práticas de engenharia maduras para ter sucesso. Com consideração cuidadosa, esse modelo pode ser muito eficaz.

Benefícios: os preços baseados em recursos geralmente são atrativos para os clientes, pois eles podem selecionar uma camada com base no conjunto de recursos ou no nível de serviço de que precisam. Ele também fornece um caminho claro para aumentar a venda de seus clientes com recursos adicionais ou maior resiliência para aqueles que precisam dele.

Complexidade e custo operacional: modelos de preços baseados em recursos podem ser complexos de implementar, pois exigem que sua solução esteja ciente dos recursos disponíveis em cada camada de preço. Os alternâncias de recursos podem ser uma maneira eficaz de fornecer acesso a determinados subconjuntos de funcionalidade, mas isso requer manutenção contínua. Além disso, as alternâncias de recursos aumentam a sobrecarga para garantir a alta qualidade, pois haverá mais caminhos de código para testar. Habilitar metas de disponibilidade de serviços mais altas em algumas camadas pode exigir complexidade de arquitetura adicional, para garantir que o conjunto certo de infraestrutura seja usado para cada camada. Esse processo pode aumentar o custo operacional da solução.

Riscos: modelos de preços baseados em recursos poderão se tornar complicados e confusos, se houver muitas camadas ou opções. Além disso, a sobrecarga envolvida na alternância dinâmica de recursos pode reduzir a taxa na qual você fornece recursos adicionais.

Preços de freemium

Você pode optar por oferecer uma camada gratuita do serviço, com funcionalidade básica e sem garantias de nível de serviço. Você pode oferecer uma camada paga separada, com recursos adicionais e um contrato de nível de serviço formal (conforme mostrado no diagrama a seguir).

A camada gratuita também pode ser oferecida como uma avaliação por tempo limitado e, durante a avaliação, seus clientes podem ter funcionalidade completa ou limitada disponível. Isso é conhecido como um modelo de freemium, que é efetivamente uma extensão do modelo de preços baseado em recursos.

Benefícios: é muito fácil comercializar uma solução quando é gratuita.

Complexidade e custo operacional: todas as preocupações de complexidade e custo operacional se aplicam a partir do modelo de preços baseado em recursos. No entanto, você também precisa considerar o custo operacional envolvido no gerenciamento de locatários gratuitos. Talvez seja necessário garantir que os locatários obsoletos sejam integrados ou removidos, e você deve ter uma política de retenção clara, especialmente para locatários gratuitos. Ao promover um locatário para uma camada paga, talvez seja necessário mover o locatário entre os serviços do Azure para obter SLAs mais altas. Também será importante reter os dados e a configuração do locatário ao ser transferido para uma camada paga.

Riscos: você precisa fornecer um ROV alto o suficiente para que os locatários considerem mudar para uma camada paga. Além disso, o custo de fornecer sua solução aos clientes na camada gratuita precisa ser coberto pela margem de lucro daqueles que estão em camadas pagas.

Preço de custo dos produtos vendidos

Você pode optar por precificar a solução para que cada locatário pague apenas o custo de operação de sua parte dos serviços do Azure, sem margem de lucro adicional. Esse modelo – também chamado de custo ou preço de passagem – às vezes é usado para soluções multilocatário que não se destinam a ser um centro de lucro.

O modelo de custo de produtos vendidos é uma boa opção para soluções multilocatários voltadas internamente. Cada unidade organizacional corresponde a um locatário e os custos dos recursos do Azure precisam ser distribuídos entre eles. Também pode ser apropriado quando a receita é derivada de vendas de outros produtos e serviços que consomem ou aumentam a solução multilocatário.

Benefícios: como esse modelo não inclui nenhuma margem adicional de lucro, o custo para os locatários será menor.

Complexidade e custo operacional: semelhante ao modelo de consumo, o preço de custo dos produtos vendidos depende de medidas precisas de uso e na divisão desse uso por locatário. O consumo de acompanhamento pode ser desafiador, especialmente em uma solução com muitos componentes distribuídos. Você precisa manter registros de consumo detalhados para fins de cobrança e auditoria, bem como fornecer métodos para que os clientes tenham acesso aos seus dados de consumo.

Para soluções multilocatários voltadas internamente, os locatários podem aceitar estimativas de custo aproximadas e ter requisitos de auditoria de cobrança mais relaxados. Esses requisitos relaxados reduzem a complexidade e o custo de operação da solução.

Riscos: o preço de custo dos produtos vendidos pode motivar os locatários a reduzir o uso do sistema, a fim de reduzir seus custos. No entanto, como esse modelo é usado para aplicativos que não são centros de lucro, isso pode não ser uma preocupação.

Preço de taxa fixa

Neste modelo, você cobra uma taxa fixa para um locatário pelo acesso à sua solução por um determinado período. O mesmo preço se aplica independentemente do quanto eles usam o serviço, o número de usuários, o número de dispositivos que se conectam ou qualquer outra métrica. Confira o diagrama a seguir.

Esse é o modelo mais simples a ser implementado e para os clientes entenderem e geralmente é solicitado por clientes corporativos. No entanto, ele poderá facilmente se tornar pouco rentável se você precisar continuar a adicionar recursos ou se o consumo de locatários aumentar sem nenhuma receita adicional.

Benefícios: o preço de taxa fixa é fácil de vender e é fácil para seus clientes entender e orçamento.

Complexidade e custo operacional: os modelos de preço de taxa fixa podem ser fáceis de implementar porque os clientes de cobrança não exigem nenhum consumo de medição ou acompanhamento. No entanto, embora não seja essencial, é aconselhável medir o consumo por locatário para garantir que você esteja medindo o COGS com precisão e garantir que sua rentabilidade seja mantida.

Riscos: se você tiver locatários que fazem uso intenso da sua solução, facilmente esse modelo de preços se tornará pouco rentável.

Preço com desconto

Depois de definir seu modelo de preços, você poderá optar por implementar estratégias comerciais para incentivar o crescimento por meio de preço com desconto. Preço com desconto pode ser usado com modelos de preço de consumo, por usuário e por unidade.

Observação

O preço com desconto normalmente não exige considerações de arquitetura, além de adicionar suporte para uma estrutura de cobrança mais complexa. Uma discussão completa sobre os benefícios comerciais do desconto está além do escopo deste documento.

Os padrões comuns de preço com desconto incluem:

• Preço fixo. Você tem o mesmo custo para cada usuário, unidade ou quantidade de consumo, não importa quanto seja comprado ou consumido. Essa é a abordagem mais simples. No entanto, os clientes que fazem uso pesado da sua solução podem sentir que devem se beneficiar de economias de escala obtendo um desconto.
• Preço digressivo. Conforme os clientes compram ou consomem mais unidades, você reduz o custo por unidade. Isso é mais atrativo comercialmente para os clientes.
• Preço de etapas. Você reduz o custo por unidade, conforme os clientes compram mais. No entanto, você faz isso em alterações de etapa, com base em intervalos predefinidos de quantidade. Por exemplo, você pode cobrar um preço mais alto para os primeiros 100 usuários, depois um preço mais baixo para o 101º até o 200º usuário e um preço mais baixo novamente depois disso. Isso pode ser mais lucrativo.

O diagrama a seguir ilustra estes padrões de preço.

Descontos de ambiente de não produção

Em muitos casos, os clientes exigem acesso a um ambiente de não produção que podem ser usados para teste, treinamento ou para criar sua documentação interna. Os ambientes de não produção geralmente têm requisitos de consumo e custos menores para operar. Por exemplo, os ambientes de não produção geralmente não estão sujeitos a SLAs (contratos de nível de serviço) e os limites de taxa podem ser definidos com valores mais baixos. Você também pode considerar um dimensionamento automático mais agressivo em seus serviços do Azure.

Da mesma forma, os clientes geralmente esperam que os ambientes de não produção sejam significativamente mais baratos do que seus ambientes de produção. Há várias alternativas que podem ser apropriadas quando você fornece ambientes de não produção:

• Ofereça uma camada de freemium, como você pode fazer para clientes pagos. Isso deve ser monitorado cuidadosamente, pois algumas organizações podem criar muitos ambientes de teste e treinamento, que consumirão recursos adicionais para operar.

  Observação

  As avaliações com tempo limitado usando camadas de freemium geralmente não são adequadas para ambientes de teste e treinamento. Os clientes geralmente precisam que seus ambientes de não produção estejam disponíveis para o tempo de vida do serviço de produção.

• Ofereça uma camada de teste ou treinamento do seu serviço, com limites de uso mais baixos. Você pode optar por restringir a disponibilidade dessa camada aos clientes que têm um locatário pago existente.
• Ofereça um preço com desconto por usuário, por usuário ativo ou por unidade para locatários que não são de produção, com um contrato de nível de serviço inferior ou nenhum contrato.
• Para locatários que usam preço de taxa fixa, os ambientes de não produção podem ser negociados como parte do contrato.

Observação

Os preços baseados em recursos geralmente não são uma boa opção para ambientes de não produção, a menos que os recursos oferecidos sejam os mesmos que o ambiente de produção oferece. Isso ocorre porque os locatários geralmente desejam testar e fornecer treinamento sobre todos os mesmos recursos que estão disponíveis para eles em produção.

Modelos de preço não lucrativo

Um modelo de preços não lucrativo custa mais para entregar o serviço do que a receita que você ganha. Por exemplo, você pode cobrar uma taxa fixa por locatário sem limites para seu serviço, mas criar o serviço com recursos do Azure baseados em consumo e sem limites de uso por locatário. Nessa situação, você pode estar em risco de seus locatários usarem o serviço em excesso e, portanto, torná-lo pouco rentável para atendê-los.

Em geral, você deseja evitar modelos de preço não lucrativos. No entanto, há situações em que você pode optar por adotar um modelo de preços não lucrativo, incluindo:

• Um serviço gratuito está sendo oferecido para habilitar o crescimento.
• Fluxos de receita adicionais são fornecidos por serviços ou recursos de complemento.
• Hospedar um locatário específico fornece outro valor comercial, como usá-los como um locatário âncora em um novo mercado.

No caso de você criar inadvertidamente um modelo de preços não lucrativo, há algumas maneiras de reduzir os riscos associados a eles, incluindo:

• Limitar o uso do serviço por meio de limites de uso.
• Exigir o uso de reservas de capacidade.
• Solicitar que o locatário mude para uma camada de serviço ou recurso mais alta.

Modelos de preço arriscados

Ao implementar um modelo de preços para uma solução, você geralmente precisará fazer suposições sobre como ele será usado. Se essas suposições forem incorretas ou os padrões de uso forem alterados ao longo do tempo, o modelo de preços poderá se tornar pouco lucrativo. Modelos de preço que correm o risco de se tornarem não lucrativos são conhecidos como modelos de preço arriscados. Por exemplo, se você adotar um modelo de preços que espera que os usuários limitem automaticamente o valor que usam sua solução, talvez tenha implementado um modelo de preços arriscado.

A maioria das soluções de SaaS adicionará novos recursos regularmente. Isso aumenta o ROV para os usuários, o que também pode levar a aumentos na quantidade em que a solução é usada. Isso pode resultar em uma solução que se torna pouco lucrativa, se o uso de novos recursos impulsiona o uso, mas o modelo de preços não considera isso.

Por exemplo, se você introduzir um novo recurso de upload de vídeo à sua solução, que usa um recurso baseado em consumo, e a aceitação do usuário do recurso for maior do que o esperado, considere uma combinação de limites de uso e preço a nível de serviço e recurso.

Limites de uso

Limites de uso permitem que você restrinja o uso do serviço para impedir que seus modelos de preços se tornem não lucrativos ou para impedir que um único locatário consuma uma quantidade desproporcional da capacidade do serviço. Isso pode ser especialmente importante em serviços multilocatários, em que um único locatário pode afetar a experiência de outros locatários consumindo muitos recursos.

Observação

É importante informar os clientes de que você aplica limites de uso. Se você implementar limites de uso sem informar os clientes sobre o limite, poderá resultar em insatisfação do cliente. Isso significa que é importante identificar e planejar limites de uso antecipadamente. A meta deve ser planejar o limite e comunicar os limites aos clientes antes que eles se tornem necessários.

Os limites de uso geralmente são usados em combinação com o preço no nível de serviço e recurso, para fornecer uma quantidade maior de uso em camadas mais altas. Os limites também serão geralmente usados para proteger componentes principais que causarão gargalos do sistema ou problemas de desempenho, se forem consumidos demais.

Limites de taxa

Uma maneira comum de aplicar um limite de uso é adicionar limites de taxa às APIs ou funções de aplicativo específicas. Isso também é conhecido como limitação. Os limites de taxa impedem o uso excessivo contínuo. Eles geralmente são usados para limitar o número de chamadas a uma API, durante um período definido. Por exemplo, uma API pode ser chamada apenas 20 vezes por minuto e retornará um erro HTTP 429, se for chamada com uma frequência maior.

Algumas situações em que a limitação de taxa é frequentemente usada incluem:

• APIs REST.
• Tarefas assíncronas.
• Tarefas que não diferenciam o tempo.
• Ações que incorrem em um alto custo a ser executado.
• Geração de relatórios.

Implementar a limitação de taxa pode aumentar a complexidade da solução, mas serviços como o Gerenciamento de API do Azure podem tornar isso mais simples aplicando políticas de limite de taxa.

Ciclo de vida do modelo de preços

Como qualquer outra parte da sua solução, os modelos de preço têm um ciclo de vida. Conforme seu aplicativo evolui ao longo do tempo, talvez seja necessário alterar seus modelos de preço. Isso pode ser impulsionado pela alteração das necessidades do cliente, dos requisitos comerciais ou das alterações na funcionalidade em seu aplicativo. Algumas alterações comuns no ciclo de vida dos preços incluem o seguinte:

• Adicionar um modelo de preços completamente novo. Por exemplo, adicionar um modelo de preços de consumo a uma solução que atualmente oferece um modelo de taxa fixa.
• Desativar um modelo de preços existente.
• Adicionar uma camada a um modelo de preços existente.
• Desativar uma camada em um modelo de preços existente.
• Alterar os limites de uso em um recurso de um modelo de preços.
• Adicionar ou remover recursos de um modelo de preços de nível de serviço e recursos.
• Alterar de um modelo comercial B2C (empresa para consumidor) para um modelo comercial B2B (empresa para empresa). Essa alteração exige novas estruturas de preços para seus clientes comerciais.

Geralmente, é complexo implementar e gerenciar muitos modelos de preços diferentes ao mesmo tempo. Também é confuso para os clientes. Portanto, é melhor implementar apenas um ou dois modelos, com um pequeno número de camadas. Isso torna sua solução mais acessível e fácil de gerenciar.

Observação

Modelos de preços e funções de cobrança devem ser testados, idealmente usando testes automatizados, assim como qualquer outra parte do sistema. Quanto mais complexos forem os modelos de preços, mais testes serão necessários e, portanto, o custo de desenvolvimento e novos recursos aumentará.

Ao alterar modelos de preços, você precisará considerar os seguintes fatores:

• Os locatários desejarão migrar para o novo modelo?
• É fácil para os locatários migrar para o novo modelo?
• Os novos modelos de preços expõem seu serviço a riscos? Por exemplo, você está removendo limites de taxa que estão atualmente protegendo recursos críticos contra o uso excessivo?
• Os locatários têm um caminho claro para migrar para o novo modelo de preços?
• Como você impedirá que os locatários usem modelos de preços mais antigos para que seja possível desativá-los?
• Os locatários poderão ter um choque de cobrança (uma reação negativa a uma fatura inesperada) ao alterar modelos de preços?
• Você está monitorando o desempenho e a utilização de seus serviços para modelos de preços novos ou alterados para garantir a rentabilidade contínua?
• Você consegue comunicar claramente o ROV para novos modelos de preços para seus locatários existentes?

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Daniel Scott-Raynsford | Estrategista de Tecnologia Do Parceiro

Outros colaboradores:

• Bohdan Cherchyk | Engenheiro de Cliente Sênior da FastTrack para Azure
• John Downs | Engenheiro de software principal
• Chad Kittel | Engenheiro de Software Principal
• Paolo Salvatori | Engenheiro de Cliente Principal, FastTrack for Azure
• Arsen Vladimirskiy | Engenheiro de Cliente Principal, FastTrack for Azure

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Considere como você medirá o consumo por locatários em sua solução.