Chris Bishop, BillingPlatformin toimitusjohtaja – Haastattelusarja

Chris Bishop, BillingPlatformin toimitusjohtaja, on yritysohjelmistojen johtaja, jolla on yli kahden vuosikymmenen kokemus SaaSista, tulonhallinnasta, asiakassuksesta, ammatillisista palveluista ja markkinoillemenon johtamisesta. Ennen kuin hän liittyi BillingPlatformiin toimitusjohtajana vuonna 2026, Bishop vietti lähes seitsemän vuotta Congassa, jossa hän toimi senioritehtävissä, kuten Chief Customer Officer, Chief Revenue Officer ja Chief Marketing Officer, auttaen johtamaan yritystä läpi muutos- ja integraatiojakson. Aikaisemmin hän toimi Group Vice President of Global Services -roolissa Plex Systemsissä ja perusti MIPRO Consultingin, yrityssovellusten neuvontayrityksen, joka erikoistui PeopleSoft- ja Oracle-teknologioihin. Hänen uransa sisältää myös seniorijohdon tehtäviä PeopleSoftissa ja Oraclessa, joissa hän johti Pohjois-Amerikan toimitusketjun hallinnan käytäntöä, johon kuului yli 230 konsulttia, sekä aiempaa prosessien uudelleenrakentamista Ford Motor Companyssa.

BillingPlatform on yritysrevenuuliikekierroksen hallinta- ja monetisointiohjelmistoyritys, jonka tarkoituksena on auttaa yrityksiä hallitsemaan yhä monimutkaisempia hinnoittelu- ja laskutusmalleja. Vuonna 2012 perustettu yritys tarjoaa pilvipohjaisen alustan, joka kattaa tilauskeruun, tilaus- ja käyttöperusteisen laskutuksen, laskutuksen, maksut, saatavien automaation, tulon tunnistamisen ja taloushallinnon. Sen teknologia tukee toistuvaa, kulutukseen perustuvaa, hybridia ja muita konfiguroitavia hinnoittelumalleja, kun taas sen käyttömäärän välitysominaisuudet voivat kerätä ja muuntaa dataa, kuten API‑kutsuja, tapahtumia, istuntoja, kaistanleveyttä tai muita kulutustapahtumia, laskutettaviksi tiedoiksi. BillingPlatformin mukaan sen järjestelmät käsittelevät yli 50 000 laskua päivässä ja yli 4 miljardia dollaria kuukausittaisia laskutuksia, mikä asettaa alustan taloudelliseksi infrastruktuuriksi yrityksille, jotka siirtyvät perinteisten kiinteähintaisen ja tilauspohjaisen mallien ulkopuolelle.

Ura on vienyt sinut prosessien uudelleenrakentamisesta Fordilla ja yrityssovelluksista PeopleSoftissa ja Oraclessa MIPRO Consultingin perustamiseen sekä asiakas-, tulon- ja markkinointitoimintojen johtamiseen Plex Systemsissä ja Congassa. Miten nämä kokemukset ovat muokanneet prioriteettejasi BillingPlatformin toimitusjohtajana, erityisesti kun otetaan käyttöön AI kriittisiin talousoperaatioihin?

Pidän jokaisen urani pysähdyksenä kriittisenä kokemuksena. Valmistusprosessi Fordilla, talous- ja toimitusketjun hallinta PeopleSoftissa ja Oraclessa, näiden välisten konsultointivuosien aikana, ERP Plexissä ja tulonkiertohallinta Congassa. Kun tällaiset järjestelmät kohtaavat virheitä tai jokin rivi pysähtyy, joku ei saa maksua, tai kauppa ei sulkeudu. Tämä on paljon alhaisempi virhetoleranssi kuin suurin osa ohjelmistoista toimii.

Toinen ajatus on, että arvo määräytyy saavutettujen tulosten perusteella, ei sen mukaan, mitä markkinoidaan. Asiakas- ja tulotoimintojen omistaminen Plexissä ja Congassa avasi tämän minulle selvästi, kun istuin kuilussa sen välillä, mitä myytiin ja mitä asiakas sai.

