Griffin Parry, m3terin toimitusjohtaja – Haastattelusarja

Griffin Parry on m3terin toimitusjohtaja ja perustaja. Tämä on hänen toinen startup-yrityksensä, sillä hän on aiemmin perustanut ja johtanut GameSparksia, pilvipalveluyritystä, jonka Amazon (AMZN ) hankki vuonna 2017. Sen jälkeen hän työskenteli kolme vuotta johtavissa tuote- ja kenttärooleissa AWS:ssä. Hän aloitti uransa medialla (Sky, News International) keskittyen digitaaliseen strategiaan ja digitaalisten tuotteiden kehittämiseen, mukaan lukien Sky:n online-televisiopalvelun lanseeraus ja johtaminen.

m3ter on SaaS-alusta, joka on suunniteltu auttamaan yrityksiä ottamaan käyttöön ja hallitsemaan monimutkaisia käyttöperusteisia hinnoittelumalleja toimimalla mittaus- ja laskutusinfrastruktuurikerroksena, joka sijaitsee olemassa olevien järjestelmien, kuten CRM- ja ERP-järjestelmien, rinnalla. Se kerää raakatuotteiden käyttödataa, soveltaa joustavaa hinnoittelulogiiikkaa ja automatisoi koko tarjous-tai-maksuprosessin, mahdollistaen yritysten luominen tarkkoja, reaaliaikaisia laskuja ja vähentäen tulonvuotoa ja operatiivisia kustannuksia. Erottamalla laskutuksen ydinjärjestelmistä m3ter mahdollistaa yritysten kokeilemisen hinnoittelumalleja, lanseeraa uusia tuotteita nopeammin ja saavuttaa syvemmän ymmärryksen asiakkaiden käytöstä ja tulonvirroista, mikä tekee siitä erityisen arvokkaan modernille ohjelmistoyrityksille, jotka siirtyvät kulutusperusteisiin liiketoimintamalleihin.

Perustit ja kasvattajat GameSparksin hankinnan kautta, ja valitsit aloittaa m3terin keskittyen erityisesti laskutusinfrastruktuuriin ja moderniin rahoitukseen. Mitä sinut veti tähän ongelma-alueeseen toisessa yrityksessäsi, ja miten aikaisempi perustajakokemus vaikutti tähän päätökseen?

Olemme klassinen tapaus perustajista, jotka ratkaisevat ongelman, jonka he ovat kokeneet itse. GameSparksissa meillä oli moderni rahoitusstrategia – käyttöperusteinen hinnoittelu – koska se toimi liiketoimintamallissamme (pilvi-infrastruktuuri). Se oli avain menestykseemme, mutta se aiheutti myös paljon operatiivista ja myyntipainetta. Sitten AWS:ssä, myös pilvi-infrastruktuuriliiketoimintaa, vaikka se oli paljon suurempi, näimme, että heillä oli samat ongelmat. Näimme myös, kuinka paljon vaivaa he panivat niiden ratkaisemiseen, koska se oli kriittistä heidän liiketoiminnalleen. Totesimme, että käyttöperusteisessa maailmassa laskutusinfrastruktuuri on strateginen kyky, jota useimmat yritykset eivät voineet kehittää, joten perustimme m3terin muuttaaksemme tämän.

AI-natiiviset tuotteet voivat olla epävakaiden infrastruktuurikustannusten vuoksi, jotka liittyvät esimerkiksi johtopäätöksiin, tokenien käyttöön tai mallin uudelleenkoulutukseen. Miten perustajien tulisi ajatella hinnoittelun ja arvon yhdistämistä suojelemalla samalla bruttokatetta?

Perinteiset SaaS-tuotteet olivat yleensä lähes nolla marginaalikustannuksia käytöstä. Toisin sanoen, asiakkaan käyttö ei vaikuttanut palvelun tarjoamiseen. Tämä ei pidä paikkaansa AI-tuotteille, koska niiden käyttö aiheuttaa kustannuksia, kuten tokenien kulutusta. Jos hinnoittelusi on kiinteä, se tarkoittaa, että bruttokatteesi voivat vaihdella merkittävästi asiakasta kohti riippuen heidän käytöstään. Tämä tekee käyttöperusteisen hinnoittelun lähes välttämättömäksi, koska se yhdistää tulot kustannuksiin ja vakauttaa bruttokatetta.

