Модели ценообразования для мультитенантного решения

Хорошая модель ценообразования гарантирует, что вы остаетесь прибыльным по мере роста числа клиентов и при добавлении новых функций. Важно учитывать при разработке коммерческого мультитенантного решения, чтобы разработать модели ценообразования для вашего продукта. На этой странице мы предоставляем рекомендации для технических лиц, принимающих решения о моделях ценообразования, которые можно рассмотреть и о компромиссах.

При определении модели ценообразования для вашего продукта необходимо сбалансировать рентабельность стоимости (ROV) для клиентов с стоимостью проданных товаров (COGS) для доставки услуги. Предложение более гибких коммерческих моделей (для решения) может увеличить ROV для клиентов, но также может увеличить архитектуру и коммерческую сложность решения (и, следовательно, увеличить COGS).

Некоторые важные аспекты, которые следует учитывать при разработке моделей ценообразования для решения, приведены ниже.

• Будет ли COGS выше прибыли, полученной от решения?
• Может ли COGS меняться со временем на основе роста пользователей или изменений в шаблонах использования?
• Насколько сложно измерять и записывать сведения, необходимые для работы с моделью ценообразования? Например, если вы планируете выставлять счета клиентам на основе количества вызовов API, которые они делают, вы определили, как измерять вызовы API, сделанные каждым клиентом?
• Зависит ли ваша прибыльность от обеспечения того, чтобы клиенты использовали ваше решение в ограниченном порядке?
• Если клиент перепользовал решение, это означает, что вы больше не прибыльны?

Существуют некоторые ключевые факторы, влияющие на прибыльность:

• Модели цен на службы Azure. Модели ценообразования служб Azure или сторонних служб, составляющих ваше решение, могут повлиять на прибыльные модели.
• Шаблоны использования служб. Пользователям может потребоваться только доступ к решению в рабочее время или может быть только небольшая доля пользователей с большим объемом. Можно ли сократить количество COGS, уменьшая неиспользуемую емкость при низком использовании?
• Рост хранилища. Большинство решений накапливают данные с течением времени. Больше данных означает более высокую стоимость хранения и защиты, что снижает рентабельность каждого клиента. Можно ли задать квоты хранилища или применить период хранения данных?
• Изоляция клиентов. Модель аренды, используемая, влияет на уровень изоляции, который у вас есть между клиентами. Если вы предоставляете общий доступ к ресурсам, необходимо рассмотреть, как клиенты могут чрезмерно использовать или злоупотреблять службой? Как уровень изоляции клиента влияет на работу COGS и производительность для всех пользователей? Некоторые модели ценообразования не являются прибыльными без дополнительных элементов управления распределением ресурсов. Например, может потребоваться реализовать регулирование служб, чтобы обеспечить устойчивость модели ценообразования с фиксированной ставкой.
• Жизненный цикл клиента. Например, решения с высоким уровнем скорости обработки клиентов или услуги, требующие большей нагрузки на борту, могут страдать от снижения рентабельности, особенно если они оцениваются с помощью модели на основе потребления.
• Требования к уровню обслуживания. Клиенты, требующие более высокого уровня обслуживания, могут означать, что ваше решение больше не выгодно. Очень важно, чтобы вы четко узнали о ожиданиях уровня обслуживания клиентов и любых обязательствах, которые у вас есть, чтобы вы могли планировать модели ценообразования соответствующим образом.

Распространенные модели ценообразования

Существует множество распространенных моделей ценообразования, которые часто используются с мультитенантными решениями. Каждая из этих моделей ценообразования связана с коммерческими преимуществами и рисками и требует дополнительных архитектурных рекомендаций. Важно понимать различия между этими моделями ценообразования, чтобы гарантировать, что решение остается прибыльным по мере развития.

Примечание.

