Измерване на потреблението и ценообразуване: инженерство срещу финанси

Въведение

Ценообразуването на базата на потреблението и хибридното ценообразуване рядко са статични. Когато логиката на ценообразуването е твърдо кодирана, всяка промяна в нивото или кредитния лимит се превръща в техническа заявка. Това забавя финансовия отдел и е изнервящо за разработчиците. Кой тогава трябва да отговаря за измерването на потреблението и ценообразуването, базирано на него? Нека да разберем.

Защо промените в ценообразуването са вече чести

Ценообразуването вече не е решение, което се взема веднъж и завинаги. Докладът за ценообразуването в SaaS и AI на консултантската фирма hy и OMR Reviews, цитиращ данни от Growth Unhinged, сочи, че три от четири софтуерни компании в САЩ са променили цените си през изминалата година. Това е значителна промяна.

Моделите също се променят. В проучването на hy сред 180 софтуерни компании 37% вече използват модели, базирани на използването, а 59% комбинират повече от един показател за ценообразуване, като например таксуване на потребител заедно с обема на API. Добавяне на кредити, провеждане на експерименти, оптимизиране на пакетите – промените се превръщат в норма, а не в изключение.

Как логиката на ценообразуването става собственост на инженерите

Обикновено това се случва случайно. В началото някой разработчик кодира твърдо даден показател: преброява API-извикванията, прилага тарифа и изпраща общата сума към фактурата. Работи, така че никой не го поставя под въпрос.

След това ценообразуването се развива. Нов ценови план, безплатен лимит или различна тарифа за надхвърляне означава, че някой подава заявка, чака място в спринта и се надява, че пускането на версията няма да наруши фактурирането. Времето за изпълнение се удължава и всяко пускане на версия носи известен риск. Финансовият отдел в крайна сметка чака на опашка, която не контролира.

Хибридните модели влошават ситуацията. Колкото повече компоненти има една цена, толкова повече места в кода може да се скрие дадена промяна.

Цената на ценообразуването, управлявано от инженерите

Разходите са реални, дори и без електронна таблица, която да ги докаже.

• Бавно внедряване: Една идея за ценообразуване може да остане на заден план в продължение на седмици, докато се работи по продукта.
• Грешки: Логиката, скрита в кода, е трудна за разчитане от финансовия отдел, поради което грешките често се проявяват във фактурите.
• Слепи точки във финансовия отдел: Ако финансовият отдел не може да види как е изчислена дадена цифра, разрешаването на споровете отнема повече време.
• Алтернативни разходи: Инженерите поддържат кода за фактуриране, вместо да разработват продукта.

Ето моето мнение: ако промяната в цената изисква внедряване на код, ценообразуването ви се движи със скоростта на календара ви за пускане на версии, а не със скоростта на пазара

За какво трябва да отговаря отделът по финанси и за какво – инженерният екип

Отговорността не е „или-или“. Разделете я според типа на решението.

Инженерният екип отговаря за инструментацията на събитията, потоците от данни и точността на данните за използването при източника.

Финансовият отдел и продуктовият екип отговарят за дефинициите на метриките, ценовите нива, пакетите и кредитите.

Ето един прост тест. Ако промяната засяга това, което се събира, тя е от компетенцията на инженерния отдел. Ако засяга начина, по който събраните данни за използването се превръщат в пари, тя е от компетенцията на финансовия отдел и продуктовия екип. Например, решението даден план да включва 1 500 API извиквания вместо 1 000 е решение, свързано с ценообразуването. Увереността, че всяко извикване се регистрира точно веднъж, е инженерно решение.

Управление на промените в ценообразуването

Предаването на контрола без предпазни мерки води до хаос. Това са общи най-добри практики, които не са свързани с конкретен инструмент:

• Одобрения: Изисквайте конкретно одобрение от финансовия отдел и екипа по продукта, преди промяната да влезе в сила.
• Тестване: Преглед на ефекта върху реалните данни за използване преди пускането в експлоатация.
• Версии: Поддържайте версии на всяка ценова конфигурация, за да можете да сравнявате версиите или да се върнете към предишна версия.
• Дати на влизане в сила: Определете кога се прилага дадена промяна и как се третира вече регистрираното използване в средата на цикъла.
• Одитна следа: Записвайте кой какво е променил и кога.

Помислете за това като за преглед на кода при ценообразуването. Никой не пуска код без втори поглед, а цените заслужават същото внимание.

Предпоставки за ценообразуване, ръководено от финансовия отдел

Финансовият отдел не може да притежава това, на което не може да се довери. На първо място са три основи.

Чисти данни за използването. Дублираните или липсващите събития подкопават всяка цена, която определите въз основа на тях.

Съгласувани дефиниции на показателите. Ако продуктовият отдел дефинира „активен потребител“ по един начин, а финансовият – по друг, фактурите ви ще решат спора вместо вас, и то не по най-приятния начин.

Надеждни източници. Данните за използването обикновено се съхраняват в хранилище за данни, зад API или във файлове. Изберете една система за записване на данни за всеки показател и се придържайте към нея.

Въпроси, които да зададете, преди да прехвърлите отговорността за ценообразуването

Съберете финансовия директор, ръководителя на продуктовия екип и ръководителя на инженерния екип в една стая и обсъдете следните въпроси:

1. Какви промени в ценообразуването направихме миналата година и колко време отне въвеждането на всяка от тях?
2. Има ли всяка фактурируема метрика едно общоприето определение?
3. Може ли финансовият отдел да проследи как даден показател за използване се е превърнал в ред във фактурата?
4. Кой одобрява промяната и как я тестваме, преди да влезе в сила?
5. Къде се съхраняват данните за използването и кой отговаря за тяхната точност?

Ако не можете да отговорите на два или три от тях, това е вашата отправна точка.

Промяна на ценообразуването без преработване на системата за измерване

Тук инструментите могат да помогнат. Според страницата на Zenskar за измерване на потреблението екипите могат да дефинират метриките за фактуриране на прост език и да позволят на изкуствения интелект да напише логиката за агрегиране, или да напишат персонализиран SQL код за сложна логика. Данните за потреблението могат да се извличат от източници като Postgres, Athena и MySQL, да се предават чрез API или да се качват като CSV файл. Една и съща метрика може да се използва повторно за различни продукти, договори и позиции.

Важното за собствеността е, че софтуерът за фактуриране на базата на потреблението трябва да позволява промяна на ценовите нива, надхвърлянията и честотата на фактуриране независимо от потреблението. Логиката на фактуриране може да се променя и в средата на цикъла, без да се нарушава потока от данни. Един-единствен показател може да задвижва различни ценови модели в различните договори, като поддържа стабилно измерване, докато ценообразуването се развива.

Заключение

Най-здравословният модел е споделеният. Инженерният екип поддържа точността и потока на данните за използването. Финансовият екип и екипът по продуктите определят стойността на тези данни в рамките на ясно управление. Коя промяна в ценообразуването ви очаква в инженерната ви опашка в момента?

Ключови изводи:

• Твърдо кодираните цени превръщат всяко променяне на нивото или кредита в заявка към инженерния екип.
• Разделете отговорността според типа на решението: инженерният екип отговаря за събирането и точността на данните за използването, докато финансовият екип и екипът по продукта отговарят за дефинициите на показателите, ценовите нива, пакетите и кредитите.
• Първо въведете предпазни мерки: одобрения, тестване, версии, дати на влизане в сила и одитна следа.
• Ценообразуването, ръководено от финансовия отдел, се нуждае от чисти данни за използването, съгласувани дефиниции на показателите и една система за записване на данните за всеки показател.
• Използвайте петте въпроса преди предаването на проекта, за да намерите отправната си точка.
• Изберете инструменти, които позволяват промяна на ценообразуването, без да се налага преизграждане на системата за измерване.