Kun AI upotetaan olemassa oleviin ohjelmistokategorioiden, odotatko, että useimmat yritykset lisäävät käyttökomponentteja tilauksiin, vai näetkö uusia rahoituskehyksiä syntyvän?

En odota mitään täysin uutta – vain vanhojen hinnoittelumallien uudelleenkeksimistä. Näet koko kirjon, alkaen puhtailta tilauksilta ja päättyen tuloksiperusteisiin malleihin. Mutta suurin ryhmä on hybridimalli: kiinteät toistuvat elementit ennustettavuuden vuoksi, yhdistettynä muuttuvan mittarilla, joka toimii sekä asiakkaiden (he yhdistävät sen menestykseen) että toimittajien (se on tarpeeksi kustannuksiin sopiva) kanssa.

Tuloksiperusteisen hinnoittelun ympärillä on kasvava keskustelu AI-aikakaudella. Missä näet todellisen otteen syntyvän, ja missä uskot, että malli tulee liian monimutkaiseksi toteuttaa tehokkaasti?

Tuloksiperusteisen hinnoittelun haaste on attribuutio – jotta se toimisi, mitattava tulos on oltava yksiselitteisesti toimittajan tuotteen aiheuttama. Joskus se on mahdollista – maksamisen esimerkki, jossa tarjoajat ottavat osuuden transaktiosta, ja se näyttää reilulta. Mutta kokemukseni mukaan nämä tilanteet ovat suhteellisen harvinaisia, ja yritykset usein turvautuvat hinnoittelumittareihin, jotka ovat enemmän arvon viitearvoja – esimerkiksi asiakastukea tekevälle tekoälyagentille, puhelut, jotka ratkaistaan ilman ihmisen väliintuloa. Taas, nähdään ratkaisuja, jotka ovat käyttöperusteisia, arvon viitearvoja ja tuloksiperusteisia hinnoittelumalleja – se riippuu käyttötapausta. Mitä ne kaikki ovat yhteisiä, on se, että jotain on laskettava ja hinnoiteltava, mikä on se, mihin m3ter tulee.

Kun määritetään arvoa tekoälykäyttöisissä tuotteissa, mitkä käytännön mittarit yritysten tulisi keskittyä realistisina arvoina tuloksille?

Tämä on vaikea kysymys, koska se on hyvin käyttötapausspecifinen. On joitakin “aina” -huomioita – onko mittari yksinkertainen, ennustettavissa, liitetty arvoon ja tarpeeksi kustannuksiin sopiva? Mutta itse mittari riippuu siitä, mitä tuote tekee. “Tokenit käytetty” toimii LLM-mallille. “Asiakirjat käsitelty” toimii sopimussanalyysille. “Kyselyt suoritettu” toimii yritysten hakukoneelle. “Keskustelut käsitelty (ilman ihmisen väliintuloa) toimii asiakastuella.

Mitkä ovat yleisimmät operatiiviset ja tekniset haasteet, joita yritykset kohtaavat siirtymällä tilausvain-malleista hybrid- tai käyttöperusteisiin hinnoittelumalleihin?

Avainkivulat liittyvät tulojen vuotoon, huonoihin asiakaskokemuksiin ja hinnoittelun joustavuuden puutteeseen, joka haittaa Tuotteen ja Myyntiprosessia. Syyt juontavat väärästä operatiivisesta perustasta. Uudet (tarvittavat) kyvyt, joita tarvitaan siirtymiseen tilausvain-malleista hybrid- tai käyttöperusteisiin hinnoitteluun, ovat käytön datakäsittely, edistynyt (ja jatkuva) laskennan laskenta ja automaattiset yhteydet CRM-, laskutus- ja ERP-järjestelmien välillä.

