Fogyasztásmérés és árazás: műszaki szempontok kontra pénzügyi szempontok

Bevezetés

A használat alapú és a hibrid árazás ritkán statikus. Ha az árazási logika merev kódolású, akkor a szintek vagy a kreditkeret bármilyen módosítása mérnöki jegyet eredményez. Ez lassítja a pénzügyi folyamatokat és frusztráló a fejlesztők számára. Tehát kinek kellene felelnie a használatmérésért és az arra épülő árazásért? Nézzük meg közelebbről!

Miért változnak manapság olyan gyakran az árak?

Az árazás már nem olyan döntés, amit egyszer meghozunk, és többé nem kell foglalkozni vele. A hy tanácsadó cég és az OMR Reviews által készített SaaS & AI Pricing Report, a Growth Unhinged adataira hivatkozva, azt állítja, hogy az elmúlt évben az amerikai szoftvercégek négyötöde változtatott az árazásán. Ez jelentős változás.

A modellek is változnak. A hy 180 szoftvercéget felölelő felmérése szerint 37%-uk már használ használat alapú modelleket, 59%-uk pedig több árképzési mutatót kombinál, például a felhasználónkénti számlázást az API-forgalommal. Ha ehhez hozzáadjuk a krediteket, a kísérleteket és a csomagok finomítását, a változás inkább a norma lesz, mint a kivétel.

Hogyan kerül az árazási logika a fejlesztők kezébe

Ez általában véletlenül történik. A kezdeti szakaszban egy fejlesztő beépít egy mutatót a kódba: számolja az API-hívásokat, alkalmaz egy díjszabást, és elküldi az összeget a számlára. Működik, így senki sem kérdőjelezi meg.

Aztán az árazás fejlődik. Egy új szint, egy ingyenes keret vagy egy eltérő túllépési díj azt jelenti, hogy valaki jegyet nyit, vár egy sprint-időpontra, és reméli, hogy a kiadás nem zavarja meg a számlázást. Az átfutási idő megnyúlik, és minden kiadás bizonyos kockázatot hordoz magában. A pénzügyi részleg végül egy olyan sorban várakozik, amelyet nem tud irányítani.

A hibrid modellek tovább rontanak a helyzeten. Minél több összetevőből áll egy ár, annál több helyen rejtőzhet el egy változás a kódban.

A mérnökök által irányított árazás költségei

A költségek valósak, még akkor is, ha nincs táblázat, ami alátámasztaná őket.

• Lassú bevezetések: Egy árazási ötlet hetekig háttérbe szorulhat a termékfejlesztési munkák mögött.
• Hibák: A kódba ágyazott logikát a pénzügyi részleg nehezen tudja értelmezni, ezért a hibák gyakran megjelennek a számlákon.
• A pénzügyi részleg „vakfoltjai”: Ha a pénzügyi részleg nem látja, hogyan számították ki egy adott számot, a vitás kérdések megoldása több időt vesz igénybe.
• Alternatív költség: A mérnökök a termék fejlesztése helyett a számlázási kódot karbantartják.

Íme a véleményem: ha egy árváltozáshoz kódkihelyezésre van szükség, akkor az árazás a kiadási naptár sebességével halad, nem pedig a piac sebességével

Mi a pénzügyi részleg és mi a fejlesztői részleg feladata

A felelősség nem kizárólagos. A döntés típusa szerint kell felosztani.

A fejlesztőcsapat felelős az események nyomon követéséért, az adatcsatornákért és a felhasználási adatok forrásnál biztosított pontosságáért.

A pénzügyi és a termékcsapat felelős a mutatók meghatározásáért, az árszintekért, a csomagokért és a kreditekért.

Íme egy egyszerű teszt: ha a változás arra vonatkozik, hogy mit rögzítenek, akkor az a fejlesztés feladata. Ha arra vonatkozik, hogy a rögzített használati adatok hogyan alakulnak át pénzré, akkor az a pénzügy és a termékfejlesztés feladata. Például az a döntés, hogy egy csomag 1 000 helyett 1 500 API-hívást tartalmaz, árképzési döntés. Az, hogy minden hívás pontosan egyszer legyen naplózva, fejlesztési feladat.

Az árváltozások irányítása

Ha korlátok nélkül adjuk át az irányítást, az káoszhoz vezet. Ezek általános bevált gyakorlatok, amelyek nem kötődnek egyetlen eszközhöz sem:

• Jóváhagyások: A változtatások élesítéséhez a pénzügyi és a termékfejlesztési részleg név szerinti jóváhagyása szükséges.
• Tesztelés: A bevezetés előtt ellenőrizze a változás hatását a valós használati adatokon.
• Verziókezelés: Az egyes árképzési konfigurációkat verziószámmal kell ellátni, hogy össze lehessen hasonlítani a verziókat, illetve vissza lehessen állítani a korábbi állapotot.
• Hatálybalépés: Határozzuk meg, mikor lép hatályba a változás, és hogyan kezeljük a ciklus közepén már rögzített használati adatokat.
• Ellenőrzési nyomvonal: Rögzítsük, ki, mit és mikor módosított.