Вы можете предложить несколько моделей для решения или объединить модели вместе. Например, можно предоставить модель для каждого пользователя для клиентов, имеющих довольно стабильные номера пользователей, и вы также можете предложить модель потребления для клиентов, которые имеют изменяющиеся шаблоны использования.

Цены на основе потребления

Модель потребления иногда называется оплатой по мере использования или PAYG. По мере увеличения использования вашей службы ваш доход увеличивается:

При измерении потребления можно учитывать простые факторы, такие как объем данных, добавляемых в решение. Кроме того, можно рассмотреть сочетание атрибутов использования вместе. Модели потребления предлагают множество преимуществ, но их может быть трудно реализовать в мультитенантном решении.

Преимущества. С точки зрения клиентов, есть минимальные предварительные инвестиции, необходимые для использования вашего решения, чтобы эта модель имеет низкий барьер для входа. С точки зрения оператора службы затраты на размещение и управление увеличиваются по мере использования клиентов и увеличения доходов. Это увеличение может сделать его высокомасштабируемой моделью ценообразования. Модели ценообразования потребления работают особенно хорошо, когда службы Azure, используемые в решении, также основаны на потреблении.

Сложность и операционные затраты. Модели потребления зависят от точных измерений использования и разделения этого использования по клиенту. Это может быть сложно, особенно в решении с множеством распределенных компонентов. Необходимо хранить подробные записи потребления для выставления счетов и аудита, а также предоставлять клиентам методы для получения доступа к их данным потребления.

Риски: цены на потребление могут мотивировать ваших клиентов сократить их использование системы, чтобы снизить их затраты. Кроме того, модели потребления приводят к непредсказуемым потокам доходов. Это можно устранить, предлагая резервирования емкости, где клиенты платят за некоторый уровень потребления заранее. Вы, как поставщик услуг, можете использовать этот доход для инвестиций в улучшение решения, чтобы уменьшить операционные затраты или увеличить рентабельность стоимости, добавив функции.

Примечание.

Реализация и поддержка резервирования емкости могут повысить сложность процессов выставления счетов в приложении. Кроме того, вам может потребоваться рассмотреть вопрос о том, как клиенты получают возмещение или обмениваются резервированиями емкости, и эти процессы также могут добавлять коммерческие и операционные проблемы.

Цены для одного пользователя

Модель ценообразования для каждого пользователя включает в себя зарядку клиентов на основе количества пользователей, использующих службу, как показано на следующей схеме.

Модели ценообразования для каждого пользователя очень распространены из-за простоты реализации в мультитенантном решении. Однако они связаны с несколькими коммерческими рисками.

Преимущества. При выставлении счетов за каждого пользователя легко вычислить и прогнозировать поток доходов. Кроме того, при условии, что у вас есть довольно согласованные шаблоны использования для каждого пользователя, доход увеличивается на том же уровне, что и внедрение служб, что делает эту масштабируемую модель.

Сложность и операционные затраты: модели для каждого пользователя, как правило, легко реализовать. Однако в некоторых ситуациях необходимо измерять потребление для каждого пользователя, что может помочь вам убедиться, что COGS для одного пользователя остается прибыльным. Измеряя потребление и связывая его с определенным пользователем, вы можете увеличить операционную сложность решения.

Риски: различные шаблоны потребления пользователей могут привести к снижению рентабельности. Например, тяжелые пользователи решения могут стоить больше, чем легкие пользователи. Кроме того, фактический возврат стоимости (ROV) для решения не отражается фактическим количеством приобретенных лицензий пользователей.

Цены на пользователей для каждого активного пользователя

Эта модель аналогична ценам на пользователя, но не требует предварительного обязательства от клиента по количеству ожидаемых пользователей, клиент взимается только за пользователей, которые фактически входят и используют решение в течение определенного периода (как показано на следующей схеме).

Это можно измерять в любом периоде. Ежемесячные периоды являются общими, а затем эта метрика часто записывается как ежемесячные активные пользователи или MAU.

