Modelos de precios para una solución multiinquilino

Un buen modelo de precios garantiza que siga siendo rentable a medida que crece el número de inquilinos y agrega nuevas características. Una consideración importante al desarrollar una solución comercial multiinquilino es cómo diseñar modelos de precios para su producto. En esta página, se proporcionan instrucciones para los responsables de la toma de decisiones técnicas sobre los modelos de precios que puede tener en cuenta y sus contrapartidas.

Al determinar el modelo de precios de su producto, debe equilibrar la rentabilidad del valor (ROV) de los clientes con el coste de bienes vendidos (COGS) para ofrecer el servicio. Ofrecer modelos comerciales más flexibles (para una solución) podría aumentar el ROV para los clientes, pero también podría aumentar la complejidad arquitectónica y comercial de la solución (y, por tanto, también aumentar el COGS).

Algunas consideraciones importantes que debe tener en cuenta al desarrollar modelos de precios para una solución son las siguientes:

• ¿Será el COGS mayor que el beneficio que obtenga de la solución?
• ¿Puede cambiar el COGS con el tiempo, en función del crecimiento de los usuarios o de los cambios en los patrones de uso?
• ¿Qué dificultad tiene medir y registrar la información necesaria para utilizar el modelo de precios? Por ejemplo, si planeas facturar a tus clientes en función del número de llamadas API que realizan, ¿has identificado cómo medirás las llamadas API realizadas por cada cliente?
• ¿Depende su rentabilidad de garantizar que los clientes usen la solución de una manera limitada?
• Si un cliente sobreutiliza la solución, ¿significa que ya no es rentable?

Hay algunos factores clave que influyen en la rentabilidad:

• Modelos de precios de servicios de Azure. Los modelos de precios de los servicios de Azure o de terceros que componen la solución pueden afectar a si los modelos son rentables.
• Patrones de uso de servicio. Es posible que los usuarios solo necesiten acceder a la solución durante su horario laboral o que solo haya un pequeño porcentaje de usuarios de gran volumen. ¿Puede reducir el COGS reduciendo la capacidad sin usar cuando el uso es bajo?
• Crecimiento del almacenamiento. La mayoría de las soluciones acumulan datos a lo largo del tiempo. Más datos significa un mayor coste para almacenarlos y protegerlos, lo que reduce la rentabilidad por inquilino. ¿Puede establecer cuotas de almacenamiento o aplicar un período de retención de datos?
• Aislamiento de inquilinos. El modelo de inquilino que use afecta al nivel de aislamiento que tiene entre los inquilinos. Si comparte sus recursos, ¿debe tener en cuenta la forma en que los inquilinos podrían sobreutiilizar o abusar del servicio? ¿Cómo afectará el nivel de aislamiento de inquilino a los COGS y al rendimiento de todos? Algunos modelos de precios no son rentables sin controles adicionales en torno a la asignación de recursos. Por ejemplo, es posible que deba implementar una limitación del servicio para que un modelo de precios de tarifa plana sea sostenible.
• Ciclo de vida del inquilino. Por ejemplo, las soluciones con altas tasas de abandono de clientes o los servicios que requieren un mayor esfuerzo de incorporación pueden tener una rentabilidad menor, especialmente si su precio depende de un modelo basado en el consumo.
• Requisitos de nivel de servicio. Cuando los inquilinos requieren niveles más altos de servicio, puede significar que la solución ya no es rentable. Es fundamental que tenga claro las expectativas del nivel de servicio de los clientes y las obligaciones que tiene, para que pueda planear los modelos de precios en consecuencia.

Modelos de precios comunes

Hay muchos modelos de precios comunes que a menudo se usan con soluciones multiinquilino. Cada uno de estos modelos de precios tiene ventajas y riesgos comerciales asociados, y requiere consideraciones arquitectónicas adicionales. Es importante comprender las diferencias entre estos modelos de precios, para que pueda asegurarse de que la solución sigue siendo rentable a medida que evoluciona.

Nota

Puede ofrecer varios modelos para una solución o combinar modelos. Por ejemplo, podría proporcionar un modelo por usuario para los clientes que tienen un número de usuarios bastante estable y también puede ofrecer un modelo por consumo para los clientes que tienen patrones de uso fluctuantes.