Gondoljunk rá úgy, mint az árazás kódfelülvizsgálatára. Senki sem ad ki kódot anélkül, hogy egy másik szem is átnézné, és az árak is ugyanolyan gondosságot érdemelnek.

A pénzügyi vezetésű árképzés előfeltételei

A pénzügyi részleg nem birtokolhatja azt, amiben nem bízik. Három alapelv az elsődleges.

Tiszta használati adatok. Az ismétlődő vagy hiányzó események aláássák az azok alapján megállapított árakat.

Egyeztetett mutatódefiníciók. Ha a termékfejlesztés egy módon, a pénzügy pedig másképp határozza meg az „aktív felhasználó” fogalmát, a számlák fogják eldönteni a vitát, és nem éppen kedvező módon.

Megbízható források. A használati adatok általában egy adattárházban, egy API mögött vagy fájlokban találhatók. Válasszon ki egy nyilvántartási rendszert minden mutatóhoz, és tartsa be azt.

Kérdések, amelyeket fel kell tenni az árazás felelősségének átruházása előtt

Hívja össze a pénzügyi igazgatót, a termékfejlesztési vezetőt és a műszaki vezetőt egy terembe, és vegyék át a következőket:

1. Milyen árképzési változtatásokat hajtottunk végre tavaly, és mennyi időbe telt mindegyik bevezetése?
2. Minden számlázható mutatóhoz van-e egy egyeztetett definíció?
3. A pénzügyi osztály nyomon tudja követni, hogy egy felhasználási adat hogyan vált számlasorrá?
4. Ki hagyja jóvá a változást, és hogyan teszteljük azt, mielőtt élesben is bevezetjük?
5. Hol tároljuk a felhasználási adatokat, és ki felel azok pontosságáért?

Ha ezek közül kettőre vagy háromra nem tudnak válaszolni, az lesz a kiindulási pontjuk.

Az árazás megváltoztatása a mérési rendszer átalakítása nélkül

Itt jöhetnek jól a megfelelő eszközök. A Zenskar „Usage Metering” (Használatmérő) oldalának leírása szerint a csapatok egyszerű nyelven definiálhatják a számlázható mutatókat, és hagyhatják, hogy a mesterséges intelligencia írja meg az összesítési logikát, vagy komplex logika esetén egyedi SQL-kódot is írhatnak. A használati adatok olyan forrásokból nyerhetők ki, mint a Postgres, az Athena és a MySQL, API-n keresztül továbbíthatók, vagy CSV-fájlként feltölthetők. Ugyanaz a mutató újrahasznosítható termékek, szerződések és tételek között.

Ami a felelősségvállalás szempontjából fontos, az az, hogy a használat alapú számlázási szoftvernek lehetővé kell tennie a díjszintek, a túllépések és a számlázási gyakoriság használattól független módosítását. A számlázási logika a ciklus közepén is módosítható anélkül, hogy megzavarná az adatfolyamatot. Egyetlen mutató támaszthatja alá a különböző szerződésekben alkalmazott különböző árazási modelleket, így a mérési rendszer stabil marad, miközben az árazás változik.

Következtetés

A legegészségesebb modell a megosztott modell. A fejlesztőcsapat gondoskodik a használati adatok pontosságáról és folyamatos áramlásáról. A pénzügyi és a termékcsapat egyértelmű irányelvek keretein belül felel az adatok értékéért. Melyik árazási változtatás vár jelenleg a fejlesztői sorban?

Főbb tanulságok:

• A merev kódolású árazás miatt minden szint- vagy kreditmódosítás mérnöki jegyet eredményez.
• Osszuk meg a felelősséget a döntés típusa szerint: a műszaki részleg felel a felhasználási adatok rögzítéséért és pontosságáért, míg a pénzügyi és a termékfejlesztési részleg a mutatók definícióiért, az árszintekért, a csomagokért és a kreditekért.
• Először hozzunk létre biztonsági intézkedéseket: jóváhagyások, tesztelés, verziókezelés, hatálybalépési dátumok és ellenőrzési nyomvonal.
• A pénzügyi részleg által irányított árazáshoz tiszta használati adatokra, egyeztetett mutatódefiníciókra és mutatóként egy-egy nyilvántartási rendszerre van szükség.
• Használja az átadás előtti öt kérdést a kiindulási pont megtalálásához.
• Válasszon olyan eszközöket, amelyek lehetővé teszik az árak módosítását a mérési rendszer újbóli felépítése nélkül.