Services-as-Software er en omskrivning af bruttoavance — ikke et product pivot

Jeg kan godt lide ambitionen bag “Services-as-Software”. ZDNET-argumentet har ret i retningen: AI gør mere service delivery til noget, der kan pakkes, gentages og sælges med software-lignende økonomi.

Men de fleste teams begår en fejl, der er så basal, at det er pinligt. De behandler det som et product shift. De budgetterer det som klassisk SaaS. Og så vågner de seks måneder senere op med “AI features”, der opfører sig som et bureau, der ikke kan skaleres.

Mit operator-perspektiv er enkelt: Services-as-Software er en omskrivning af bruttoavance. Hvis du ikke meter og kontrollerer variabilitet, æder kanterne dit P&L længe før omsætningen ser “AI-powered” ud.

Jeg har set samme mønster i to verdener. I industrielle serviceorganisationer gemmer variabiliteten sig i marken: rejse, fejlsøgningstid, reservedele og eskalationer. I SaaS gemmer variabiliteten sig i support og delivery: custom workflows, dataoprydning, integrationer og nu tokens og human-in-the-loop-minutter. Forskellig overflade. Samme sygdom.

Modelsiftet er ikke “AI features”. Det er cost-to-serve-indsigt.

Klassisk SaaS-unit economics antager, at marginalomkostningen primært er infrastruktur og support, og at begge skalerer rimeligt med omsætningen. Services-as-Software bryder den antagelse, fordi delivery bliver en hybrid af:

• Compute-variabelt arbejde (tokens pr. workflow, retrieval-kald, model eval, batch jobs).
• Menneske-variabelt arbejde (review-minutter, exception handling, onboarding, data-korrektion, kundetræning).
• Support-variabelt arbejde (tickets, incidents, “hvorfor gjorde modellen det her?”-eskalationer).

Hvis du ikke eksplicit meter de tre, kan du ikke styre bruttoavance. Du kører blindt.

Da jeg ledede en international business unit inden for smart-building og home automation, lærte jeg en hård lektie om connected products: hardware-margin er ikke system-margin. Returer, remote support, firmware-edge cases, installatørfejl og leverandørvariabilitet skaber usynlige omkostninger, medmindre du instrumenterer det. AI delivery er den samme historie — bortset fra at variabiliteten nu ligger inde i dine workflows og prompts.

Fælden: du prissætter sikkerhed, men leverer variabilitet

De fleste Services-as-Software-tilbud sælges, som om leverandøren kan forudsige workload per kunde. Fast pris. All-inclusive. “Unlimited”. Det lukker deals. Det subsidierer også de mest støjende accounts og straffer de stille.

I industrielt tech foregav vi aldrig, at service var ubegrænset. Du har warranty-vilkår. Du har service-level tiers. Du har tydelige inklusioner og eksklusioner. Og du tracker failure modes, fordi de driver omkostninger. SaaS-teams springer ofte den disciplin over, fordi software historisk kunne tåle det. Det kan AI ikke.

ZDNET-artiklen indrammer Services-as-Software som den næste model. Jeg er enig i retningen. Det, jeg ikke er enig i, er den implicitte lethed. Den svære del er ikke at shippe assistenten. Den svære del er at gøre delivery til en kontrolleret proces med målbare inputs og afgrænsede outputs.

Hvis emnet rammer noget hos dig, hænger det tæt sammen med ejerskab af workflows. Jeg skrev om det her: AI Leadership Is Workflow Leadership: Own the Handoffs. Hvis du ikke ejer handoffs, kommer du heller ikke til at eje omkostningen.

Instrumentér hver AI-touch, som du instrumenterer cloud spend

Her er den operationelle baseline, jeg ville etablere i dette kvartal. Ikke næste år. Dette kvartal.

1) Definér “unit of work” pr. produkt-workflow

Vælg 3 til 5 workflows, der betyder noget kommercielt. Eksempel: “generér og godkend et kundesvar”, “udarbejd et compliance-resumé”, “klassificér en inbound request og route den”. Hvert workflow får en unit-definition, du kan tælle.

2) Meter de tre omkostningsdrivere pr. unit

• Tokens og tool calls: gennemsnit, p95 og max. Ikke af nysgerrighed. For at styre varians.
• Human-in-the-loop-minutter: review, korrektion, eskalation. Track hvem der gør det, og hvorfor.
• Support load: tickets pr. 100 units, incident rate, tid til løsning.