Precios basados en el consumo

A veces, un modelo por consumo se conoce como pago por uso. A medida que aumenta el uso del servicio, los ingresos aumentan:

Al medir el consumo, puede considerar factores simples, como la cantidad de datos que se agregan a la solución. Como alternativa, puede tomar en consideración una combinación de atributos de uso. Los modelos por consumo ofrecen numerosas ventajas, pero pueden ser difíciles de implementar en una solución multiinquilino.

Ventajas: desde la perspectiva de los clientes, la inversión inicial necesaria para usar la solución es mínima, por lo que la barrera de entrada del modelo es baja. Desde su perspectiva de operador de servicios, los costes de hospedaje y administración aumentan a medida que también aumentan el uso por parte de los clientes y sus ingresos. Este aumento puede convertirlo en un modelo de precios altamente escalable. Los modelos de precios por consumo funcionan especialmente bien cuando los servicios de Azure que se usan en la solución también se basan en el consumo.

Complejidad y coste operativo: los modelos por consumo se basan en medidas precisas del uso y en la división de este uso por inquilino. Puede ser complicado, especialmente en una solución con muchos componentes distribuidos. Debes mantener registros detallados de consumo para fines de facturación y auditoría, así como proporcionar métodos para que los clientes obtengan acceso a sus datos de consumo.

Riesgos: los precios por consumo pueden motivar a los clientes a reducir su uso del sistema, con el fin de reducir sus costes. Además, los modelos por consumo tienen como resultado flujos de ingresos imprevisibles. Se puede mitigar si se ofrecen reservas de capacidad, donde los clientes pagan por adelantado algún nivel de consumo. Usted, como proveedor de servicios, puede usar estos ingresos para invertir en mejoras de la solución, para reducir el coste operativo o para aumentar la rentabilidad del valor mediante la adición de características.

Nota

Implementar y admitir reservas de capacidad puede aumentar la complejidad de los procesos de facturación dentro de la aplicación. Puede que también deba tener en cuenta cómo obtienen los clientes los reembolsos o intercambian sus reservas de capacidad, y estos procesos también pueden agregar desafíos comerciales y operativos.

Precios por usuario

Un modelo de precios por usuario implica cobrar a los clientes en función del número de personas que usan el servicio, como se muestra en el diagrama siguiente.

Los modelos de precios por usuario son muy comunes, debido a la simplicidad de su implementación en una solución multiinquilino. Sin embargo, están asociados a varios riesgos comerciales.

Ventajas: al facturar a los clientes por cada usuario, es fácil calcular y prever el flujo de ingresos. Además, suponiendo que tiene patrones de uso bastante coherentes para cada usuario, los ingresos aumentan a la misma velocidad que la adopción del servicio, lo que lo hace un modelo escalable.

Complejidad y coste operativo: los modelos por usuario tienden a ser fáciles de implementar. Sin embargo, en algunas situaciones, debe medir el consumo por usuario, lo que puede ayudarle a garantizar que el COGS de un solo usuario sigue siendo rentable. Medir el consumo y asociarlo a un usuario determinado, puede aumentar la complejidad operativa de la solución.

Riesgos: los distintos patrones de consumo de usuario pueden dar lugar a una rentabilidad reducida. Por ejemplo, puede costar más de atender a los usuarios con uso intensivo de la solución que a los ligeros. Además, la rentabilidad del valor (ROV) real de la solución no se refleja en el número real de licencias de usuario adquiridas.

Precios por usuario activo

Este modelo es similar al de precios por usuario, pero en lugar de requerir un compromiso inicial del cliente sobre el número de usuarios esperados, solo se cobra al cliente por los usuarios que realmente inician sesión y usan la solución durante un período (como se muestra en el diagrama siguiente).

Puede medir esto en cualquier período que tenga sentido. Los períodos mensuales son habituales y esta métrica se suele registrar como usuarios activos mensuales o MAU.