Преимущества: с точки зрения клиентов, эта модель требует низкой инвестиции и риска, так как есть минимальный объем отходов; неиспользуемые лицензии не оплачиваются. Это делает его особенно привлекательным при маркетинге решения или росте решения для крупных корпоративных клиентов. С точки зрения владельца службы ваш ROV более точно отражается на клиенте по количеству ежемесячных активных пользователей.

Сложность и операционные затраты: для каждой активной модели пользователей требуется записать фактическое использование и сделать его доступным для клиента в рамках счета. Измерение потребления для каждого пользователя помогает гарантировать, что прибыльность поддерживается с помощью COGS для одного пользователя, но опять же требуется дополнительная работа для измерения потребления для каждого пользователя.

Риски. Как и для каждого пользователя, существует риск того, что различные шаблоны потребления отдельных пользователей могут повлиять на прибыльность. По сравнению с ценами на пользователя, модели для каждого активного пользователя имеют менее прогнозируемый поток доходов. Кроме того, цены на скидки не обеспечивают полезный способ стимулирования роста.

Цены на единицу

Во многих системах число пользователей не является элементом, который имеет наибольшее влияние на общий COGS. Например, в решениях, ориентированных на устройства, также называемых Интернетом вещей или Интернета вещей, число устройств часто оказывает наибольшее влияние на COGS. В этих системах можно использовать модель ценообразования на единицу, где определяется единица, например устройство. Рассмотрим схему ниже.

Кроме того, некоторые решения имеют очень переменные шаблоны использования, где небольшое количество пользователей оказывает непропорциональное влияние на COGS. Например, в решении, проданном кирпичным и минометным розничным торговцам, может оказаться подходящим модель ценообразования на магазин.

Преимущества. В системах, где отдельные пользователи не оказывают значительного влияния на COGS, цены на единицу лучше представить реальность масштабирования системы и результирующего влияния на COGS. Кроме того, он может улучшить выравнивание фактических шаблонов использования для клиента. Для многих решений Интернета вещей, где каждое устройство создает прогнозируемый и постоянный объем потребления, это может быть эффективная модель для масштабирования роста решения.

Сложность и операционные затраты: как правило, цены на единицу легко реализовать и имеют довольно низкую операционную стоимость. Однако операционные затраты могут стать выше, если необходимо различать и отслеживать использование по отдельным единицам, таким как устройства или розничные магазины. Измерение потребления на единицу помогает обеспечить поддержание рентабельности, так как вы можете определить COGS для одной единицы.

Риски: риски модели ценообразования на единицу аналогичны ценам на пользователя. Различные шаблоны потребления по некоторым единицам могут означать, что у вас снижение рентабельности, например, если некоторые устройства или магазины гораздо более тяжелые пользователи решения, чем другие.

Цены на уровне компонентов и служб

Вы можете предложить решение с различными уровнями функциональности в разных ценовых точках. Например, можно предоставить две ежемесячные цены на плоскую ставку или на единицу, одно из которых является базовым предложением с подмножеством доступных функций, а другое представляет комплексный набор функций вашего решения. Рассмотрим схему ниже.

Эта модель также может предлагать различные соглашения уровня обслуживания для разных уровней. Например, базовый уровень может предложить 99,9 % времени простоя, в то время как уровень "Премиум" может предложить 99,99%. Соглашение об уровне обслуживания (SLA) может быть реализовано с помощью служб и функций, которые обеспечивают более высокие целевые показатели доступности.

Хотя эта модель может быть коммерчески полезной, она требует зрелых инженерных методик, чтобы сделать хорошо. При внимательном рассмотрении эта модель может быть очень эффективной.

Преимущества: цены на основе функций часто привлекательны для клиентов, так как они могут выбрать уровень на основе набора компонентов или уровня обслуживания, который им нужен. Он также предоставляет четкий путь для повышения производительности клиентов с дополнительными функциями или более высокой устойчивостью для тех, кто его требует.