Molemmat langat johtavat samaan paikkaan AI:n roolissa talousoperaatioissa. Olla oikeassa 99,5 % ajasta kuulostaa hienolta demossa, mutta se on silti epäonnistuminen. Laskutamme yrityksiä, joilla on miljoonia tilaajia. Tuolla mittakaavalla puolen prosentin virherata tarkoittaa kymmeniä tuhansia vääriä laskuja yhdessä kuussa, kymmeniä tuhansia asiakaskeskusteluja, joita kukaan ei suunnitellut, ja kreditointiprosessia, joka haudaa tiimin. Asiakas odotti kaikkien olevan oikein, joten 99,5 % ei toimittanut ostamaansa tulosta.

Siksi olemme varovaisia sen suhteen, missä AI koskettaa rahaa, ja aggressiivisia sen suhteen, missä se koskettaa työtä. AI tekee konfiguraatiota, analyysiä ja tutkimusta. Laskenta pysyy deterministisenä. Testi, jonka sovellan jokaiselle AI-ominaisuudelle, on voiko kontrolleri selittää tuloksen tarkastajalle ilman, että hän sanoo mallin päättäneen sen puolestaan.

Monet yritysohjelmistotoimittajat lisäävät AI‑avustajia olemassa oleviin tuotteisiin. BillingPlatform kuvaa AI:nsä natiiviksi tulonkiertoon ja rakennetuksi yhtenäiseen, itsekuvaavaan metatietomalliin. Mitä tämä arkkitehtuuri voi saavuttaa, mitä perinteinen AI‑kerros, joka lisätään perintö‑laskutusohjelmistoon, ei pysty?

Alustamme kuvaa itseään. Entiteetit, kentät, hinnoittelusäännöt, työnkulut ja hyväksynnät ovat kaikki metatietoa, jonka järjestelmä voi lukea suoritusaikana. Tämä tarkoittaa, että AI lukee todellista konfiguraatiotasi, ei geneeristä tuoteskeemaa, ja se voi ehdottaa muutoksia siihen konfiguraatioon, koska konfiguraatio on dataa eikä koodia.

Avustaja, joka on kiinnitetty perintö‑laskutusohjelmistoon, kohtaa erilaisen ongelman. Asiakaskohtainen logiikka näissä järjestelmissä elää räätälöidyssä koodissa, tallennetuissa proseduurissa ja integraatiovälikerroksessa. Avustaja voi vastata kysymyksiin dokumentaatiosta. Mikä tahansa, mikä liittyy siihen, miten oma instanssisi todella käyttäytyy, täytyy lukea siitä koodista, ja sen muuttaminen vaatii kehityssyklin eikä keskustelun.

Toinen ongelma on, että mittaus, laskutus ja tulon tunnistaminen sijaitsevat yleensä erillisissä järjestelmissä eri tietokannoilla. Mikä tahansa AI näiden toimintojen päällä tekee päätelmiä sovituksen yli, joten sen vastaus on vain niin hyvä kuin eilisen yön eräajon tulos. Me ajamme kaikki kolme aluetta yhdellä mallilla, joten on yksi ketju käyttötilanteesta kirjanpitotapahtumaan. AI vastaa samasta tietueesta, josta lasku on rakennettu, mikä on valtavan tärkeää.

Kun yritykset omaksuvat käyttöperusteisia, tulosperusteisia ja hybridimallisia liiketoimintamalleja, miten tekoäly muuttaa tuotteiden ja palveluiden pakkaamista, hinnoittelua ja ansaintaa?

Kaksi asiaa on muuttumassa. Ensimmäinen on, että arvoyksikkö siirtyy istumapaikoista kohti tehtyä työtä, joten yritykset hinnoittelevat ratkaisuja, käsiteltyjä asiakirjoja, suoritettuja tehtäviä tai toimitettuja tuloksia. Toinen on, että hinnoittelua tarkastellaan nyt neljännesvuosittain eikä vuosittain, koska tekoälytuotteen alla oleva kustannuskäyrä muuttuu niin nopeasti.

Kokemuksemme mukaan tekoäly auttaa enemmän analyysipuolella kuin luovassa puolella. Jos tapahtumahistoriasi on yhdessä paikassa, voit mallintaa ehdotetun hintamuutoksen todellista asiakaskäyttäytymistä vastaan ennen kuin otat sen käyttöön minuuteissa, ja esimerkiksi ennustaa, miten se vaikuttaa katteeseen tai asiakasvaihtoon. Tämä oli aiemmin usean viikon talousharjoitus.