Ventajas: desde la perspectiva de los clientes, este modelo requiere una inversión y un riesgo bajos, porque el desperdicio es mínimo y las licencias no usadas no son facturables. Esto hace que sea especialmente atractivo al comercializar la solución o al aumentar la solución para clientes empresariales más grandes. Desde la perspectiva del propietario del servicio, el ROV se refleja con más precisión para el cliente por el número de usuarios activos mensuales.

Complejidad y coste operativo: los modelos por usuario activo requieren que registres el uso real y que lo pongas a disposición del cliente como parte de la factura. La medición del consumo por usuario ayuda a garantizar que la rentabilidad se mantiene con el COGS para un solo usuario, pero de nuevo requiere trabajo adicional para medir el consumo de cada usuario.

Riesgos: igual que con los precios por usuario, existe el riesgo de que los distintos patrones de consumo de usuarios individuales puedan afectar a tu rentabilidad. En comparación con los precios por usuario, los modelos por usuario activo tienen un flujo de ingresos menos predecible. Además, los precios con descuento no proporcionan una manera útil de estimular el crecimiento.

Precios por unidad

En muchos sistemas, el número de usuarios no es el elemento que tiene mayor impacto en el COGS general. Por ejemplo, en las soluciones orientadas a dispositivos, también denominadas Internet de las cosas o IoT, el número de dispositivos es lo que suele tener mayor impacto en el COGS. En estos sistemas, se puede usar un modelo de precios por unidad, donde se define qué es una unidad, como un dispositivo. Consulte el diagrama siguiente:

Además, algunas soluciones tienen patrones de uso muy variables, donde un pequeño número de usuarios tiene un impacto desproporcionado en el COGS. Por ejemplo, en una solución que se vende a minoristas físicos, un modelo de precios por tienda podría ser adecuado.

Ventajas: en los sistemas en los que los usuarios individuales no tienen un efecto significativo en el COGS, los precios por unidad son una manera mejor de representar la realidad de cómo se escala el sistema y el impacto resultante en el COGS. También puede mejorar la alineación con los patrones reales de uso de un cliente. Para muchas soluciones de IoT, donde cada dispositivo genera una cantidad predecible y constante de consumo, puede ser un modelo eficaz para escalar el crecimiento de la solución.

Complejidad y coste operativo: por lo general, los precios por unidad son fáciles de implementar y tienen un coste operativo bastante bajo. Sin embargo, el coste operativo puede ser mayor si necesita diferenciar y realizar un seguimiento del uso por unidades individuales, como dispositivos o tiendas minoristas. La medición del consumo por unidad le ayuda a garantizar que se mantiene su rentabilidad, ya que puede determinar el COGS de una sola unidad.

Riesgos: los riesgos de un modelo de precios por unidad son similares a los precios por usuario. Los distintos patrones de consumo de algunas unidades pueden significar que se ha reducido la rentabilidad, por ejemplo, si algunos dispositivos o tiendas son usuarios con un uso más intensivo de la solución que otros.

Precios basados en el nivel de servicio y características

Puede optar por ofrecer la solución con distintos niveles de funcionalidad a distintos precios. Por ejemplo, puede proporcionar dos precios mensuales de tarifa plana o por unidad, uno es una oferta básica con un subconjunto de características disponibles y el otro presenta el conjunto completo de las características de la solución. Consulte el diagrama siguiente:

Este modelo también puede ofrecer contratos de nivel de servicio diferentes para distintos niveles. Por ejemplo, el nivel básico puede ofrecer un tiempo de actividad del 99,9 %, mientras que un nivel prémium puede ofrecer el 99,99 %. El Acuerdo de Nivel de Servicio (SLA) superior puede implementarse mediante servicios y características que permitan destinos de disponibilidad superiores.

Aunque este modelo puede ser beneficioso comercialmente, requiere prácticas de ingeniería maduras para hacerlo bien. Con una consideración cuidadosa, este modelo puede ser muy eficaz.

Ventajas: los precios basados en características suelen ser atractivos para los clientes, ya que pueden seleccionar un nivel en función del conjunto de características o el nivel de servicio que necesiten. También proporciona una trayectoria clara para aumentar las ventas a los clientes con características adicionales o una mayor resistencia para aquellos que lo requieran.