Сложность и операционные затраты: модели ценообразования на основе функций могут быть сложными для реализации, так как им требуется, чтобы ваше решение учитывалось о функциях, доступных на каждой ценовой категории. Переключатели функций могут быть эффективным способом предоставления доступа к определенным подмножествам функций, но это требует постоянного обслуживания. Кроме того, переключатели функций повышают нагрузку, чтобы обеспечить высокое качество, так как для тестирования будет больше путей кода. Для обеспечения более высокого уровня доступности служб на некоторых уровнях может потребоваться дополнительная сложность архитектуры, чтобы обеспечить правильный набор инфраструктуры для каждого уровня, и этот процесс может увеличить эксплуатационные затраты решения.

Риски: модели ценообразования на основе функций могут стать сложными и запутанными, если есть слишком много уровней или вариантов. Кроме того, издержки, связанные с динамическим переключением функций, могут замедлить скорость доставки дополнительных функций.

Цены на Freemium

Вы можете предложить бесплатный уровень службы с базовыми функциями и без гарантий уровня обслуживания. Затем вы можете предложить отдельный платный уровень с дополнительными функциями и официальным соглашением об уровне обслуживания (как показано на следующей схеме).

Бесплатный уровень также может быть предложен как ограниченная временем пробная версия, и во время пробной версии клиенты могут иметь полную или ограниченную функциональность. Это называется моделью freemium, которая фактически является расширением модели ценообразования на основе функций.

Преимущества: это очень легко вывести на рынок решение, когда это бесплатно.

Сложность и операционные затраты: все проблемы сложности и операционные затраты применяются к модели ценообразования на основе функций. Однако вам также необходимо рассмотреть операционные затраты, связанные с управлением бесплатными клиентами. Возможно, потребуется убедиться, что устаревшие клиенты подключены или удалены, и необходимо иметь четкую политику хранения, особенно для бесплатных клиентов. При продвижении клиента на платный уровень может потребоваться переместить клиент между службами Azure, чтобы получить более высокие соглашения об уровне обслуживания. Также важно сохранить данные и конфигурацию клиента при переходе на платный уровень.

Риски. Необходимо обеспечить достаточно высокий уровень ROV для клиентов, чтобы рассмотреть возможность перехода на платную категорию. Кроме того, стоимость предоставления решения клиентам на бесплатном уровне должна быть охвачена прибылью от тех, кто на платных уровнях.

Стоимость проданных товаров

Вы можете выбрать цену вашего решения, чтобы каждый клиент заплатил только стоимость эксплуатации своей доли служб Azure без добавленной прибыли. Эта модель , также называемая сквозной стоимостью или ценами , иногда используется для мультитенантных решений, которые не предназначены для получения прибыли.

Стоимость проданных товаров является хорошим подходом для внутренних мультитенантных решений. Каждое подразделение соответствует клиенту, а затраты на ресурсы Azure должны распределяться между ними. Кроме того, это может быть уместно, если доход является производным от продаж других продуктов и услуг, которые потребляют или расширяют мультитенантное решение.

Преимущества. Поскольку эта модель не включает в себя добавленную маржу для прибыли, стоимость клиентов будет ниже.

Сложность и операционные затраты: как и модель потребления, стоимость проданных товаров зависит от точных измерений использования и разделения этого использования по клиенту. Отслеживание потребления может быть сложной задачей, особенно в решении с множеством распределенных компонентов. Необходимо хранить подробные записи потребления для выставления счетов и аудита, а также предоставлять клиентам методы для получения доступа к их данным потребления.

Для внутренних мультитенантных решений клиенты могут принимать приблизительные оценки затрат и иметь более расслабленные требования к аудиту выставления счетов. Эти расслабленные требования снижают сложность и стоимость работы решения.

Риски: стоимость проданных товаров может мотивировать клиентов сократить их использование системы, чтобы снизить их затраты. Однако, поскольку эта модель используется для приложений, которые не являются центрами прибыли, это может не быть проблемой.