Monet suuret yritykset ovat syvästi sitoutuneita järjestelmiin, kuten Salesforceen ja NetSuiteen. Miten m3ter modernisoi rahoitusinfrastruktuuria ilman, että yritysten on pakko uusia olemassa olevaa pinottaa?

Vakiintuneet tarjous-laskutus-työkalut, kuten Salesforce (CRM ) ja NetSuite, olettaa maailman, jossa on tilauksia. Se ei tarkoita, ettei niitä voida käyttää modernissa rahoituslähestymistavoissa – sinun tarvitsee vain täyttää kriittiset aukot, mitä m3ter tekee. Keskitymme tarkalleen siihen, mitä puuttuu: käytön datakäsittely, edistynyt hinnoittelu ja automaattiset datakuljetukset tarjous-laskutusjärjestelmien välillä.

Tulojen vuoto on usein aliarvioitu. Kuinka merkittävä ongelma tämä on modernissa SaaS-liiketoimissa, ja mitkä ovat yleisimmät syyt siihen?

Tulojen vuoto on arvoa, joka on ansaittu (olet myynyt sen ja toimittanut sen), mutta jota ei ole kerätty laskutusvirheiden vuoksi – laskusi eivät kata kaikkia asiakkaan käyttöä tai eivät sovellaa oikein kaupallisia ehtoja. Se on suuri asia – PwC:n Tulon eheys -tiimi arvioi sen 4-7 prosentiksi, ja mitä monimutkaisempi hinnoittelu on, sitä todennäköisemmin se on. Juurellinen syy johtuu järjestelmistä ja ohjauksesta: ei käytön dataa kerätä tehokkaasti; ei automaattisia yhteyksiä laskutuksen lähtökohtien ja laskennan laskentamekanismin välillä; ja laskennan laskentamekanismi ei ole tarpeeksi kehittynyt käsitelläkseen monimutkaisuutta (esim. riippuen taulukoista).

Miten suurempi hinnoittelun joustavuus vaikuttaa tuoteinnovaatioon ja myyntistrategiaan ohjelmistoyrityksissä?

Yksinkertaista – mitä enemmän hinnoittelun joustavuutta sinulla on, sitä nopeammin voit toimittaa uusia tuotteita, ja sitä helpommin voit sopeuttaa hinnoittelua asiakkaiden tarpeisiin ja toiveisiin, mukaan lukien yksityiset hinnoittelukaupat, jotka auttavat Myyntiä voittamaan. Se on strateginen kyky liiketoiminnalle. Mutta et voi saada joustavuutta ilman automaatiota ja ohjausta. Muuten saat laskutusvirheitä, tulojen vuotoa ja vaatimustenmukaisuushaasteita.

Näkymässä, näetkö tekoälyllä roolin dynaamisessa hinnoittelumallien optimoinnissa reaaliajassa, ja mitä pitäisi olla paikassa, jotta se toimisi luotettavasti suuressa mittakaavassa?

Olen varmasti hyvin innoissani tekoälyn mahdollisuuksista hinnoittelun optimoinnissa. Mutta olen vähemmän vakuuttunut reaaliaikaisesta osasta, ainakin ohjelmistoa palveluna (SaaS) tai ratkaisua palveluna (Solutions-as-a-Service) -liiketoiminnassa. Jos myyt hotellihuoneita tai lentolippuja, dynaaminen hinnoittelu toimii, koska se on yksittäinen transaktio. Mutta B2B-ohjelmistotoimittajat haluavat asiakassuhteita, jotka kestävät, ja asiakkaat eivät halua, että hinnoittelu muuttuu odottamattomasti päivittäin. Joten hinnoittelun optimointi keskittyy luomiseen räätälöityjä hinnoitteluratkaisuja pitkäaikaisiin sopimuksiin – hinnoittelu, joka on suunniteltu tarjoamaan parhaat tulokset sekä toimittajalle että asiakkaalle monivuotisten suhteiden aikana.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia lisää, voivat vierailla m3ter-sivustolla.