Complejidad y coste operativo: los modelos de precios basados en características pueden ser complejos de implementar, ya que requieren que la solución sea consciente de las características que están disponibles en cada franja de precios. La activación/desactivación de funcionalidad puede ser una manera eficaz de proporcionar acceso a determinados subconjuntos de funcionalidad, pero requiere un mantenimiento continuo. Además, la activación/desactivación de funcionalidades aumenta la sobrecarga para garantizar una alta calidad, ya que habrá más rutas de acceso de código para probar. La habilitación de destinos de disponibilidad de servicio superior en algunos niveles puede requerir una complejidad arquitectónica adicional, para asegurarse de que se usa el conjunto adecuado de infraestructura para cada nivel y este proceso puede aumentar el costo operativo de la solución.

Riesgos: los modelos de precios basados en características pueden resultar complicados y confusos si hay demasiados niveles u opciones. Además, la sobrecarga implicada en la activación/desactivación dinámica de las características puede ralentizar la velocidad a la que se entregan características adicionales.

Precios freemium

Puede optar por ofrecer un nivel gratuito del servicio, con funcionalidad básica y sin garantías de nivel de servicio. Y puede ofrecer un nivel de pago independiente, con características adicionales y un contrato formal de nivel de servicio (como se muestra en el diagrama siguiente).

El nivel gratuito también se puede ofrecer como una evaluación de tiempo limitado y, durante la evaluación, es posible que los clientes tengan disponible la funcionalidad completa o limitada. Esto se conoce como un modelo freemium, que es realmente una extensión del modelo de precios basado en características.

Ventajas: es muy fácil comercializar una solución cuando es gratuita.

Complejidad y coste operativo: se aplican todos los problemas de complejidad y coste operativo del modelo de precios basado en características. Sin embargo, también debe tener en cuenta el coste operativo implicado en la administración de inquilinos gratuitos. Puede que tenga que asegurarse de que los inquilinos se han retirado o eliminado, y debe disponer de una directiva de retención clara, especialmente para los inquilinos gratuitos. Al promover un inquilino a un nivel de pago, es posible que tenga que mover el inquilino entre los servicios de Azure para obtener SLA superiores. También será importante conservar los datos y la configuración del inquilino al pasar a un nivel de pago.

Riesgos: debe asegurarse de que proporciona un ROV lo suficientemente alto para que los inquilinos consideren la posibilidad de cambiar a un nivel de pago. Además, el coste de proporcionar la solución a los clientes en el nivel gratuito debe estar cubierto por el margen de beneficio de los que se encuentran en los niveles de pago.

Precio de costo de los bienes vendidos

Puede optar por cambiar el precio de la solución para que cada inquilino pague solo el costo de funcionamiento de su parte de los servicios de Azure, sin ningún margen de beneficio adicional. Este modelo, también llamado precios o costo de traspaso, a veces se usa para soluciones multiinquilino que no están diseñadas como centro de beneficios.

El modelo de costo de bienes vendidos es una buena opción para las soluciones multiinquilino de uso interno. Cada unidad organizativa corresponde a un inquilino y los costos de los recursos de Azure deben repartirse entre ellos. También puede ser adecuado cuando los ingresos derivan de las ventas de otros productos y servicios que consumen o aumentan la solución multiinquilino.

Ventajas: como este modelo no incluye ningún margen de beneficio adicional, el costo para los inquilinos será menor.

Complejidad y costo operativo: De forma similar al modelo de consumo, el precio de costo de bienes vendidos se basa en medidas precisas de uso y en la división de este uso por inquilino. Hacer el seguimiento del consumo puede ser complicado, especialmente si la solución tiene muchos componentes distribuidos. Debes mantener registros detallados de consumo para fines de facturación y auditoría, así como proporcionar métodos para que los clientes obtengan acceso a sus datos de consumo.

En el caso de las soluciones multiinquilino de uso interno, los inquilinos pueden aceptar estimaciones de costos aproximados y tener requisitos de auditoría de facturación más relajada. Estos requisitos relajados reducen la complejidad y el costo de funcionamiento de la solución.