Цены на неструктурированные тарифы

В этой модели плата взимается с плоской ставки клиенту за доступ к решению в течение определенного периода времени. Те же цены применяются независимо от того, сколько они используют службу, количество пользователей, количество устройств, которые они подключаются, или любую другую метрику. Рассмотрим схему ниже.

Это простейшая модель для реализации и понимания клиентами, которую часто запрашивают корпоративные клиенты. Тем не менее, он может легко стать непригодным, если вам нужно продолжать добавлять новые функции или если потребление клиентов увеличивается без дополнительных доходов.

Преимущества: цены на неструктурированные ставки легко продавать, и это легко для ваших клиентов, чтобы понять и бюджет для.

Сложность и операционные затраты. Модели ценообразования с неструктурированными тарифами могут быть легко реализованы, так как для выставления счетов клиентам не требуется никакого измерения или отслеживания потребления. Однако, хотя и не важно, рекомендуется измерять потребление для каждого клиента, чтобы обеспечить точное измерение COGS и обеспечить поддержание рентабельности.

Риски: если у вас есть клиенты, которые используют ваше решение, то это легко для этой модели ценообразования, чтобы стать непригодными.

Цены на скидку

Определив модель ценообразования, вы можете реализовать коммерческие стратегии для стимулирования роста с помощью цен на скидку. Цены на скидку можно использовать с моделями ценообразования на единицу, на пользователя и на единицу.

Примечание.

Цены на скидки обычно не требуют архитектуры, помимо добавления поддержки более сложной структуры выставления счетов. Полное обсуждение коммерческих преимуществ скидки выходит за рамки этого документа.

Распространенные шаблоны ценообразования со скидкой включают:

• Фиксированные цены. Вы имеете одинаковую стоимость для каждого пользователя, единицы или объема потребления, независимо от того, сколько будет приобретено или потребляется. Это самый простой подход. Однако клиенты, которые используют ваше решение, могут почувствовать, что они должны воспользоваться экономией масштаба, получив скидку.
• Экскурсивная цена. По мере приобретения или использования клиентами большего количества единиц вы сокращаете затраты на единицу. Это более привлекательно для клиентов.
• Цены на шаг. Вы сокращаете затраты на единицу, так как клиенты покупают больше. Однако это можно сделать в изменениях на шаге на основе предопределенных диапазонов количества. Например, вы можете взимать более высокую цену для первых 100 пользователей, а затем более низкую цену для 101-го по 200-й пользователь, а затем более низкую цену снова после этого. Это может быть более прибыльным.

На следующей схеме показаны эти шаблоны ценообразования.

Скидки на непроизводственные среды

Во многих случаях клиентам требуется доступ к нерабородной среде, которую они могут использовать для тестирования, обучения или создания собственной внутренней документации. Непроизводственные среды обычно имеют более низкие требования к потреблению и затраты на работу. Например, непроизводственные среды часто не применяются к соглашениям об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания), а ограничения скорости могут быть заданы при более низких значениях. Вы также можете рассмотреть более агрессивный автомасштабирование в службах Azure.

В равной степени клиенты часто ожидают, что непроизводственные среды будут значительно дешевле, чем их производственные среды. Существует несколько вариантов, которые могут быть подходящими, если вы предоставляете непроизводственные среды:

• Предложить уровень freemium, например, вы уже можете сделать для платных клиентов. Это следует тщательно отслеживать, так как некоторые организации могут создавать множество сред тестирования и обучения, которые будут использовать дополнительные ресурсы для работы.

  Примечание.

  Ограниченные по времени пробные версии с использованием уровней freemium обычно не подходят для тестирования и обучения сред. Клиентам обычно требуется, чтобы их нерабоственные среды были доступны в течение всего времени существования рабочей службы.

