Credits vervangen een lange lijst technische tarieven door één saldo dat bij het product past. Een creatieve tool kan 1.000 credits per maand omvatten, een AI-bewerking kan 2 tot 80 credits verbruiken en een API-klant kan een nieuw pakket kopen wanneer het saldo opraakt.
Deze abstractie kan het verpakken van meerdere dure acties vergemakkelijken. Ze kan ook de werkelijke kosten van alles verbergen. Als klanten vóór elke klik valuta moeten omrekenen, de documentatie van het model moeten doorlezen en de lengte van het resultaat moeten raden, heeft het product de complexiteit alleen verplaatst in plaats van weggehaald.
Prijzen op basis van credits werken wanneer het saldo klanten een stabiele planningseenheid geeft, de leverancier de variabele kosten laat dekken en veel acties ondersteunt zonder onleesbare prijslijst. Ze mislukken wanneer credits vooral zijn ontworpen om de prijs te versluieren, kunstmatig ongebruikt saldo te creëren of tarieven te wijzigen zonder duidelijk prijsbesluit.
Deze gids legt uit hoe je een transparante en operationeel betrouwbare economie van credits bouwt.
Wat een productcredit vertegenwoordigt
Een credit is een commercieel recht dat in een wallet of limiet is vastgelegd. Activiteit in het product verbruikt dat recht volgens een omrekenregel.
De basisberekening ziet er zo uit:
verbruikte credits = aantal acties × kosten in credits van één actie
De kosten in geld hangen af van de manier waarop de credits zijn verkregen:
effectieve prijs van de actie = verbruikte credits × gerealiseerde prijs van één credit
De gerealiseerde prijs van een credit verschilt, omdat credits via verschillende wegen binnenkomen: een terugkerende limiet in het pakket, een eenmalig pakket, een jaarverplichting, volumekortingen, een promotionele toekenning, een restitutie of compensatietegoed, een partnerprogramma, automatische opwaardering.
Daarom zegt de geadverteerde prijs van een credit weinig over de omzet. Twee accounts met identiek verbruik kunnen meerdere malen verschillen in wat ze voor die credits hebben betaald.
Een credit kan één onderliggende maatstaf abstraheren of meerdere. Bijvoorbeeld:
| Actie in het product | Kosten in credits | Onderliggende kostenfactoren |
|---|---|---|
| Achtergrond van een afbeelding verwijderen | 2 | inferentie van het model en opslag |
| Een standaardafbeelding genereren | 12 | model, resolutie en wachtrij |
| Een afbeelding met hoge resolutie genereren | 35 | groter model en verwerkingstijd |
| 30 seconden video maken | 80 | duur, model en rendering |
De tabel is alleen nuttig als klanten haar zien voordat ze een actie uitvoeren en de acties consistent zijn gedefinieerd.
Waarom producten credits gebruiken
Eén saldo kan uiteenlopende acties omvatten
AI-producten en creatieve tools kunnen tekst, beeld, geluid, video en analyse bieden. Tokens, seconden, pixels, GPU-tijd en verzoeken aan de leverancier rechtstreeks in rekening brengen zou nauwkeurig zijn, maar lastig te kopen. Credits vormen één commerciële laag boven die middelen.
Pakketten worden makkelijker te construeren
Een abonnement kan een pool bevatten die voor meerdere processen is te gebruiken. De klant krijgt flexibiliteit en de leverancier hoeft niet precies te voorspellen welke functie zal worden gebruikt.
Vooruitbetaling beperkt de financiële blootstelling
Gekochte credits laten je geld innen voordat de variabele kosten worden gemaakt en beperken het gebruik tot het beschikbare saldo. Dat is waardevol bij dure bewerkingen die direct beschikbaar worden gesteld.
Promoties zijn los te koppelen van de catalogusprijs
Een product kan proef- of compensatiecredits toekennen zonder het vaste tarief per actie te wijzigen. Aparte saldi voor toekenningen maken het bovendien mogelijk de kosten van een promotie te meten.
Kostenverschillen blijven uitdrukbaar
Een duur model kan meer credits verbruiken dan een efficiënt model, terwijl de gebruiker nog steeds met één wallet werkt.
Deze voordelen vragen om een begrijpelijk systeem van omrekening. Een saldo waarvan de betekenis onvoorspelbaar verandert, is geen stabiele maatstaf voor waarde.
Wanneer credits een goede oplossing zijn
Prijzen op basis van credits zijn het nuttigst wanneer:
- het product meerdere factureerbare acties omvat;
- de acties duidelijk verschillende variabele kosten hebben;
- klanten die acties flexibel willen gebruiken;
- directe technische maatstaven moeilijk te voorspellen zouden zijn;
- vooruitbetaling of een ingesloten limiet het risicobeheer verbetert;
- de kosten van een bewerking vóór uitvoering zijn in te schatten of te begrenzen.
Ze zijn minder nuttig wanneer het product al met één natuurlijke eenheid te beschrijven is. Een API voor het valideren van e-mailadressen met één stabiel type verzoek kan duidelijker zijn met een prijs van 0,004 € per validatie dan met 0,4 credit waarvan je de geldwaarde moet uitrekenen.
Het model is ook zwak wanneer credits niet aan een betekenisvol resultaat zijn te koppelen. "AI-energiepunten" verbeteren het begrip niet als dezelfde prompt een onvoorspelbare hoeveelheid verbruikt.
Gebruik een diagnose van de match:
| Dimensie | Credits passen goed | Waarschuwingssignaal |
|---|---|---|
| Breedte van het product | Meerdere acties delen een gemeenschappelijke wallet | Eén duidelijke actie om te factureren |
| Variabiliteit van kosten | Klassen van acties hebben bekende relatieve kosten | Elke uitvoering heeft onbeperkte, onbekende kosten |
| Planning door de klant | Processen zijn in credits in te schatten | Het opraken van het saldo voelt willekeurig |
| Risico | Vooruitbetaling beveiligt dure uitvoering | De kosten zijn verwaarloosbaar en het opwaarderen van het saldo voegt wrijving toe |
| Pakketten | Een flexibele limiet vergroot de keuze | Credits dienen alleen om een prijsverhoging te verbergen |
| Operatie | Wallet en register kunnen de bron van waarheid zijn | Het saldo wordt in verschillende systemen inconsistent berekend |
Wat één credit betekent
Een credit hoeft niet één op één met een valuta overeen te komen. Hij moet wel een stabiel commercieel doel hebben.
Er zijn drie gangbare benaderingen.
Monetaire abstractie
Eén credit komt overeen met een vaste geldwaarde, bijvoorbeeld 0,01 €. Acties verbruiken credits volgens hun prijs.
Voordelen: interne tarieven zijn makkelijk te berekenen, restituties en boekhouding zijn eenvoudig en klanten kunnen de waarde naar valuta omrekenen.
Nadelen: de extra eenheid kan weinig waarde toevoegen, klanten blijven valuta omrekenen en regionale prijzen en kortingen bemoeilijken de gelijkwaardigheid.
Als de omrekenfactor vast en zichtbaar is, overweeg dan of het simpelweg tonen van de valuta niet duidelijker zou zijn.
Abstractie van een productactie
Eén credit komt ongeveer overeen met een kleine actie in het product. Grotere acties verbruiken een veelvoud daarvan.
Voordelen: de taal van het product kan intuïtiever zijn, limieten in pakketten kunnen een reeks werkzaamheden vertegenwoordigen en details van technische kosten blijven intern.
Nadelen:
- klanten hebben een omrekentabel nodig;
- wijzigingen in acties kunnen de gepercipieerde waarde veranderen;
- fractionele of heel hoge kosten kunnen onhandig worden.
Abstractie van middelen gewogen naar kosten
Credits weerspiegelen relatieve variabele middelen. Verschillende modellen, resoluties of prioriteiten verbruiken verschillende hoeveelheden.
Voordelen:
- beschermt de marge bij veranderingen in de onderliggende kosten;
- laat gebruikers kwaliteit en snelheid inwisselen tegen saldo;
- werkt goed bij uiteenlopende AI-belasting.
Nadelen:
- kan technische complexiteit indirect zichtbaar maken;
- kosten en waarde voor de klant kunnen uiteenlopen;
- veranderingen in de prestaties van de leverancier vragen om beheer van de tarieven.
De meest volwassen uitrol combineert productacties met kostenweging: herkenbare resultaten worden in hele credits geprijsd en interne telemetrie beschermt de marge.
De omrekentabel
De omrekentabel is de eigenlijke prijslijst. Behandel haar als een openbare commerciële overeenkomst, niet als een verborgen configuratiewaarde.
Bepaal voor elke actie:
- de naam van de actie en de toestand van het product;
- het basisaantal credits;
- de dimensie van de hoeveelheid, indien aanwezig;
- de vermenigvuldiger voor model, kwaliteit of snelheid;
- de regel voor afronding;
- de schatting die vóór bevestiging wordt getoond;
- de regel voor de eindafrekening;
- hoe fouten en annuleringen worden afgehandeld;
- de geldende versie en datum.
Geef de voorkeur aan bedragen die je makkelijk onthoudt. Een typische actie die 7,384 credit kost, wekt een schijn van precisie en is lastig te plannen. Hele credits of begrijpelijke stappen werken meestal beter.
Toon totalen voor representatieve processen, niet alleen voor losse acties:
| Proces | Onderdelen | Verwacht verbruik van credits |
|---|---|---|
| Eén productfoto voorbereiden | Achtergrond verwijderen + standaard genereren | 14 |
| Een campagneset maken | 8 standaardafbeeldingen + 2 varianten met hoge resolutie | 166 |
| Een korte clip maken | Storyboard + rendering van 30 seconden | 96 |
Een schatting per proces helpt kopers een pakket van 1.000 credits te vertalen naar bruikbare resultaten.
Verberg het variabele verbruik niet
Sommige acties zijn vooraf niet precies te prijzen. Het genereren van tekst kan afhangen van de lengte van het resultaat, een agent kan meerdere tools aanroepen en een videotaak kan herhalingen vragen.
Pas een van de vier patronen toe.
Vaste kosten per actie
Reken hetzelfde aantal credits voor een gedefinieerde bewerking en neem de gewone variabiliteit voor eigen rekening. Dat geeft de beste voorspelbaarheid wanneer de variabiliteit beperkt is.
Schatting vóór uitvoering
Schat het verbruik in op basis van de invoer en de gekozen instellingen. Toon een bereik of het maximum voordat de klant bevestigt.
Reservering en afrekening
Reserveer een hoeveelheid die als bovengrens dient, voer de bewerking uit en reken het werkelijke verbruik af. Geef het resterende deel direct vrij.
beschikbaar saldo na reservering = beginsaldo − gereserveerde credits
eindsaldo = beginsaldo − afgerekende credits
Maximum dat de gebruiker bepaalt
Laat de klant een limiet instellen voor credits, lengte van het resultaat, aantal stappen of kwaliteitsniveau. Stop de actie op gecontroleerde wijze zodra de limiet is bereikt.
Laat een autonoom proces nooit de hele wallet van een organisatie leegmaken zonder zichtbaarheid of beveiligingen. Gebruik budgetten en subwallets voor agents, projecten en API-sleutels.
Een echt register voor de wallet
Het saldo van een wallet is financiële infrastructuur. Sla het niet op als één aanpasbaar getal zonder transactiegeschiedenis.
Houd een register bij dat alleen wordt aangevuld (append-only) of volledig controleerbaar is, met duidelijke transactietypen: aankoop, toekenning via abonnement, promotionele toekenning, reservering, afrekening, vrijgave, restitutie, handmatige correctie, vervallen, overdracht, terugboeking na een chargeback.
Reservering, afrekening en vrijgave moeten aparte typen zijn. Een credit die voor lopend werk is vastgehouden, is niet uitgegeven en niet beschikbaar, en een register dat die toestand niet kan uitdrukken, gaat van de werkelijkheid afwijken.
Elke transactie bevat een uniek ID, account en wallet, bedrag en richting, categorie van het saldo, bron-actie of bestelling, idempotentiesleutel, tijdstempel, batch met vervaldatum, versie van de omrekentabel, actor of systeem en reden samen met metadata voor audit.
De versie van de omrekentabel maakt het mogelijk om een jaar later de vraag "waarom kostte dit twaalf credits" te beantwoorden.
Bereken het saldo op basis van registervermeldingen of houd een afgestemde projectie bij. Product, factureringssysteem en supportpaneel moeten overeenstemmen.
De geschiedenis die de klant ziet, moet interne vermeldingen in begrijpelijke taal vertalen. "Registercorrectie van type R-17" is geen voldoende verklaring voor een ontbrekend saldo.
Gekocht saldo, saldo uit het pakket en promotiesaldo
Credits die op verschillende manieren zijn verkregen, kunnen onder verschillende voorwaarden vallen. Bewaar ze in aparte batches of categorieën.
Gekochte credits
De klant heeft rechtstreeks voor het saldo betaald. Regels voor restitutie, vervallen en overdracht kunnen onder regelgeving vallen en moeten behoudend zijn.
Limiet uit het abonnement
Een terugkerend pakket kent credits toe voor een bepaalde tijd. Een ongebruikte limiet kan op nul worden gezet, binnen vaste grenzen naar de volgende periode worden overgedragen of zich opstapelen. Presenteer deze regel duidelijk.
Promotionele credits
Toekenningen voor proefgebruik, doorverwijzing of compensatie kunnen een kortere geldigheid en een smallere reikwijdte hebben. Ze mogen gekochte credits bij het afrekenen niet stilzwijgend vervangen.
Servicecredits
Compensatie voor een storing kan beperkt zijn tot toekomstige diensten en onder andere contractuele regels vallen dan een terugbetaling in geld.
Bepaal de volgorde van verbruik. Een gangbare regel is eerst het saldo te gebruiken dat het vroegst vervalt, en gekochte middelen te beschermen tegen onnodig vervallen. Toon klanten welke batches er nog zijn en wanneer ze vervallen.
Gaan credits over naar de volgende periode of vervallen ze
Vervallen verandert gedrag en economie.
Periodieke limiet die op nul wordt gezet
Een maandabonnement omvat credits die in de betreffende factureringsperiode beschikbaar zijn. Op nul zetten beperkt de economie van het pakket en is klanten bekend, maar in maanden met minder gebruik kunnen ze het als waardeverlies ervaren.
Beperkte overdracht
Een ongebruikte limiet kan een vast aantal maanden of tot een bepaald plafond worden overgedragen. Zo kun je wisselende vraag opvangen zonder een onbeperkte verplichting te creëren.
Gekocht saldo zonder vervaldatum
Dat is het eenvoudigst te rechtvaardigen als opgeslagen betaalde waarde. Het creëert langdurige verplichtingen tot dienstverlening en vraagt om een beleid voor inactief saldo.
Gekocht saldo met vervaldatum
Dat kan verplichtingen uit oude prijzen vereenvoudigen en aanzetten tot gebruik, maar het brengt risico's mee voor vertrouwen, recht en boekhouding. Maak de vervaldatum vóór de aankoop bekend, stuur herinneringen en baseer de belangrijkste bron van marge niet op ongebruikte waarde.
Vervallen van promotionele credits
Toekenningen met een tijdslimiet komen vaak voor en zijn doorgaans makkelijker uit te leggen wanneer de datum duidelijk is.
Modelleer de verplichting uit het resterende saldo en het verwachte gebruik. Ongebruikt saldo (credits die nooit zijn gebruikt) kan de boekhouding raken, maar mag niet opzettelijk worden voortgebracht door ondoorzichtigheid.
Omvang van pakketten en limieten
Het ontwerp van pakketten en limieten beïnvloedt toegankelijkheid, geldstromen en de effectieve prijs per eenheid.
Kleine pakketten
Ze verlagen de drempel om te beginnen met testen en passen bij gebruikers die sporadisch werken. Betalingskosten en support kunnen ze onrendabel maken.
Grote pakketten
Ze verbeteren de inning en kunnen kortingen op hoeveelheid ondersteunen. Ze vergroten het risico op restituties, vervallen en ongebruikte aankopen.
Limiet uit het abonnement
Dit levert terugkerende omzet op en geeft klanten regelmatig toegang tot middelen. De limiet moet overeenkomen met een herkenbaar volume aan processen.
Automatische opwaardering
Voegt een pakket toe wanneer het saldo onder een drempel zakt. Laat klanten kiezen: het bedrag van de opwaardering, het saldo dat de opwaardering activeert, de maandelijkse limiet voor opwaarderingen, de betaalmethode en de ontvangers van meldingen.
Schakel automatische opwaardering nooit in op basis van onduidelijke toestemming. De klant moet de functie kunnen pauzeren zonder de toegang tot het account uit te schakelen.
Verplichting van een organisatie
Een onderneming kan een jaarlijkse pool credits kopen die door projecten wordt gedeeld. Bepaal de regels voor samenvoegen, debet, vervallen, vastzetten van tarieven en rapportage.
Gebruik een tabel om de effectieve prijzen uit te leggen:
| Aankoop | Credits | Prijs | Effectieve prijs van één credit |
|---|---|---|---|
| Klein pakket | 500 | 15 € | 0,030 € |
| Standaardpakket | 2.000 | 54 € | 0,027 € |
| Volumepakket | 10.000 | 240 € | 0,024 € |
Als de kortingen groot zijn, controleer dan of klanten het saldo niet ongewild kunnen doorverkopen of overdragen.
Credits en unit economics
Voor elke actie:
omzet uit de actie = verbruikte credits × gerealiseerde omzet per credit
contributiemarge van de actie = omzet uit de actie − variabele kosten van de actie
De gerealiseerde omzet per credit hangt af van de gebruikte batch. Promotionele credits leveren mogelijk geen directe omzet op, credits uit het abonnement hebben de waarde van het pakket toegewezen gekregen en kortingspakketten hebben lagere gerealiseerde tarieven.
Volg de contributiemarge naar type actie, model of leverancier, kwaliteitsinstelling, cohort van klanten, bron van acquisitie, bron van credits, omvang van het pakket en percentiel van het verbruik.
De bron van de credits staat niet toevallig in deze doorsnede. Verbruik dat met promotionele toekenningen is gefinancierd, heeft kosten en geen omzet, en door het te vermengen met gekochte credits blijft verborgen waar de marge werkelijk zit.
Bereken de marge niet op basis van de nominale catalogusprijs als het grootste deel van het gebruik uit kortingscredits, credits uit het pakket of promotionele credits komt.
Voer stresstests uit voor:
- de langste toegestane invoer;
- resultaten met de hoogste resolutie;
- herhaalde pogingen;
- een lage hitratio van de cache;
- prijsverhogingen van externe diensten;
- veranderingen in wisselkoersen;
- gebruikers die uitsluitend de actie met de laagste marge kiezen;
- jaarlijkse saldi die volgens de oude omrekentabel zijn gekocht.
Een gemengde economie van credits kan kruissubsidiëring verbergen. Dat kan acceptabel zijn, als het bedoeld en begrensd is.
Geef de omrekentarieven versies
Productacties en kosten van uitvoering veranderen. Daarom heeft de omrekentabel versiebeheer nodig.
Een wijziging van een tarief moet vastleggen:
- de acties waarop de wijziging betrekking heeft;
- het nieuwe aantal credits;
- de ingangsdatum;
- hoe werk in de wachtrij wordt behandeld;
- hoe bestaande abonnementen worden behandeld;
- hoe gekocht saldo wordt behandeld;
- de communicatie met klanten;
- het plan voor migratie en voor het terugdraaien van de wijziging.
Het meest gevoelig is het saldo dat al is gekocht. Door de prijs te wijzigen van wat de klant heeft betaald, verandert de waarde van de middelen die hij al heeft overgedragen, en zo zal de klant het ook omschrijven.
Een verhoging van de kosten van een actie van 10 naar 15 credits is een effectieve prijsverhoging van 50 % voor hetzelfde resultaat. Behandel die met dezelfde zorg als een wijziging van een prijs in valuta.
Mogelijke waarborgen zijn onder meer:
- een termijn van aankondiging;
- tijdelijke toegang tot het oude tarief voor bestaande verplichtingen;
- toekenning van extra saldo;
- omrekening van oude credits naar behouden geldwaarde;
- de keuze voor een nieuw model met een ander tarief;
- een wijziging van de prijs van het pakket in plaats van een ongemerkte wijziging van het verbruik.
Herschrijf historische vermeldingen in het register niet volgens de nieuwe tabel. Elke afrekening moet de versie van het tarief bewaren die op dat moment is toegepast.
Wijzigingen van modellen en leveranciers
AI-producten kunnen van leverancier wisselen, prompts optimaliseren of modellen met andere kosten en kwaliteit invoeren.
Houd waar mogelijk interne ID's van modellen gescheiden van duurzame serviceklassen die de klant ziet. De actie "Standaardafbeelding" kan stabiel blijven wanneer de leverancier de implementatie verbetert, zolang de kwaliteit van het resultaat en de economie binnen de samengestelde belofte blijven.
Toon tarieven voor specifieke modellen wanneer de keuze van het model zelf ertoe doet: klanten kunnen bepaalde mogelijkheden, vertraging, leverancier of databeleid eisen. Toon in dat geval vóór gebruik de exacte kosten in credits.
Als optimalisatie de variabele kosten verlaagt, kan de leverancier de tarieven handhaven, het verbruik van credits verlagen of de dienst in het pakket verbeteren. Beoordeel concurrentie, waarde en marge in plaats van automatisch uit te gaan van kostprijs plus.
Als de kosten plotseling stijgen, vermijd dan het met terugwerkende kracht verlagen van saldi. Gebruik limieten, tijdelijke controle op beschikbaarheid en wijzigingen van tarieven voor de toekomst.
Reserveringen, annuleringen en foutafhandeling
Dure asynchrone acties vragen om duidelijke overgangen tussen toestanden.
Een betrouwbaar proces:
- schat het maximale aantal credits in;
- bevestig dat het beschikbare saldo voldoende is;
- maak een idempotente reservering;
- voer de actie uit;
- reken bij succes de werkelijk verschuldigde credits af;
- geef het resterende deel vrij;
- draai de afrekening automatisch terug bij een in aanmerking komende fout.
Definieer de uitkomsten:
| Uitkomst | Hoe credits worden afgerekend |
|---|---|
| De leverancier wijst het verzoek af voordat het werk begint | Geen afrekening; geef de reservering vrij |
| Fout die door de leverancier is veroorzaakt | Geef credits automatisch vrij of betaal ze terug |
| Dubbele herhaling door de klant met dezelfde idempotentiesleutel | Eén reservering en één afrekening |
| De klant annuleert voordat dure werkzaamheden beginnen | Geef de reservering vrij |
| De klant annuleert na aanzienlijke verwerking | Pas de bekendgemaakte gedeeltelijke of volledige vergoeding toe |
| Gedeeltelijk bruikbaar resultaat | Pas de gepubliceerde regel voor een gedeeltelijk resultaat toe |
| Afwijzing op grond van het inhoudsbeleid | Laat vóór het verzenden weten of de controle kosten met zich meebrengt |
Het product mag een reservering nooit onbeperkt laten staan. Gebruik afstemming na overschrijding van de tijdslimiet en een status die de klant ziet.
Negatieve saldi en race conditions
Parallelle verzoeken kunnen meer verbruiken dan het beschikbare saldo van de wallet als reserveringen niet atomair zijn.
De vereisten zijn onder meer:
- atomaire controle van het saldo en het maken van reserveringen;
- idempotentie van herhaalde verzoeken;
- deterministische volgorde of afhandeling van conflicten;
- controle op gelijktijdigheid op het niveau van de organisatie;
- limieten voor negatief saldo;
- herstel na vertraagde meting;
- afstemmingstaken;
- meldingen bij schending van invarianten.
Bepaal of een begrensd debet is toegestaan. Zakelijke accounts met betaling achteraf kunnen een kredietlijn hebben; zelfbedieningsaccounts met vooruitbetaling kunnen de actie stoppen wanneer het beschikbare saldo ontoereikend is.
Als het product een negatief saldo toestaat tijdens een vertraagde afrekening, toon dan het openstaande gebruik en laat het dashboard het vorige bedrag niet als veilig beschikbaar presenteren.
Teams, projecten en kostenplaatsen
Eén wallet voor de hele organisatie kan te breed zijn. Een team moet weten wie wat heeft verbruikt.
Bied aan:
- gebruik per werkruimte, project en API-sleutel;
- labels of tags voor kostenplaatsen;
- projectbudgetten;
- limieten voor subwallets;
- rolgebaseerde rechten voor aankopen;
- drempels voor goedkeuring;
- gecentraliseerde opwaardering;
- geconsolideerde exports van transacties.
Drempels voor goedkeuring en subwallets maken credits aanvaardbaar voor het financiële team. Zonder die middelen is een gedeeld saldo een niet-toegewezen budget dat elk team kan uitgeven.
Een subwallet kan een deel van het saldo van de organisatie reserveren zonder een aparte aankoop te doen. Bepaal of ongebruikte toewijzingen automatisch terugkeren.
Dwing niet elke gebruiker om persoonlijke credits te kopen wanneer de organisatie de betaler is. Persoonlijke wallets kunnen waarde versnipperen en het inkoopproces bemoeilijken.
Leg de prijsstelling in credits uit op het punt van aankoop
De prijspagina moet direct vier vragen beantwoorden:
- Hoeveel credits bevat het pakket of de aankoop?
- Wat kosten typische acties?
- Wat gebeurt er wanneer het saldo nul bereikt?
- Gaan credits over naar de volgende periode of vervallen ze?
Toon vervolgens:
- de volledige omrekentabel;
- voorbeelden van processen;
- een calculator;
- tarieven voor opwaarderingen;
- verschillen tussen modellen en kwaliteitsniveaus;
- regels voor restituties en foutafhandeling;
- schermafbeeldingen of beschrijvingen van het dashboard voor gebruik;
- regels voor delen en verplichtingen voor ondernemingen.
Vertrouw niet op de formulering "tot 1.000 gegenereerde resultaten" als de normale instellingen er veel minder opleveren. Geef de aannames en een realistisch bereik.
Toon waar dat praktisch is de valuta naast de credits bij het afrekenen en in de geschiedenis van gebruik. Het doel is begrip, niet het maximaliseren van het aantal stappen dat nodig is om de effectieve prijs te ontdekken.
Begrijpen klanten credits
Credits creëren twee lagen van omrekening:
valuta → credits → productresultaten
Test ze allebei.
Geef deelnemers een pakket, een omrekentabel en een scenario. Vraag:
- Hoeveel processen kun je afronden?
- Wat is de effectieve prijs van één standaardresultaat?
- Welke bewerking verbruikt het meest?
- Wat gebeurt er met ongebruikt saldo?
- Wat gebeurt er als het saldo ontoereikend is?
- Verandert een andere kwaliteitsinstelling de kosten?
Leg het rekenproces vast, niet alleen of de deelnemer credits waardeert. Herhaalde rekenfouten wijzen erop dat de abstractie te moeilijk is.
Vergelijk credits met alternatieven die rechtstreeks op valuta en eenheden zijn gebaseerd. Credits moeten winnen omdat ze een uiteenlopend product vereenvoudigen, niet omdat het bedrijf een interface prefereert die op een spel lijkt.
Test de economie van credits in schaduwmodus
Voordat echte saldi de toegang gaan regelen, pas je de omrekentabel toe op gebeurtenissen die op productie lijken.
Meet vóór de lancering of een wijziging van het model het verwachte aantal credits per account, of typische scenario's binnen bereik blijven, het tempo waarmee saldi opraken, de marge per actie, de nauwkeurigheid van reserveringen, restituties na storingen, conflicten tussen parallelle bewerkingen, de kosten van promoties, het verwachte ongebruikte saldo en uitschieters onder de accounts.
De beschikbaarheid van typische scenario's beschermt de adoptie. Als een routinetaak een merkbaar deel van de maandlimiet opslokt, zullen klanten ermee ophouden en het product duur noemen.
Geef testgebruikers vervolgens zichtbare schaduwsaldi. Vraag of het tempo waarin die opraken overeenkomt met het mentale model van gebruikers. Een technisch correct register kan commercieel nog steeds onbegrijpelijk zijn.
Test de grenzen van maanden, het toekennen van limieten, wijzigingen van abonnementen, restituties, vervallen batches, overgedragen werkruimtes en versies van omrekentarieven.
Implementatieplan van zes weken
Week 1: definieer het doel en de acties
- Noem de factureerbare productacties en de processen van klanten.
- Breng de variabele kosten en de waarde van elke actie in kaart.
- Bepaal waarom credits beter zijn dan directe valuta of eenheden van gebruik.
- Stel een eenvoudige omrekentabel op.
Week 2: ontwerp het beleid voor saldo
- Scheid gekochte batches, batches uit het pakket en promotionele batches.
- Definieer overdracht, vervallen en volgorde van verbruik.
- Kies pakketten, limieten uit het abonnement en de manier van opwaarderen.
- Beoordeel juridische en boekhoudkundige kwesties.
Week 3: bouw het register en de reserveringen
- Implementeer idempotente transacties van de wallet.
- Voeg toestanden toe voor reservering, afrekening, vrijgave en restitutie.
- Beveilig gelijktijdige updates van het saldo.
- Maak tools voor afstemming en audit.
Week 4: modelleer en onderzoek
- Speel echte acties opnieuw af volgens de omrekentabel.
- Test de kosten en de marge onder extreme omstandigheden.
- Test de berekeningen van processen met klanten.
- Corrigeer onbegrijpelijke waarden en acties met een lage marge.
Week 5: lancering in schaduwmodus
- Toon niet-bindende saldi en een transactiegeschiedenis.
- Test meldingen over het opraken van saldo en controle op opwaarderingen.
- Stem elke fout en elke overschrijding van de tijdslimiet van reserveringen af.
- Train support in het onderzoeken van saldo.
Week 6: gecontroleerde betaalde pilot
- Schakel een beperkte cohort in onder bekendgemaakte voorwaarden.
- Monitor aankopen, verbruik, opwaarderingen en contributiemarge.
- Analyseer dagelijks misverstanden en geschillen.
- Besluit of je de abstractie uitbreidt, verbetert of verwerpt.
Indicatoren voor producten op basis van credits
| Gebied | Indicator | Wat het onthult |
|---|---|---|
| Activatie | Accounts die de eerste waardevolle actie met credits uitvoeren | Of toekenningen tot echt gebruik van het product leiden |
| Begrip | Contact met support over prijzen en saldo | Of de abstractie begrijpelijk is |
| Verbruik | Verbruikte credits per actie en cohort | Productmix en de manier waarop saldi opraken |
| Conversie | Accounts met een proeftoekenning die credits kopen | Commerciële kwaliteit van gratis gebruik |
| Herhaalde aankoop | Accounts die opnieuw kopen of opwaarderen | Terugkerende bruikbaarheid buiten het label abonnement |
| Benutting van de limiet | Verbruikte / toegekende credits uit het abonnement | Aansluiting van het pakket en risico bij verlenging |
| Ongebruikt saldo | Vervallen of inactief saldo per bron | Ongebruikte waarde en bestaande verplichting |
| Economie | Contributiemarge per actie en bron van credits | Rendement bij kortingen en toekenningen |
| Betrouwbaarheid | Afwijkingen in het register en overschrijdingen van de tijdslimiet van reserveringen | Integriteit van de infrastructuur van de wallet |
| Vertrouwen | Restituties, betwiste afschrijvingen en onverwacht opraken | Eerlijkheid en transparantie |
| Concentratie | Aandeel in verbruik per actie en account | Afhankelijkheid en blootstelling van de marge |
Volg omzet in geld en geldstromen apart van het verbruik van credits. De verkoop van een pakket en het gebruik ervan zijn verschillende economische gebeurtenissen.
Typische oorzaken van mislukking
Willekeurige wisselkoers
Het product kiest een groot fictief getal dat niet helpt bij het plannen. Klanten rekenen nog steeds alles terug naar valuta.
Verborgen kosten van acties
Gebruikers leren het aantal credits pas kennen nadat ze hebben geklikt. Het opraken van het saldo voelt willekeurig.
Stille inflatie
Hetzelfde resultaat gaat meer credits verbruiken, maar de wijziging wordt niet als prijsverhoging behandeld.
Ongebruikt saldo als strategie
Omvang van pakketten en vervaldatums worden zo ontworpen dat klanten regelmatig betaalde waarde verliezen. Marge op korte termijn leidt tot langdurig wantrouwen.
Eén aanpasbaar saldo
Gekochte en promotionele waarde worden zonder geschiedenis vermengd. Support kan vervallen en restituties niet uitleggen.
Kosten rekenen voor fouten van de leverancier
Mislukte taken en automatische herhalingen verbruiken credits. De leverancier profiteert van onbetrouwbaarheid.
Geen systeem voor reserveringen
Parallelle dure bewerkingen overschrijden het saldo van de wallet of eindigen met een fout nadat het werk is geleverd.
Onbeperkt verbruik door een agent
Automatisering kan de waarde van de hele organisatie verbruiken zonder projectbudget of maximum.
Analyse van de nominale marge
Het team waardeert elke verbruikte credit tegen de catalogusprijs van het pakket, terwijl die uit een korting, een toekenning of een limiet in het abonnement kwam.
Te veel complexiteit in de omrekening
Modellen, instellingen en functies creëren tientallen vermenigvuldigers. Credits vereenvoudigen de prijslijst niet meer.
Praktische checklist voor prijzen op basis van credits
Strategische match
- Credits vereenvoudigen meerdere uiteenlopende factureerbare acties.
- Directe valuta of één natuurlijke eenheid zou niet duidelijker zijn.
- Klanten kunnen het saldo koppelen aan herkenbare processen.
- Vooruitbetaling of een limiet creëert echte waarde voor de klant of in het risicobeheer.
- Het systeem is niet vooral ontworpen om de prijs te versluieren.
Omrekentabel
- Elke actie heeft zichtbare kosten in credits met versiebeheer.
- Typische processen hebben realistische voorbeelden.
- Acties met variabele kosten tonen vóór uitvoering schattingen of het maximum.
- Regels voor afronding, model, kwaliteit en fouten zijn openbaar.
- Wijzigingen van de effectieve prijs vallen onder prijstoezicht.
Wallet en beleid
- Gekochte, abonnements-, promotionele en servicebatches zijn gescheiden.
- Regels voor overdracht, vervallen en volgorde van verbruik zijn bekendgemaakt.
- Vermeldingen in het register zijn onveranderlijk of volledig controleerbaar.
- Reserveringen en afrekeningen zijn atomair en idempotent.
- Restituties en correcties bewaren verwijzingen naar de bron.
Controle door de klant
- Actuele, openstaande en vervallende saldi zijn zichtbaar.
- Transacties gebruiken begrijpelijke productentaal.
- Automatische opwaardering vraagt om expliciete, instelbare toestemming.
- Projecten en API-sleutels kunnen budgetten of limieten hebben.
- Meldingen komen aan vóór het opraken of bij ongebruikelijk verbruik.
Economie en bewijs
- De contributiemarge is gemodelleerd per actie en bron van credits.
- Promotionele toekenningen en kortingen zijn opgenomen in de gerealiseerde economie.
- Historische acties zijn in schaduwmodus geprijsd.
- Grote belasting en parallelle bewerkingen zijn getest.
- Klanten kunnen berekenen of een typisch proces binnen het saldo past.
- Succes omvat terugkerende waarde, vertrouwen en marge, niet alleen de verkoop van credits.
Credits moeten leesbaar blijven
Credits moeten een uiteenlopend product vereenvoudigen tot één begrijpelijk saldo. Ze moeten klanten laten plannen met nuttig werk, kiezen tussen acties en hun uitgaven beheersen, terwijl de leverancier de variabele kosten kan dekken.
Zorg dat de omrekentabel zichtbaar is. Scheid de bronnen van saldo, bewaar een controleerbaar register, reserveer credits vóór dure werkzaamheden en geef ze bij fouten automatisch terug. Behandel elke wijziging in het verbruik van credits als een prijsbesluit, niet als een stille update van de configuratie.
Een gezonde economie van credits meet je niet aan de hoeveelheid gekochte waarde die vervalt. Je meet haar aan de vraag of klanten begrijpen wat ze kunnen bereiken, credits verbruiken voor waardevolle resultaten en hun saldo uit eigen beweging aanvullen.