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

Um bom modelo de preços garante que você permaneça lucrativo à medida que o número de locatários cresce e à medida que você adiciona novos recursos. Uma consideração importante ao desenvolver uma solução comercial multilocatária é como projetar modelos de preços para seu produto. Nesta página, fornecemos orientação para os tomadores de decisão técnica sobre os modelos de preços que você pode considerar e as compensações envolvidas.

Ao determinar o modelo de preços para seu produto, você precisa equilibrar o retorno sobre o valor (ROV) para seus clientes com o custo das mercadorias vendidas (COGS) 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 (e, portanto, também aumentar seu COGS).

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

• O COGS será maior do que o lucro que você ganha com a solução?
• O COGS pode mudar ao longo do tempo, com base no crescimento de usuários ou mudanças nos padrões de uso?
• Quão difícil é medir e registrar as informações necessárias para operar o modelo de precificação? Por exemplo, se você planeja cobrar seus clientes com base no número de chamadas de API que eles fazem, identificou como você mede as chamadas de API feitas por cada cliente?
• A sua rentabilidade depende de garantir que os clientes utilizam a sua solução de forma limitada?
• Se um cliente usa demais a solução, isso significa que você não é mais rentável?

Existem alguns fatores-chave que influenciam a sua rentabilidade:

• Modelos de preços de 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 utilização do serviço. Os usuários podem precisar acessar sua solução apenas durante o horário de trabalho ou podem ter apenas uma pequena porcentagem de usuários de alto volume. Você pode reduzir seu COGS reduzindo a capacidade não utilizada quando seu uso é baixo?
• Crescimento do armazenamento. A maioria das soluções acumula dados ao longo do tempo. Mais dados significam um custo mais alto para armazená-los e protegê-los, reduzindo sua rentabilidade por inquilino. É possível definir cotas de armazenamento ou impor um período de retenção de dados?
• Isolamento do inquilino. O modelo de arrendamento que utiliza afeta o nível de isolamento que tem entre os seus inquilinos. Se você compartilha seus recursos, precisa considerar como os locatários podem utilizar demais ou abusar do serviço? Como o nível de isolamento do locatário afetará seu COGS e o desempenho de todos? Alguns modelos de preços não são rentáveis sem controles adicionais sobre a alocação de recursos. Por exemplo, talvez seja necessário implementar a limitação de serviço para tornar sustentável um modelo de preço fixo.
• Ciclo de vida do inquilino. Por exemplo, soluções com altas taxas de rotatividade de clientes, ou serviços que exigem um maior esforço de integração, podem sofrer menor rentabilidade - especialmente se forem precificadas usando um modelo baseado no consumo.
• Requisitos de nível de serviço. Locatários que exigem níveis mais altos de serviço podem significar que sua solução não é mais lucrativa. É fundamental que você tenha clareza sobre as expectativas de nível de serviço de seus clientes e quaisquer obrigações que tenha, para que possa planejar seus modelos de preços de acordo.

Modelos comuns de preços

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

Nota

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

Preços baseados no consumo

Um modelo de consumo é por vezes referido como pay-as-you-go, ou PAYG. À medida que o uso do seu serviço aumenta, sua receita aumenta:

Ao medir o consumo, você 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 juntos. 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 de seus clientes, há um investimento inicial mínimo necessário para usar sua solução, de modo que esse modelo tenha uma baixa barreira de entrada. Do seu ponto de vista como operador de serviços, os seus custos de alojamento e gestão aumentam à medida que a utilização dos seus clientes e a sua receita aumentam. Esse aumento pode torná-lo um modelo de preços altamente escalá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 no consumo.

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

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

Nota

A implementação e o suporte a reservas de capacidade podem aumentar a complexidade dos processos de faturamento em seu aplicativo. Você também pode precisar considerar como os clientes obtêm reembolsos ou trocam suas reservas de capacidade, e esses processos também podem adicionar desafios comerciais e operacionais.

Preços por utilizador

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

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

Benefícios: Quando você fatura seus 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 este um modelo escalável.

Complexidade e custo operacional: Os 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 lucrativo. Ao medir o consumo e associá-lo a um usuário específico, você pode aumentar a complexidade operacional da sua solução.

Riscos: Diferentes padrões de consumo dos utilizadores podem resultar numa redução da rentabilidade. Por exemplo, usuários pesados da solução podem custar mais para servir do que usuários leves. Além disso, o retorno real sobre o valor (ROV) da solução não é refletido pelo número real de licenças de usuário compradas.

Preços por usuário ativo

Esse modelo é semelhante ao preço por usuário, mas em vez de exigir um compromisso inicial do cliente sobre o número de usuários esperados, o cliente é cobrado apenas pelos usuários que realmente fazem login e usam a solução durante um período (como mostrado no diagrama a seguir).

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