• Предложить тестовый или учебный уровень службы с более низкими ограничениями использования. Вы можете ограничить доступность этого уровня клиентам, у которых есть существующий платный клиент.
• Предоставление скидки на пользователя, каждого активного пользователя или цену на единицу для непроизводственных клиентов с более низким или без соглашения об уровне обслуживания.
• Для клиентов, использующих цены на плоскую ставку, непроизводственные среды могут быть согласованы в рамках соглашения.

Примечание.

Цены на основе функций обычно не являются хорошим вариантом для непроизводственных сред, если только предлагаемые функции не совпадают с предложениями рабочей среды. Это связано с тем, что клиенты обычно хотят тестировать и предоставлять обучение по всем тем же функциям, которые доступны для них в рабочей среде.

Невыгодные модели ценообразования

Невыгодная модель ценообразования стоит вам больше для доставки услуги, чем доход, который вы зарабатываете. Например, вы можете взимать неструктурированный тариф на каждого клиента без каких-либо ограничений для вашей службы, но затем вы создадите службу с ресурсами Azure на основе потребления и без ограничений на использование клиента. В этой ситуации вы можете столкнуться с риском для клиентов чрезмерного использования службы и, таким образом, что делает его непригодным для их обслуживания.

Как правило, вы хотите избежать непригодных моделей ценообразования. Однако существуют ситуации, когда вы можете принять непригодную модель ценообразования, в том числе:

• Бесплатная служба предлагается для обеспечения роста.
• Дополнительные потоки доходов предоставляются службами или функциями надстроек.
• Размещение конкретного клиента обеспечивает другую коммерческую ценность, например использование их в качестве клиента привязки на новом рынке.

В случае, если вы непреднамеренно создаете неопасную модель ценообразования, существуют некоторые способы устранения рисков, связанных с ними, в том числе:

• Ограничить использование службы с помощью ограничений использования.
• Требовать использования резервирования емкости.
• Запросите перемещение клиента на более высокий уровень функций или уровня служб.

Модели рискованного ценообразования

При реализации модели ценообразования для решения обычно придется делать предположения о том, как она будет использоваться. Если эти предположения оказываются неверными или шаблоны использования изменяются со временем, ваша модель ценообразования может стать невыгодной. Модели ценообразования, которые подвержены риску стать непригодными, называются рискованными моделями ценообразования . Например, если вы внедряете модель ценообразования, которая ожидает, что пользователи самостоятельно ограничивают сумму, которую они используют решение, возможно, вы реализовали рискоемую модель ценообразования.

Большинство решений SaaS регулярно добавляют новые функции. Это увеличивает число ROV для пользователей, что также может привести к увеличению объема используемого решения. Это может привести к тому, что решение становится непригодным, если использование новых функций приводит к использованию, но модель ценообразования не учитывает это.

Например, если вы вводите новую функцию отправки видео в решение, которая использует ресурс на основе потребления, а пользователь обгоняет эту функцию выше ожидаемого, то рассмотрим сочетание ограничений использования и цен на уровень обслуживания.

Ограничения использования

Ограничения использования позволяют ограничить использование службы, чтобы предотвратить убыточные модели ценообразования или запретить одному клиенту использовать непропорциональное количество емкости вашей службы. Это может быть особенно важно в мультитенантных службах, где один клиент может повлиять на опыт других клиентов путем чрезмерного использования ресурсов.

Примечание.

Важно, чтобы ваши клиенты знали, что вы применяете ограничения на использование. Если вы реализуете ограничения использования без того, чтобы ваши клиенты знали об ограничении, это приведет к неудовлетворенности клиентов. Это означает, что необходимо заранее определить и запланировать ограничения использования. Цель состоит в том, чтобы спланировать ограничение, а затем сообщить об ограничениях клиентам, прежде чем они станут необходимыми.