Lisäisin myös varoituksen. Useimmat kulutukseen tai tulokseen perustuvaan hinnoitteluun siirtyvät yritykset eivät vielä osaa sanoa, mitä yksi yksikkö maksaa niille palvelun tarjoamisesta. Ilman tätä lukua yritys arvelee alarajoja ja alennusvaltuuksia. Tästä syystä useimmat organisaatiot valitsevat hybridilähestymistavan: sitoutunut alustan kiinteä maksu ennustettavuuden vuoksi, kulutussopeutuminen sekä tuloskomponentti, jossa arvo on aidosti mitattavissa.

Tekoälytuotteet voivat aiheuttaa erittäin vaihtelevia kustannuksia tokenien, mallien, infrastruktuurin ja kunkin pyynnön monimutkaisuuden perusteella. Mitä uusia mittaus- ja laskutustyökaluja yritykset tarvitsevat ansaitakseen tekoälypalveluista tarkasti ilman, että ne altistuvat ennakoimattomille marginaaleille?

Ehdottaisin aloittamista mittaamisesta kustannusajurin tarkkuudella ja tapahtumien säilyttämistä. Jos aggregoit etukäteen päivittäiseksi summaksi asiakaskohtaisesti, menetät mahdollisuuden nähdä, että yksi työnkulku käyttää kallista mallia.

Sen jälkeen neljä ominaisuutta tekevät varsinaisen työn:

1. Liitä tavaroiden kustannus samaan tapahtumaan, joka sisältää tulot, jotta asiakas-, ominaisuus- ja mallikohtainen kate on näkyvissä jakson aikana eikä vasta sulkemisen yhteydessä.
2. Tue hintarakenteita, jotka muuttuvat jakson keskellä, sillä mallin korvaaminen ja toimittajan hintaleikkaukset eivät odota yrityksen uusimisajankohtaa.
3. Tarjoa asiakkaille sitoumuksia, ennakkomaksuja, rajoja ja nostoja, koska ennakoitavuus on tuotteen ominaisuus ja se suojaa yritystä yllättävältä laskulta.
4. Ja lopuksi, kyky uudelleenarvioida historia, kun hinta muuttuu tai sovittelu on ollut virheellinen, ilman manuaalista hyvitysprosessia.

Katteiden suojaaminen tekoälytuotteissa on mittaus- ja hinnoittelusuunnitteluongelma. Jos käsittelet sen talousraportointiongelmana, saat siitä tiedon 40 päivää myöhässä.

BillingPlatform mahdollistaa tiimien konfiguroida tuotteita, hinnoittelusääntöjä ja laskutustyönkulkuja keskustelunomaisesti. Mitkä päätökset voidaan turvallisesti delegoida tekoälylle, ja missä ihmisen tarkastus ja hyväksyntä on edelleen pakollista?

Sanon, että työn voi delegoida, mutta päätökset tulisi jättää ihmisille.

Tekoäly voi turvallisesti lukea ja selittää olemassa olevan konfiguraation, laatia uuden konfiguraation hiekkalaatikossa, luoda testidataa ja testitapauksia, havaita poikkeavuuksia käyttö- tai laskutuskierroksissa, tutkia hinnoittelukohdistuksen erimielisyyden takaisin lähdetapahtumaan ja rakentaa ensiaskeleen kartoituksen migraatiota varten. Tämä kattaa suuren osan laskutustiimin viikoittaisista työtunneista eikä sisällä juuri lainkaan riskiä.

Ihmisen hyväksyntä on pakollista kaikessa, mikä muuttaa asiakkaan laskutusta tai tuotannon tuloutusta. Näihin kuuluvat hintojen ja taksamääräysten muutokset, sopimusehdot, hyvitykset ja korjaukset, tuloutuspolitiikka ja itsenäiset myyntihintojen arvostelut, kirjanpidon (GL) kartoitus, veropositioinnit sekä jakson sulkeminen. Lisäksi ihmiset on otettava mukaan kaikkiin ensimmäistä kertaa asiakkaille näkyviin toimenpiteisiin.

Toimintasääntö on, että tekoäly ehdottaa, valtuutettu henkilö hyväksyy, ja hyväksyntä kirjataan muutokseen. Hyväksynnät ja roolipohjaiset oikeudet olivat jo alustassa, joten agentit perivät ne sen sijaan, että kiertäisivät ne.

Taloudelliset järjestelmät jättävät vähän tilaa harhauksille tai selittämättömille päätöksille. Kuinka BillingPlatform yhdistää tekoälyn päättelyn deterministiseen suoritukseen varmistaakseen, että laskut, tulolaskelmat ja kirjanpitotoimet pysyvät tarkkoina ja toistettavina?