Benefícios: Do ponto de vista dos seus clientes, este modelo requer um baixo investimento e risco, porque há um desperdício mínimo, as licenças não utilizadas não são faturáveis. Isso a torna particularmente atraente ao comercializar a solução ou ao expandi-la para clientes corporativos maiores. Do seu ponto de vista como proprietário do serviço, seu 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 a um cliente como parte da fatura. A medição do 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: Tal como os preços por utilizador, existe o risco de que os diferentes padrões de consumo de utilizadores individuais possam afetar a sua rentabilidade. Em comparação com os preços por usuário, os modelos por usuário ativo têm um fluxo de receita menos previsível. Além disso, os preços com desconto não fornecem uma maneira útil de estimular o crescimento.

Preço unitário

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 para dispositivos, também conhecidas como internet das coisas ou IoT, o número de dispositivos geralmente tem o maior impacto no COGS. Nesses sistemas, um modelo de preço por unidade pode ser usado, onde você define o que é uma unidade , como um dispositivo. Veja o seguinte diagrama.

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

Benefícios: Em sistemas onde 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 se dimensiona e o impacto resultante no COGS. Ele também pode melhorar o alinhamento com os padrões reais de uso para um cliente. Para muitas soluções de IoT, onde cada dispositivo gera uma quantidade previsível e constante de consumo, este pode ser um modelo eficaz para escalar o crescimento da sua solução.

Complexidade e custo operacional: Geralmente, o preço unitário é fácil de implementar e tem um custo operacional bastante baixo. No entanto, o custo operacional pode se tornar maior se você precisar diferenciar e rastrear o uso por unidades individuais, como dispositivos ou lojas de varejo. A medição do consumo por unidade ajuda a garantir que sua rentabilidade seja mantida, uma vez que você pode determinar o COGS para uma única unidade.

Riscos: Os riscos de um modelo de preços unitários são semelhantes aos preços por utilizador. Diferentes padrões de consumo por algumas unidades podem significar que você reduziu a lucratividade, como se alguns dispositivos ou lojas são usuários muito mais pesados da solução do que outros.

Preços baseados em recursos e nível de serviço

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

Esse modelo também pode oferecer diferentes contratos de nível de serviço para diferentes níveis. Por exemplo, seu nível básico pode oferecer 99,9% de tempo de atividade, enquanto um nível premium pode oferecer 99,99%. O contrato de nível de serviço (SLA) mais alto pode ser implementado usando serviços e recursos que permitem metas de disponibilidade mais altas.

Embora este modelo possa ser comercialmente benéfico, ele requer práticas de engenharia maduras para se sair bem. Com uma análise cuidadosa, este modelo pode ser muito eficaz.

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

Complexidade e custo operacional: os 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 faixa de preço. As alternâncias de recursos podem ser uma maneira eficaz de fornecer acesso a determinados subconjuntos de funcionalidades, mas isso requer manutenção contínua. Além disso, as alternâncias de recursos aumentam a sobrecarga para garantir alta qualidade, porque haverá mais caminhos de código para testar. Habilitar metas de maior disponibilidade de serviço em alguns níveis pode exigir complexidade arquitetônica adicional, para garantir que o conjunto certo de infraestrutura seja usado para cada camada, e esse processo pode aumentar o custo operacional da solução.

Riscos: Os modelos de preços baseados em recursos podem se tornar complicados e confusos, se houver muitos níveis ou opções. Além disso, a sobrecarga envolvida na alternância dinâmica de recursos pode diminuir a taxa na qual você fornece recursos adicionais.

Preços Freemium

Você pode optar por oferecer um nível gratuito do seu serviço, com funcionalidade básica e sem garantias de nível de serviço. Em seguida, você pode oferecer um nível pago separado, com recursos adicionais e um contrato formal de nível de serviço (conforme mostrado no diagrama a seguir).

O nível gratuito também pode ser oferecido como uma avaliação por tempo limitado e, durante a avaliação, seus clientes podem ter funcionalidades completas ou limitadas disponíveis. Isso é conhecido como um modelo freemium, que é efetivamente uma extensão do modelo de preços baseado em recursos.

Benefícios: É muito fácil comercializar uma solução quando ela é 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 tem que considerar o custo operacional envolvido no gerenciamento de inquilinos gratuitos. Talvez seja necessário garantir que os locatários obsoletos sejam removidos 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 altos. Também será importante reter os dados e a configuração do locatário ao mudar para uma camada paga.

Riscos: Você precisa garantir que fornece um ROV alto o suficiente para que os locatários considerem mudar para um nível pago. Além disso, o custo de fornecer sua solução aos clientes no nível gratuito precisa ser coberto pela margem de lucro daqueles que estão em níveis pagos.