Ограничения использования часто используются в сочетании с ценами на компонент и уровень обслуживания, чтобы обеспечить более высокий объем использования на более высоких уровнях. Ограничения также часто используются для защиты основных компонентов, которые вызывают узкие места в системе или проблемы с производительностью, если они чрезмерно используются.

Ограничения скорости

Распространенный способ применения ограничения использования — добавить ограничения скорости в API или в определенные функции приложения. Это также называется регулированием. Ограничения скорости препятствуют непрерывному чрезмерному использованию. Они часто используются для ограничения количества вызовов API в течение определенного периода времени. Например, API может вызываться только 20 раз в минуту, и он вернет ошибку HTTP 429, если она вызывается чаще, чем это.

Некоторые ситуации, когда часто используется ограничение скорости, включают в себя следующее:

• REST API.
• Асинхронные задачи.
• Задачи, которые не учитывает время.
• Действия, которые повлечет за собой высокую стоимость выполнения.
• Создание отчетов.

Реализация ограничения скорости может увеличить сложность решения, но такие службы, как Azure Управление API, могут сделать это проще, применяя политики ограничения скорости.

Жизненный цикл модели ценообразования

Как и любая другая часть решения, модели ценообразования имеют жизненный цикл. По мере развития приложения с течением времени может потребоваться изменить модели ценообразования. Это может быть вызвано изменением потребностей клиентов, коммерческих требований или изменений функций в приложении. Ниже перечислены некоторые распространенные изменения жизненного цикла ценообразования:

• Добавление совершенно новой модели ценообразования. Например, добавление модели ценообразования на потребление в решение, которое в настоящее время предлагает модель с плоской ставкой.
• Выход из существующей модели ценообразования.
• Добавление уровня в существующую модель ценообразования.
• Выход на пенсию уровня в существующей модели ценообразования.
• Изменение ограничений использования функции в модели ценообразования.
• Добавление или удаление функций из модели ценообразования на уровне обслуживания.
• Переход с коммерческой модели на бизнес-потребитель (B2C) на коммерческую модель бизнес-бизнеса (B2B). Это изменение требует новых структур ценообразования для ваших бизнес-клиентов.

Обычно это сложно реализовать и управлять множеством разных моделей ценообразования одновременно. Это также запутано для ваших клиентов. Поэтому лучше реализовать только одну или две модели с небольшим количеством уровней. Это упрощает управление решением.

Примечание.

Модели ценообразования и функции выставления счетов должны быть протестированы в идеале с помощью автоматизированного тестирования, как и любая другая часть системы. Чем сложнее модели ценообразования, тем больше требуется тестирование, поэтому стоимость разработки и новых функций увеличится.

При изменении моделей ценообразования необходимо учитывать следующие факторы:

• Будут ли клиенты выполнять миграцию в новую модель?
• Легко ли перенести клиентов в новую модель?
• Будут ли новые модели ценообразования предоставлять вашей службе риск? Например, вы удаляете ограничения скорости, которые в настоящее время защищают критически важные ресурсы от чрезмерного использования?
• Есть ли у клиентов четкий путь к миграции в новую модель ценообразования?
• Как предотвратить использование старых моделей ценообразования для клиентов, чтобы вы могли снять их с учета?
• Могут ли клиенты получать шок счета (негативная реакция на непредвиденный счет) при изменении моделей ценообразования?
• Вы отслеживаете производительность и использование служб для новых или измененных моделей ценообразования, чтобы обеспечить постоянную прибыльность?
• Вы можете четко сообщить ROV для новых моделей ценообразования с существующими клиентами?

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

• Даниэль Скотт-Райнсфорд | Стратег технологий партнеров

Другие участники:

• Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
• Джон Даунс | Главный инженер программного обеспечения
• Чад Киттель | Главный инженер программного обеспечения
• Паоло Сальватори | Главный инженер клиента, FastTrack для Azure
• Арсен Владимирский | Главный инженер клиента, FastTrack для Azure

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Рассмотрим способ измерения потребления клиентами в решении.