Riesgos: los precios de costo de bienes vendidos pueden motivar a los clientes a reducir su uso del sistema con el fin de reducir sus costos. Sin embargo, como este modelo se usa para aplicaciones que no son centros de beneficios, tal vez esto no suponga un problema.

Precios de tarifa plana

En este modelo, se cobra una tarifa plana a un inquilino por el acceso a la solución durante un período de tiempo determinado. Los mismos precios se aplican independientemente de cuánto usen el servicio, el número de usuarios, el número de dispositivos que se conectan o cualquier otra métrica. Consulte el diagrama siguiente:

Este es el modelo más sencillo de implementar y que los clientes entienden mejor. A menudo lo solicitan los clientes empresariales. Sin embargo, puede dejar de ser rentable si necesita seguir agregando nuevas características o si el consumo del inquilino aumenta sin ingresos adicionales.

Ventajas: los precios de tarifa plana son fáciles de vender, así como de entender y de presupuestar por los clientes.

Complejidad y coste operativo: los modelos de precios de tarifa plana pueden ser fáciles de implementar porque la facturación a los clientes no requiere medición ni seguimiento del consumo. Sin embargo, aunque no es esencial, es aconsejable medir el consumo por inquilino para asegurarse de que está midiendo el COGS con precisión y que se mantiene su rentabilidad.

Riesgos: si tiene inquilinos que hacen un uso intensivo de la solución, es fácil que este modelo de precios no sea rentable.

Precios con descuento

Una vez que haya definido el modelo de precios, puede optar por implementar estrategias comerciales para incentivar el crecimiento a través de precios con descuento. Los precios con descuento se pueden usar con los modelos de precios por consumo, por usuario y por unidad.

Nota

Los precios con descuento no suelen requerir consideraciones arquitectónicas, más allá de agregar compatibilidad con una estructura de facturación más compleja. La explicación completa de las ventajas comerciales del descuento queda fuera del ámbito de este documento.

Entre los patrones de precios con descuento comunes se incluyen:

• Precio fijo. Tiene el mismo coste por cada usuario, unidad o cantidad de consumo, independientemente de cuánto se compre o consuma. Esta es la opción más sencilla. Sin embargo, a los clientes que hacen un uso intensivo de la solución les puede parecer que deben beneficiarse de las economías de escala mediante un descuento.
• Precios digresivos. A medida que los clientes compran o consumen más unidades, se reduce el costo por unidad. Es más atractivo comercialmente para los clientes.
• Precios en pasos. El coste por unidad se reduce cuando los clientes compran más. Sin embargo, lo hace en cambios de paso, en función de los rangos de cantidades predefinidos. Por ejemplo, puede cobrar un precio superior para los primeros 100 usuarios, un precio más bajo para los usuarios 101 a 200 y, después de esta cantidad, un precio aún más bajo. Esto puede ser más rentable.

En el siguiente diagrama, se ilustra estos patrones de precios.

Descuentos en entornos que no son de producción

En muchos casos, los clientes requieren acceso a un entorno que no sea de producción que pueden usar para pruebas, entrenamiento o para crear su propia documentación interna. Normalmente, los entornos que no son de producción tienen menores requisitos de consumo y costes de funcionamiento. Por ejemplo, los entornos que no son de producción no suelen estar sujetos a Acuerdos de Nivel de Servicio (SLA) y los límites de frecuencia se pueden establecer en valores inferiores. También puede considerar un escalado automático más agresivo en los servicios de Azure.

Del mismo modo, los clientes suelen esperar que los entornos que no son de producción sean significativamente más baratos que sus entornos de producción. Hay varias alternativas que pueden ser adecuadas cuando se proporcionan entornos que no son de producción:

• Ofrezca un nivel freemium, como puede hacer ya para los clientes de pago. Esto debe supervisarse cuidadosamente, ya que algunas organizaciones pueden crear muchos entornos de prueba y entrenamiento, lo que consumirá recursos adicionales para funcionar.

  Nota

  Las evaluaciones de tiempo limitado que usan niveles freemium no suelen ser adecuadas para entornos de prueba y entrenamiento. Normalmente, los clientes necesitan que sus entornos que no son de producción estén disponibles durante la vigencia del servicio de producción.

