Käytön mittaus ja hinnoittelu: tekniikka vs. talous

Johdanto

Käyttöön perustuva ja hybridi hinnoittelu on harvoin staattista. Kun hinnoittelulogiikka on koodattu kiinteästi, jokainen tasoon tai luottorajaan tehty muutos muuttuu tekniseksi tukipyynnöksi. Se hidastaa taloushallintoa ja on turhauttavaa kehittäjille. Kenen siis tulisi vastata käytön mittaamisesta ja sen pohjalta rakennetusta hinnoittelusta? Selvitetään asia.

Miksi hinnoittelumuutokset ovat nykyään yleisiä

Hinnoittelu ei ole enää päätös, jonka voi tehdä kerran ja unohtaa. Konsulttiyrityksen hy:n ja OMR Reviewsin SaaS & AI Pricing Report -raportti, joka viittaa Growth Unhinged -tietoihin, kertoo, että kolme neljästä yhdysvaltalaisesta ohjelmistoyrityksestä muutti hinnoitteluaan viime vuoden aikana. Se on paljon muutosta.

Myös mallit ovat muuttumassa. Hy:n 180 ohjelmistoyritykselle tekemässä kyselyssä 37 % käyttää jo käyttöpohjaisia malleja, ja 59 % yhdistää useampaa kuin yhtä hinnoittelumittaria, kuten käyttäjäkohtaisen laskutuksen ja API-volyymin. Kun tähän lisätään hyvityksiä, kokeiluja ja pakettien hienosäätöä, muutoksista tulee pikemminkin sääntö kuin poikkeus.

Miten hinnoittelulogiikka päätyy insinöörien vastuulle

Se tapahtuu yleensä vahingossa. Alkuvaiheessa kehittäjä koodaa mittarin kiinteästi: laske API-kutsut, sovella hintaa, lähetä summa laskulle. Se toimii, joten kukaan ei kyseenalaista sitä.

Sitten hinnoittelu kehittyy. Uusi taso, ilmainen kiintiö tai erilainen ylimääräinen hinta tarkoittaa, että joku avaa tukipyynnön, odottaa sprintin aikapaikkaa ja toivoo, ettei julkaisu häiritse laskutusta. Käsittelyaika venyy, ja jokainen julkaisu sisältää jonkinlaisen riskin. Talousosasto päätyy odottamaan jonossa, jota se ei voi hallita.

Hybridimallit pahentavat tilannetta. Mitä enemmän hintaan sisältyy komponentteja, sitä useammassa paikassa muutos voi piiloutua koodiin.

Tekniikan omistaman hinnoittelun kustannukset

Kustannukset ovat todellisia, vaikka niitä ei voitaisi todistaa taulukkolaskennalla.

• Hidas käyttöönotto: Hinnoitteluidea voi jäädä viikoiksi tuotekehitystyön jalkoihin.
• Virheet: Koodiin kätketty logiikka on talousosaston vaikea tulkita, joten virheet nousevat helposti esiin laskuissa.
• Talousosaston sokeat pisteet: Jos talousosasto ei näe, miten luku on laskettu, riitojen ratkaiseminen kestää kauemmin.
• Vaihtoehtokustannukset: Kehittäjät ylläpitävät laskutuslogiikkaa sen sijaan, että kehittäisivät tuotetta.

Tässä on näkemykseni: jos hinnanmuutos vaatii koodin käyttöönottoa, hinnoittelusi etenee julkaisukalenterisi vauhdilla, ei markkinoiden vauhdilla

Mistä talousosaston ja mistä kehitysosaston tulisi vastata

Vastuu ei ole joko-tai-asia. Jaa se päätösten tyypin mukaan.

Tekniikka vastaa tapahtumien seurannasta, dataputkistoista ja käyttötietojen tarkkuudesta lähteellä.

Talous- ja tuotekehitysosastot vastaavat mittareiden määritelmistä, hintatasoista, paketoinnista ja hyvityksistä.

Tässä on yksinkertainen testi. Jos muutos koskee sitä, mitä kerätään, se kuuluu kehitysosastolle. Jos se koskee sitä, miten kerätty käyttö muuttuu rahaksi, se kuuluu talous- ja tuoteosastolle. Esimerkiksi päätös siitä, että paketti sisältää 1 500 API-kutsua 1 000:n sijaan, on hinnoittelupäätös. Sen varmistaminen, että jokainen kutsu kirjataan täsmälleen kerran, on kehitysosaston tehtävä.

Hintamuutosten hallinta

Hallinnan luovuttaminen ilman suojakaiteita johtaa kaaokseen. Nämä ovat yleisiä parhaita käytäntöjä, jotka eivät ole sidoksissa mihinkään tiettyyn työkaluun:

• Hyväksynnät: Vaadi nimetty hyväksyntä talousosastolta ja tuotekehitykseltä ennen kuin muutos otetaan käyttöön.
• Testaus: Tarkista muutoksen vaikutus todellisiin käyttötietoihin ennen käyttöönottoa.
• Versiointi: Pidä jokaisesta hinnoittelukonfiguraatiosta versio, jotta voit verrata versioita tai palata aiempaan versioon.
• Voimaantulopäivät: Määritä, milloin muutos astuu voimaan ja miten jo jakson puolivälissä kirjattua käyttöä käsitellään.
• Tarkastusjälki: Kirjaa ylös, kuka muutti mitä ja milloin.

Ajattele sitä hinnoittelun kooditarkastuksena. Kukaan ei julkaise koodia ilman toisen silmäparin tarkastusta, ja hinnoittelu ansaitsee saman huolellisuuden.

Rahoitusjohtoisen hinnoittelun edellytykset

Talousosasto ei voi omistaa sitä, mihin se ei voi luottaa. Kolme perusta on ensisijaisia.

Puhtaat käyttötiedot. Päällekkäiset tai puuttuvat tapahtumat heikentävät kaikkia niiden pohjalta asetettuja hintoja.

Sovitut mittarimääritelmät. Jos tuotekehitys määrittelee ”aktiivisen käyttäjän” yhdellä tavalla ja talousosasto toisella, laskut ratkaisevat kiistan puolestasi – eikä suinkaan ystävällisesti.

Luotettavat lähteet. Käyttötiedot sijaitsevat tyypillisesti tietovarastossa, API:n takana tai tiedostoissa. Valitse jokaiselle mittarille yksi rekisterijärjestelmä ja pidä siitä kiinni.

Kysymyksiä, jotka on syytä esittää ennen hinnoitteluvastuun siirtämistä

Kutsu talousjohtaja, tuotejohtaja ja tekninen johtaja yhteen huoneeseen ja käykää läpi seuraavat kysymykset:

1. Mitä hinnoittelumuutoksia teimme viime vuonna, ja kuinka kauan kunkin muutoksen käyttöönotto kesti?
2. Onko jokaisella laskutettavalla mittarilla yksi sovittu määritelmä?
3. Voiko talousosasto jäljittää, miten käyttöluvusta tuli laskurivi?
4. Kuka hyväksyy muutoksen, ja miten testaamme sen ennen käyttöönottoa?
5. Missä käyttötiedot sijaitsevat, ja kuka vastaa niiden paikkansapitävyydestä?

Jos et osaa vastata kahteen tai kolmeen näistä kysymyksistä, se on lähtökohtasi.

Hinnoittelun muuttaminen ilman mittauksen uudelleenrakentamista

Tässä vaiheessa työkalut voivat auttaa. Zenskarin käyttömittaussivun mukaan tiimit voivat määritellä laskutettavat mittarit selkokielellä ja antaa tekoälyn kirjoittaa aggregointilogiikan tai kirjoittaa mukautettua SQL-koodia monimutkaista logiikkaa varten. Käyttötiedot voidaan hakea lähteistä, kuten Postgresista, Athenasta ja MySQL:stä, välittää API:n kautta tai ladata CSV-tiedostona. Samaa mittaria voidaan käyttää uudelleen eri tuotteissa, sopimuksissa ja rivikohteissa.

Omistajuuden kannalta tärkeää on, että käyttöpohjaisen laskutuksen ohjelmiston tulisi sallia porrastusten, ylitysten ja laskutusvälin muuttaminen käytöstä riippumatta. Laskutuslogiikkaa voidaan myös muokata kesken laskutusjakson häiritsemättä dataputkea. Yksi ainoa mittari voi toimia pohjana erilaisille hinnoittelumalleille eri sopimuksissa, jolloin mittaus pysyy vakaana hinnoittelun kehittyessä.

Johtopäätös

Tervein malli on jaettu malli. Kehitysosasto pitää käyttötiedot tarkkoina ja varmistaa niiden virtauksen. Talous- ja tuoteosastot vastaavat tietojen arvosta selkeän hallintamallin puitteissa. Mikä hinnoittelumuutos odottaa parhaillaan kehitysosastosi jonossa?

Tärkeimmät opit:

• Koodiin kiinteästi kirjattu hinnoittelu muuttaa jokaisen taso- tai hyvitysmuutoksen tekniseksi tukipyynnöksi.
• Jaa vastuu päätöstyypeittäin: tekninen osasto vastaa käyttötietojen keräämisestä ja tarkkuudesta, kun taas talousosasto ja tuotekehitys vastaavat mittareiden määritelmistä, hintatasoista, paketoinnista ja hyvityksistä.
• Aseta ensin suojatoimenpiteet: hyväksynnät, testaus, versiointi, voimaantulopäivät ja kirjausketju.
• Talousosaston johtama hinnoittelu vaatii puhtaita käyttötietoja, sovittuja mittareiden määritelmiä ja yhtä kirjanpitojärjestelmää kutakin mittaria kohti.
• Käytä viittä luovutusta edeltävää kysymystä lähtökohdan löytämiseen.
• Valitse työkalut, joiden avulla hinnoittelua voidaan muuttaa ilman, että mittausta joudutaan rakentamaan uudelleen.