Preço do custo dos bens vendidos

Você pode optar por precificar sua 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 de passagem ou preço - às vezes é usado para soluções multilocatárias que não se destinam a ser um centro de lucro.

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

Benefícios: Como este modelo não inclui nenhuma margem adicional de lucro, o custo para os inquilinos será menor.

Complexidade e custo operacional: Semelhante ao modelo de consumo, o preço do custo dos bens vendidos depende de medições precisas do uso e da divisão desse uso pelo inquilino. Rastrear o consumo pode ser um desafio, especialmente em uma solução com muitos componentes distribuídos. Você precisa manter registros de consumo detalhados para faturamento e auditoria, bem como fornecer métodos para que os clientes tenham acesso aos seus dados de consumo.

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

Riscos: O preço do custo dos bens vendidos pode motivar os seus inquilinos a reduzir a utilização do seu sistema, de forma a reduzir os 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.

Fixação de preços fixos

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

Este é o modelo mais simples de implementar e para os clientes entenderem, e é frequentemente solicitado por clientes corporativos. No entanto, pode facilmente tornar-se não rentável se precisar de continuar a adicionar novas funcionalidades ou se o consumo do inquilino aumentar sem qualquer receita adicional.

Benefícios: O preço fixo é fácil de vender e é fácil para os seus clientes entenderem e orçamentarem.

Complexidade e custo operacional: Os modelos de preços fixos podem ser fáceis de implementar porque os clientes de faturamento não exigem medição ou rastreamento de consumo. No entanto, embora não seja essencial, é aconselhável medir o consumo por inquilino para garantir que você está medindo o COGS com precisão e para garantir que sua rentabilidade seja mantida.

Riscos: Se você tem inquilinos que fazem uso pesado de sua solução, então é fácil que esse modelo de preços se torne não lucrativo.

Preços com desconto

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

Nota

O preço com desconto normalmente não requer considerações arquitetônicas, além de adicionar suporte para uma estrutura de faturamento mais complexa. Uma discussão completa sobre os benefícios comerciais dos descontos está além do escopo deste documento.

Os padrões comuns de preços de 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. Esta é a abordagem mais simples. No entanto, os clientes que fazem uso intensivo de sua solução podem sentir que devem se beneficiar de economias de escala obtendo um desconto.
• Preços degressivos. À medida que os clientes compram ou consomem mais unidades, você reduz o custo por unidade. Isto é comercialmente mais atraente para os clientes.
• Preços escalonados. Você reduz o custo por unidade, à medida que os clientes compram mais. No entanto, você faz isso em mudanças 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º a 200º usuário e, em seguida, um preço mais baixo novamente depois disso. Isso pode ser mais lucrativo.

O diagrama a seguir ilustra esses padrões de preços.

Descontos em ambiente de não produção

Em muitos casos, os clientes precisam de acesso a um ambiente que não seja de produção que possam usar para testes, treinamento ou para criar sua própria documentação interna. Os ambientes que não são de produção geralmente têm menores requisitos de consumo e custos de operação. Por exemplo, os ambientes que não são de 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 em valores mais baixos. Você também pode considerar um dimensionamento automático mais agressivo em seus serviços do Azure.

Do mesmo modo, os clientes esperam frequentemente que os ambientes de não produção sejam significativamente mais baratos do que os seus ambientes de produção. Há várias alternativas que podem ser apropriadas quando você fornece ambientes que não são de produção:

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

  Nota

  Testes por tempo limitado usando níveis freemium geralmente não são adequados para ambientes de teste e treinamento. Os clientes geralmente precisam que seus ambientes de não produção estejam disponíveis durante a vida útil do serviço de produção.

• Ofereça um nível 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 sejam de produção, com um contrato de nível de serviço menor ou nenhum.
• Para locatários que usam preços fixos, ambientes de não produção podem ser negociados como parte do acordo.

Nota

O preço baseado em recursos geralmente não é uma boa opção para ambientes que não são de 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 querem testar e fornecer treinamento sobre todos os mesmos recursos que estão disponíveis para eles na produção.

Modelos de preços não rentáveis

Um modelo de preços não lucrativo custa mais para fornecer o serviço do que a receita que você ganha. Por exemplo, pode cobrar uma taxa fixa por inquilino sem quaisquer limites para o seu serviço, mas depois criaria o seu serviço com recursos do Azure baseados no consumo e sem limites de utilização por inquilino. Nesta situação, pode correr o risco de os seus inquilinos abusarem do seu serviço e, assim, tornarem não rentável servi-los.

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

• Um serviço gratuito está sendo oferecido para permitir o crescimento.
• Fluxos de receita adicionais são fornecidos por serviços ou recursos complementares.
• Hospedar um inquilino específico fornece outro valor comercial, como usá-lo 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 mitigar os riscos associados a eles, incluindo:

• Limitar a utilização do serviço através de limites de utilização.
• Exigir o uso de reservas de capacidade.
• Solicite que o locatário mude para um recurso ou camada de serviço superior.

Modelos de preços arriscados

Ao implementar um modelo de preços para uma solução, você geralmente terá que fazer suposições sobre como ele será usado. Se essas suposições se revelarem incorretas ou se os padrões de uso mudarem ao longo do tempo, seu modelo de preços pode se tornar não lucrativo. Os modelos de preços que correm o risco de se tornarem não rentáveis são conhecidos como modelos de preços arriscados. Por exemplo, se você adotar um modelo de preços que espera que os usuários autolimitem a quantidade que usam sua solução, talvez você tenha implementado um modelo de preços arriscado.

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

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

Limites de utilização

Os limites de utilização permitem-lhe restringir a utilização do seu serviço para evitar que os seus modelos de preços se tornem não rentáveis ou para impedir que um único inquilino consuma uma quantidade desproporcionada da capacidade do seu serviço. Isso pode ser especialmente importante em serviços multilocatário, onde um único locatário pode afetar a experiência de outros locatários consumindo recursos em excesso.

Nota

É importante conscientizar seus clientes de que você aplica limites de uso. Se você implementar limites de uso sem conscientizar seus clientes sobre o limite, isso resultará em insatisfação do cliente. Isso significa que é importante identificar e planejar os limites de uso com antecedência. O objetivo deve ser planejar o limite e, em seguida, comunicar os limites aos clientes antes que eles se tornem necessários.

Os limites de uso geralmente são usados em combinação com preços de recursos e nível de serviço, para fornecer uma quantidade maior de uso em níveis mais altos. Os limites também são comumente usados para proteger componentes principais que causarão gargalos do sistema ou problemas de desempenho, se forem consumidos em excesso.

Limites de taxa

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

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

• APIs REST.
• Tarefas assíncronas.
• Tarefas que não são sensíveis ao tempo.
• Ações que incorrem em um alto custo de execução.
• Geração de relatórios.

A implementação da limitação de taxa pode aumentar a complexidade da solução, mas serviços como o Gerenciamento de API do Azure podem simplificar isso 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ços têm um ciclo de vida. À medida que seu aplicativo evolui ao longo do tempo, talvez seja necessário alterar seus modelos de preços. Isso pode ser impulsionado por mudanças nas necessidades do cliente, requisitos comerciais ou alterações na funcionalidade do seu aplicativo. Algumas alterações comuns do ciclo de vida dos preços incluem o seguinte:

• Adicionando 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.
• Desativação de um modelo de preços existente.
• Adicionar uma camada a um modelo de preços existente.
• Desativação de um nível em um modelo de preços existente.
• Alterar os limites de utilização de uma funcionalidade num modelo de preços.
• Adicionar ou remover recursos de um modelo de preços de recurso e nível de serviço.
• Mudança de um modelo comercial business-to-consumer (B2C) para um modelo comercial business-to-business (B2B). Esta alteração exige novas estruturas de preços para os seus clientes empresariais.

Geralmente, é complexo implementar e gerenciar muitos modelos de preços diferentes ao mesmo tempo. Também é confuso para os seus 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.

Nota

Os modelos de preços e as funções de faturamento devem ser testados, idealmente usando testes automatizados, assim como qualquer outra parte do seu 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 os modelos de preços, você precisará considerar os seguintes fatores:

• Os inquilinos vão querer migrar para o novo modelo?
• É fácil para os inquilinos migrarem para o novo modelo?
• Os novos modelos de preços exporão o seu serviço a riscos? Por exemplo, você está removendo limites de taxa que atualmente estão protegendo recursos críticos contra uso excessivo?
• Os inquilinos têm um caminho claro para migrar para o novo modelo de preços?
• Como você vai evitar que os inquilinos usem modelos de preços mais antigos, para que você possa aposentá-los?
• É provável que os inquilinos recebam um choque de fatura (uma reação negativa a uma fatura inesperada) ao mudar os 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 que possa garantir a rentabilidade contínua?
• É capaz de comunicar claramente o ROV para novos modelos de preços, aos seus inquilinos existentes?

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Daniel Scott-Raynsford - Brasil | Estrategista de Tecnologia de Parceiros

Outros contribuidores:

• Bohdan Cherchyk - Brasil | Engenheiro de Clientes Sênior, FastTrack for Azure
• John Downs - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Chade Kittel - Brasil | Engenheiro de Software Principal
• Paolo Salvatori - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure
• Arsen Vladimirskiy - Brasil | Engenheiro de Clientes Principal, FastTrack for Azure

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

Próximos passos

Considere como você medirá o consumo dos lojistas em sua solução.