Erotamme tulkinnan suorituksesta. Malli tulkitsee tarkoituksen ja tuottaa konfiguraation, kyselyn tai ehdotetun muutoksen. Hinnoittelu- ja kirjanpito­moottori sitten suorittaa sen. Tämä moottori käyttää samaa koodipolkua riippumatta siitä, onko henkilö konfiguroinut sen käyttöliittymässä vai onko agentti konfiguroinut sen tekoälymme kautta, joten samat syötteet tuottavat aina saman laskun, ja voit suorittaa suljetun jakson uudelleen ja saada identtisen vastauksen.

Mikään laskun numero ei synny kielimallin toimesta laskun luontihetkellä. Tekoäly tuottaa konfiguraatiomuutoksen, ja tämä muutos sisältää version, tekijän ja aikaleiman kuten kaikki muutkin järjestelmän muutokset. Jos tarkastaja kysyy, miksi veloitus on sellainen kuin se on, vastaus jäljittää takaisin hinnoittelutietueesta käyttöön tapahtuneeseen, ei johonkin kehotteeseen.

Viimeinen osa on, että ehdotuksia voidaan tarkastella ennen niiden toteuttamista. Näet tekoälyn haluaman tarkat konfiguraatiot selkeässä muodossa, ja voit hyväksyä tai hylätä ne.

BillingPlatform tukee Model Context -protokollaa, Agent-to-Agent -protokollaa ja yhteyksiä ulkoisiin yritys‑AI‑työkaluihin. Kuinka yritykset voivat antaa itsenäisille agenteille pääsyn laskutustoimintoihin estäen samalla luvattomat toimet, tietojen paljastumisen tai jäljittämättömät muutokset?

MCP ja A2A ovat kuljetuskerroksia, ja ne saavat agentin ovelle. Ohjaustaso on käyttöoikeusmallisi, ja juuri siellä varsinainen työ tapahtuu.

Meidän tapauksessamme agentti tunnistautuu käyttäjänä ja perii saman roolin sekä kenttä‑ ja tietue‑tason käyttöoikeudet, jotka jokainen työntekijä saisi. Agenttien ohitusta ei ole. Sen lisäksi muutama käytäntö pitää paikkansa. Anna jokaiselle agentille oma rajoitettu palvelutili vähimmillä oikeuksilla, aluksi vain luku‑oikeus, kunnes toisin todistetaan, jotta auditointiloki kertoo, mikä agentti teki mitä. Ohjaa kirjoitusoperaatiot hyväksyntätyönkulun läpi dollarin‑ ja volyymirajojen kanssa. Sinun tulisi myös rajoittaa niiden nopeutta, koska silmukassa oleva agentti aiheuttaa erilaisen vian kuin henkilö tekee virheen. On myös kriittistä kirjata jokainen kutsu, ei vain niitä, jotka muuttivat jotain. Palauta vain ne kentät, joita tehtävä tarvitsee, koska nopein tapa vuotaa asiakastietoja on liian laaja luku.

Virhe, jonka odotan näkeväni markkinoilla tänä vuonna, on yritysten antavan agentille ihmisen ylläpitäjän tunnistetiedot, koska se oli helpompaa kuin määrittää oikea käyttöoikeusalue.

BillingPlatform sanoo, että tekoäly voi lyhentää käyttöönottoja neljänneksistä viikkoihin. Mitkä vaatimusten keruun, konfiguroinnin, testauksen ja migraation osat tekoäly voi automatisoida tänään, ja mitkä osat edelleen vaativat kokeneita laskutus‑ ja talousalan ammattilaisia?

Tekoäly on todellakin hyvä muuntamaan dokumentoidut hinnoittelut konfiguraatioiksi, suorittamaan aukkoanalyysin tunnettuja malleja sisältävää kirjastoa vastaan, luomaan testitapauksia ja toteuttamaan regressiotestausta, kartoittamaan ja puhdistamaan perintötietoja migraatiota varten sekä tuottamaan dokumentaatiota. Nämä ovat ne alueet, joilla työmäärä lyhenee neljänneksistä viikkoihin.