• Ofrezca un nivel de prueba o entrenamiento del servicio, con límites de uso inferiores. Puede optar por restringir la disponibilidad de este nivel a los clientes que tienen un inquilino de pago.
• Ofrezca precios con descuento por usuario, por usuario activo o por unidad para los inquilinos que no son de producción, con un contrato de nivel de servicio inferior o sin contrato.
• En el caso de los inquilinos que usan precios de tarifa plana, es posible que los entornos que no son de producción se negocien como parte del contrato.

Nota

Los precios basados en características no suelen ser una buena opción para entornos que no son de producción, a menos que las características que se ofrezcan sean las mismas que las que ofrece el entorno de producción. Es así porque los inquilinos normalmente querrán probar y proporcionar entrenamiento sobre las mismas características que tienen disponibles en producción.

Modelos de precios no rentables

En un modelo de precios no rentable, le cuesta más entregar el servicio que los ingresos que obtiene. Por ejemplo, puede cobrar una tarifa plana por inquilino sin límites para el servicio, pero luego crear el servicio con recursos de Azure basados en el consumo y sin límites de uso por inquilino. En esta situación, puede correr el riesgo de que los inquilinos sobreutilicen el servicio y, por lo tanto, hacer que no sea rentable atenderlos.

Por lo general, se quieren evitar modelos de precios no rentables. Sin embargo, hay situaciones en las que puede optar por adoptar un modelo de precios no rentable, entre las que se incluyen:

• Se ofrece un servicio gratuito para permitir el crecimiento.
• Los servicios o características complementarias proporcionan flujos de ingresos adicionales.
• Hospedar un inquilino específico proporciona otro valor comercial, como su uso como inquilino de anclaje en un nuevo mercado.

En el caso de que cree accidentalmente un modelo de precios no rentable, hay algunas maneras de mitigar los riesgos asociados a él, entre las que se incluyen:

• Limite el uso del servicio a través de límites de uso.
• Requiera el uso de reservas de capacidad.
• Solicite que el inquilino se mueva a un nivel de servicio o característica superior.

Modelos de precios de riesgo

Al implementar un modelo de precios para una solución, normalmente tendrás que hacer suposiciones sobre cómo se usará. Si estas suposiciones son incorrectas o los patrones de uso cambian con el tiempo, es posible que el modelo de precios no sea rentable. Los modelos de precios en riesgo de convertirse en no rentables se conocen como modelos de precios de riesgo. Por ejemplo, si adopta un modelo de precios en el que se espera que los usuarios limiten por sí mismos la cantidad de solución que usan, es posible que haya implementado un modelo de precios de riesgo.

La mayoría de las soluciones de SaaS agregarán nuevas características con regularidad. Esto aumenta el ROV para los usuarios, lo que también puede provocar aumentos en la cantidad de solución que se usa. Como resultado, puede que una solución se vuelva no rentable si el uso de las nuevas características impulsa su uso, pero el modelo de precios no lo tiene en cuenta.

Por ejemplo, si introduce una nueva característica de carga de vídeo en la solución, que usa un recurso basado en el consumo, y la utilización por parte del usuario de la característica es mayor de lo esperado, considere una combinación de límites de uso y precios de nivel de servicio y características.

Límites de uso

Los límites de uso permiten restringir el uso del servicio para evitar que los modelos de precios se conviertan en no rentables o para evitar que un solo inquilino consuma una cantidad desproporcionada de la capacidad del servicio. Puede ser especialmente importante en los servicios multiinquilino, donde un único inquilino puede afectar a la experiencia de otros inquilinos al consumir un exceso de recursos.

Nota

Es importante que los clientes conozcan que se aplican límites de uso. Si implementa límites de uso sin comunicárselo a los clientes, provocará su insatisfacción. Lo que significa que es importante identificar y planear los límites de uso con antelación. El objetivo debe ser planear el límite y, a continuación, comunicar los límites a los clientes antes de que sean necesarios.