I mine år i power electronics handlede quality leadership mest om måledisciplin: definér failure modes, fang dem konsistent, og feed dem ind i corrective action. AI delivery har brug for samme muskel. Metering er din “field return analysis”.

3) Etablér en “cost-to-serve ledger” pr. account

Ikke et dashboard, der ser pænt ud. En ledger, der kan svare på: denne account forbrugte X units, skabte Y exceptions, krævede Z minutters menneskearbejde og udløste N support events.

Hvis du ikke kan producere den ledger, kan du ikke prissætte rationelt — og du kan ikke have en voksen renewal-samtale.

4) Byg guardrails ind i produktet — ikke i policy docs

• Rate limits, quotas og backoff-adfærd.
• Disciplin omkring context window og retrieval caps.
• Workflow timeouts og graceful degradation (fallback templates, reduced depth modes).
• Eskalationsregler, der kan auditeres.

Det er her, mange teams forveksler “AI architecture” med diagrams. Det her er en kontrol-checkliste, der kører hver dag. Hvis du vil have en parallel, så se: AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

Redesign pricing: outcomes plus usage, med hårde inklusioner

Når du kan meter cost-to-serve, bliver pricing et engineering- og packaging-problem — ikke en debat i et mødelokale.

Jeg bruger en enkel regel: sælg outcomet, fakturér variabiliteten.

• Outcome-komponent: hvad kunden køber (hurtigere resolution, højere throughput, færre fejl). Det forankrer værdien.
• Usage-komponent: hvad der driver din marginalomkostning (units processed, tokens, workflow runs, tool calls). Det beskytter marginen.
• Exception-komponent: det, der bryder standard delivery (custom integrationer, usædvanlig data prep, high-risk review). Det er enten et betalt tier eller en professional service.

Skjul ikke exceptions. Navngiv dem. Put dem i kontrakten og i product packaging. I industriel service har warranty grænser af en grund. I AI services er “unlimited” uden guardrails bare udskudt margin-tab.

Det er også derfor, jeg bliver ved med at gentage, at Pricing Is Product Management in Disguise. Pricing tvinger dig til at definere produktets overflade. AI udvider den overflade. Hvis du ikke afgrænser den, gør kunderne det for dig — via churn eller eskalationer.

Et mønster fra virkeligheden: i det øjeblik du stopper med at gætte, bliver modellen skalerbar

Da jeg byggede og drev SaaS-produkter (bl.a. EatMore og senere mine egne ventures som IBHQ), var den farlige fase altid den samme. Tidlig traction trækker dig ind i bespoke delivery. Du kalder det “customer success”. Det er i praksis manuelle operationer.

AI forstærker det, fordi bespoke arbejde føles hurtigt. Du kan lappe et workflow med en prompt. Du kan tilføje et hurtigt reviewer-step. Du kan håndholde onboarding. Omsætningen kommer ind. Bruttoavancen eroderer stille og roligt.

Vendepunktet kommer, når du stopper med at diskutere, om noget er “product” eller “service”, og i stedet behandler det som en produktionslinje:

• Mål hvert trin.
• Reducér varians dér, hvor det betyder noget.
• Route exceptions til en betalt vej.
• Feed failure modes tilbage i workflow-designet.

Hvis du ikke kan forklare din cost-to-serve pr. workflow på én side, har du ikke Services-as-Software. Du har et bureau med en UI.

Mit beslutningsfilter for dette kvartal

Hvis du overvejer et Services-as-Software-play, ville jeg træffe tre beslutninger nu.

1. Vælg de workflows, du vil industrialisere. Ikke alt. Start med dem, der har gentagelig struktur og tydelig værdi.
2. Forpligt jer på metering som en first-class product feature. Tokens, menneskeminutter og support events. Ingen metering, ingen skala.
3. Omprissæt før du skalerer distribution. Hvis du skubber go-to-market på en broken unit model, accelererer du margin-kollaps.

Min klare holdning: Services-as-Software vinder, men kun for teams, der driver det som manufacturing. Instrumentér linjen. Kontrollér variabilitet. Prissæt exceptions. Alt andet er teater.

Hvis du vil pressure-teste dine unit economics og din packaging for en AI-assisted service, så ræk ud via kontakt-siden og fortæl mig, hvilket workflow du prøver at skalere.