Kuitenkin päätöksenteko vaatii edelleen kokeneita laskutus‑ ja talousalan ammattilaisia. Esimerkkejä, jotka edelleen vaativat kokeneita ihmisiä, ovat esimerkiksi asiakkaan saaminen suostumaan omiin hinnoittelusääntöihinsä ja tuloutuskäytäntöihinsä, ehtojen rekonstruointi sopimuksista, integraatio järjestelmään, jossa on dokumentoimatonta käyttäytymistä, sekä tuloutuksen käsittelyn arviointi moniosaisessa järjestelyssä. Lyhyesti sanottuna muutosjohtaminen ei reagoi ohjelmistoon.

Kuinka yhtenäinen malli, joka kattaa mittauksen, laskutuksen ja tuloutuksen, voi parantaa noudattamista, auditointikykyä ja talousraportointia, erityisesti organisaatioille toimivillemonimutkaisten tuloutusvaatimusten alaisina?

Auditointihenkilöt kysyvät aina kahta asiaa: Näytä minulle, miten päädyit tähän lukuun, ja näytä, että sovelsit samaa käsittelyä johdonmukaisesti. Jos mittaus-, laskutus- ja tuloutusjärjestelmäsi toimivat erillään, vastaaminen tarkoittaa kaivamista kolmen tietokannan ja ihmisen luoman taulukkolaskentataulukon läpi niiden kaikkien sovittamiseksi.

Kun kaikki on yksi malli, koko tämä harjoitus katoaa. Käyttötapahtuma, veloitus, laskurivi ja kirjanpitotapahtuma ovat kaikki sama tietue, joka vain etenee seuraavaan vaiheeseen. Voit seurata sitä eteenpäin tai taaksepäin ilman välikäyttä sovittamisvaihetta, koska mitään sovitettavaa ei ole. Kun sopimus muuttuu, arvioit samaa tapahtumatietoa, joka alun perin loi laskun. Erillinen myyntihintasi ja allokaatiosi perustuvat tapahtuneeseen.

Tämä on erityisen tärkeää yrityksille, jotka käsittelevät muuttuvaa korvausta ASC 606:n tai IFRS 15:n mukaisesti, joissa sinun on näytettävä työsi ja pystyttävä esittämään se uudelleen vuoden kuluttua.

BillingPlatform on äskettäin ilmoittanut lisäävänsä uuden talousjohtajan, tuotejohtajan ja asiakasjohtajan, kun se laajentaa AI‑natiivia strategiaansa. Kuinka nämä johtajat tekevät yhteistyötä muuttaakseen teknisen innovaation taloudellisesti kestävään kasvuun ja mitattaviin tuloksiin yritysasiakkaille?

Tuotejohtajana Rob Zwiebach varmistaa, että tuotteemme on erottuva ja toimitettu. Hän johti Workdayn talousohjelmistojen tuote‑tiekarttaa ja vietti 17 vuotta Oraclella, joten hän tuntee järjestelmät, joita ostajamme jo käyttävät, ja tietää, mitä vaaditaan kilpailemiseksi niiden kanssa. Asiakasjohtajana Chris King vastaa siitä, että asiakkaat kokevat arvon, eli aika arvoon, toimituksen johdonmukaisuuden, säilyttämisen ja laajentumisen. Hän johti palveluita ja menestystä Medidatassa ja Salesforce‑yrityksessä ja aloitti alalla Zuorassa, joten hän on nähnyt sekä hyvät että huonot yritystoimitukset mittakaavassa. Steven Springsteel, talousjohtajamme, vastaa taloudesta, ja hän tulee meille Recurlyn CFO‑tehtävästä, joten hänellä on ensikäden kokemus laskutusyrityksen talousfunktion johtamisesta.

Missä heidän on todella tehtävä yhteistyötä yhtenä ryhmänä, on numero, jonka välittömästi minua eniten kiinnostaa. Eli mitä se maksaa ja kuinka kauan kestää saada yritysasiakas käyttöön ja tuottavaksi, sekä kyseisen työn katteessa. Tämä on tuote‑päätös, toimituspäätös ja mittauspäätös, ja se on perinteisesti ollut se kohta, jossa yrityslaskutusprojektit menevät pieleen. Väite, että olet AI‑natiivi, on väite arkkitehtuuristasi. Se muuttuu liiketoiminnaksi vain, kun se näkyy toteutuskustannuksissa, laajenemisnopeudessa ja bruttokatteessa. Nämä ovat ne kolme lukua, joista Rob, Chris ja Steven kukin omistavat osan.

Kiitos erinomaisesta haastattelusta, lukijat, jotka haluavat oppia lisää, tulisi käydä BillingPlatform.