Services-as-Software is a gross margin rewrite, not a product pivot

I like the ambition behind “Services-as-Software”. The ZDNET argument is directionally right: AI is turning more service delivery into something that can be packaged, repeated, and sold with software-like economics.

But most teams make one mistake that is so basic it is embarrassing. They treat it as a product shift. They budget it like classic SaaS. Then they wake up six months later with “AI features” that behave like an unscalable agency.

My operator take is simple: Services-as-Software is a gross margin rewrite. If you do not meter and control variability, the edges eat your P&L long before revenue looks “AI-powered”.

I have seen the same pattern in two worlds. In industrial service organizations, variability hides in the field: travel, troubleshooting time, spare parts, and escalations. In SaaS, variability hides in support and delivery: custom workflows, data cleanup, integrations, and now tokens and human-in-the-loop minutes. Different surface area. Same disease.

The model shift is not “AI features”. It is cost-to-serve visibility.

Classic SaaS unit economics assume marginal cost is mostly infrastructure and support, and that both scale reasonably with revenue. Services-as-Software breaks that assumption because delivery becomes a hybrid of:

• Compute-variable work (tokens per workflow, retrieval calls, model eval, batch jobs).
• Human-variable work (review minutes, exception handling, onboarding, data correction, customer training).
• Support-variable work (tickets, incidents, “why did the model do this?” escalations).

If you do not explicitly meter those three, you cannot manage gross margin. You are running blind.

When I ran an international business unit in smart-building and home automation, I learned a hard lesson about connected products: the hardware margin is not the system margin. Returns, remote support, firmware edge cases, installer mistakes, and supplier variability create invisible cost unless you instrument it. AI delivery is the same story, except the variability is now inside your workflows and prompts.

The trap: you price certainty, but you deliver variability

Most Services-as-Software offers are sold as if the vendor can predict the workload per customer. Flat fee. All-inclusive. “Unlimited”. It closes deals. It also subsidizes the noisiest accounts and punishes the quiet ones.

In industrial tech, we never pretended service was unlimited. You have warranty terms. You have service-level tiers. You have clear inclusions and exclusions. And you track failure modes because they drive cost. SaaS teams often skip this discipline because software historically tolerated it. AI will not.

The ZDNET piece frames Services-as-Software as the next model. I agree with the direction. What I disagree with is the implied ease. The hard part is not shipping the assistant. The hard part is turning delivery into a controlled process with measurable inputs and bounded outputs.

If this topic resonates, it is tightly connected to workflow ownership. I wrote about that in AI Leadership Is Workflow Leadership: Own the Handoffs. If you do not own handoffs, you will not own cost.

Instrument every AI-touch like you instrument cloud spend

Here is the operational baseline I would put in place this quarter. Not next year. This quarter.

1) Define the “unit of work” per product workflow

Pick 3 to 5 workflows that matter commercially. Example: “generate and approve a customer response”, “draft a compliance summary”, “classify an inbound request and route it”. Each workflow gets a unit definition that you can count.

2) Meter the three cost drivers per unit

• Tokens and tool calls: average, p95, and max. Not for curiosity. For variance control.
• Human-in-the-loop minutes: review, correction, escalation. Track who does it and why.
• Support load: tickets per 100 units, incident rate, time to resolution.

In my years in power electronics, quality leadership was mostly measurement discipline: define failure modes, capture them consistently, and feed them into corrective action. AI delivery needs the same muscle. Metering is your “field return analysis”.

3) Create a “cost-to-serve ledger” per account

Not a dashboard that looks nice. A ledger that can answer: this account consumed X units, created Y exceptions, required Z minutes of human work, and triggered N support events.

If you cannot produce that ledger, you cannot price rationally, and you cannot have an adult renewal conversation.

4) Put guardrails into the product, not into policy docs

• Rate limits, quotas, and backoff behavior.
• Context window discipline and retrieval caps.
• Workflow timeouts and graceful degradation (fallback templates, reduced depth modes).
• Escalation rules that are auditable.

This is where many teams confuse “AI architecture” with diagrams. It is a checklist of controls that run daily. If you want a parallel, see AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

Redesign pricing: outcomes plus usage, with hard inclusions

Once you can meter cost-to-serve, pricing becomes an engineering and packaging problem, not a debate in a meeting room.

I use a simple rule: sell the outcome, bill the variability.

• Outcome component: what the customer is buying (faster resolution, higher throughput, fewer errors). This anchors value.
• Usage component: what drives your marginal cost (units processed, tokens, workflow runs, tool calls). This protects margin.
• Exception component: what breaks standard delivery (custom integrations, unusual data prep, high-risk review). This is either a paid tier or a professional service.

Do not hide exceptions. Name them. Put them in the contract and the product packaging. In industrial service, warranty has boundaries for a reason. In AI services, “unlimited” without guardrails is just deferred margin loss.

This is also why I keep repeating that Pricing Is Product Management in Disguise. Pricing forces you to define the product surface. AI expands that surface. If you do not constrain it, customers will do it for you, via churn or escalations.

A lived pattern: the moment you stop guessing, the model becomes scalable

When I built and operated SaaS products (including EatMore, and later my own ventures like IBHQ), the dangerous phase was always the same. Early traction pulls you into bespoke delivery. You call it “customer success”. It is really manual operations.

AI amplifies this because it makes bespoke work feel fast. You can patch a workflow with a prompt. You can add a quick reviewer step. You can handhold onboarding. Revenue comes in. Gross margin quietly erodes.

The turning point is when you stop arguing about whether something is “product” or “service” and start treating it as a production line:

• Measure every step.
• Reduce variance where it matters.
• Route exceptions to a paid path.
• Feed failure modes back into the workflow design.

If you cannot explain your cost-to-serve per workflow in one page, you do not have Services-as-Software. You have an agency with a UI.

My decision lens for this quarter

If you are considering a Services-as-Software play, I would make three decisions now.

1. Pick the workflows you will industrialize. Not everything. Start with the ones that have repeatable structure and clear value.
2. Commit to metering as a first-class product feature. Tokens, human minutes, and support events. No metering, no scale.
3. Reprice before you scale distribution. If you push GTM on a broken unit model, you will accelerate margin collapse.

My clear opinion: Services-as-Software will win, but only for teams that operate it like manufacturing. Instrument the line. Control variability. Price the exceptions. Everything else is theater.

If you want to pressure-test your unit economics and packaging for an AI-assisted service, reach out via the contact page and tell me what workflow you are trying to scale.