Los límites de uso se suelen usar en combinación con los precios de nivel de servicio y características para proporcionar una mayor cantidad de uso en niveles superiores. Los límites también se suelen usar para proteger los componentes principales que provocarán cuellos de botella en el sistema o problemas de rendimiento, si se consumen en exceso.

Límites de frecuencia

Una manera común de aplicar un límite de uso es agregar límites de frecuencia a las API o a funciones de aplicación específicas. También se conoce como limitación. Los límites de frecuencia evitan el uso excesivo continuo. A menudo se usan para limitar el número de llamadas a una API, durante un periodo de tiempo definido. Por ejemplo, una API solo se puede llamar 20 veces por minuto y devolverá un error HTTP 429 si se llama con más frecuencia.

Algunas situaciones en las que se suele usar la limitación de frecuencia son las siguientes:

• API de REST.
• Tareas asincrónicas.
• Tareas que no tienen en cuenta el tiempo.
• Acciones que incurren en un alto coste de ejecución.
• Generación de informes.

La implementación de la limitación de frecuencia puede aumentar la complejidad de la solución, pero servicios como Azure API Management pueden simplificarla mediante la aplicación de directivas de límite de frecuencia.

Ciclo de vida del modelo de precios

Al igual que cualquier otra parte de la solución, los modelos de precios tienen un ciclo de vida. A medida que la aplicación evoluciona con el tiempo, es posible que tenga que cambiar los modelos de precios. Esto puede deberse a la modificación de las necesidades del cliente, los requisitos comerciales o los cambios en la funcionalidad dentro de la aplicación. Algunos cambios comunes en el ciclo de vida de los precios son los siguientes:

• Agregar un modelo de precios completamente nuevo. Por ejemplo, la adición de un modelo de precios por consumo a una solución que actualmente ofrece un modelo de tarifa plana.
• Retirar un modelo de precios existente.
• Agregar un nivel a un modelo de precios existente.
• Retirar un nivel a un modelo de precios existente.
• Cambiar los límites de uso de una característica en un modelo de precios.
• Agregar o quitar características de un modelo de precios de nivel de servicio y características.
• Cambio de un modelo comercial de negocio a consumidor (B2C) a un modelo comercial de negocio a negocio (B2B). A continuación, este cambio requiere nuevas estructuras de precios para los clientes empresariales.

Normalmente es complejo implementar y administrar muchos modelos de precios diferentes a la vez. También resulta confuso para los clientes. Por lo tanto, es mejor implementar solo uno o dos modelos, con un pequeño número de niveles. Esto hace que la solución sea más accesible y fácil de administrar.

Nota

Los modelos de precios y las funciones de facturación deben probarse, idealmente mediante pruebas automatizadas, como cualquier otra parte del sistema. Cuanto más complejos son los modelos de precios, más pruebas se requieren, por lo que el coste de desarrollo y nuevas características aumentará.

Al cambiar los modelos de precios, debes tener en cuenta los siguientes factores:

• ¿Querrán los inquilinos migrar al nuevo modelo?
• ¿Resulta fácil para los inquilinos migrar al nuevo modelo?
• ¿Quedará el servicio expuesto a riesgo por los nuevos modelos de precios? Por ejemplo, ¿va a quitar los límites de frecuencia que protegen actualmente los recursos críticos frente al uso excesivo?
• ¿Tienen los inquilinos una trayectoria clara para migrar al nuevo modelo de precios?
• ¿Cómo evitará que los inquilinos usen modelos de precios más antiguos para poder retirarlos?
• ¿Es probable que los inquilinos tengan una reacción de bill shock (una reacción negativa a una factura inesperada) al cambiar los modelos de precios?
• ¿Está supervisando el rendimiento y el uso de los servicios para los modelos de precios nuevos o modificados, de modo que pueda garantizar una rentabilidad continua?
• ¿Puede comunicar claramente el ROV para nuevos modelos de precios a los inquilinos existentes?

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Daniel Scott-Raynsford | Partner Technology Strategist

Otros colaboradores:

• Bohdan Cherchyk | Ingeniero de clientes sénior, FastTrack for Azure
• John Downs | Ingeniero principal de software
• Chad Kittel | Ingeniero principal de software
• Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Considere cómo medirá el consumo de los inquilinos de la solución.