One services engagement can look healthy in one report and dangerous in another.

Delivery sees a working implementation. Sales sees product consumption. Product sees requirements that could not have been learned in a lab. Finance sees senior labor, irregular scope, and support exposure. The client sees either a capability it can operate or a dependency it did not intend to buy.

“Are services good for software?” collapses those views into a false binary. A more useful analysis keeps four ledgers: delivery P&L, product consumption, product learning, and client capability. Services accelerate software when the ledgers reinforce one another. They start eating it when exceptions grow faster than the platform and client can learn.

The four-ledger model is analysis, not a disclosed FDE accounting standard. Public filings provide guardrails. Palantir's 2025 Form 10-K describes platform and professional-services activity and notes that some pilots or bootcamps may be provider-funded without guaranteed return; it does not isolate FDE margin. DocuSign's 2025 Form 10-K reports subscription and professional-services economics separately. That establishes neither an AI-services benchmark nor a cross-company comparison.

With those limits intact, each ledger can support a different decision.

1. Delivery P&L: what did the work consume?

Record whether delivery is paid, bundled, discounted, or provider-funded; which senior skills it uses; who bears integration and production risk; and how exception work changes the scope.

Cash, capacity, and risk matter. Direct delivery economics still cannot settle the whole question. A provider may accept weaker near-term delivery economics when a qualified deployment creates durable product use or strategic learning. That must be demonstrated for the engagement. Vague appeals to “product learning” should not excuse work with no owner or disposition.

2. Product consumption: did use survive the intervention?

Tie consumption to a production workflow. Did users continue after the embedded team stepped back? Did the account adopt another appropriate workflow? Did the deployment expose a product limitation that blocks durable use?

Seats, tokens, and calls are useful instrumentation. Temporary activity during an intensive engagement is not the same as sustained operating consumption.

3. Product and research learning: what entered an owned system?

Valuable field outputs can include evaluation sets, requirements, tools, integration patterns, interface decisions, and platform primitives. OpenAI and Anthropic publicly connect field delivery to product or research feedback. AI-native practitioners describe upstreaming repeated work.

Decagon's company-authored article on redefining forward deployment argues for moving beyond brute-force implementation toward a compounding system. That is Decagon's stated model, not proof that every provider has a working field-to-product loop.

Learning compounds only when an artifact has a destination, product owner, data/IP treatment, and disposition date. Otherwise, “insight” remains a file in the delivery workspace.

4. Client capability: what remains operable?

The client-capability ledger asks who can run, evaluate, change, and govern the workflow after the intervention. Look for a product owner, technical owner, acceptance evidence, access model, tested runbook, change process, and escalation path.

It also records residual support honestly. A continuing managed service may be appropriate. A product limitation may still require vendor escalation. Transfer by design does not promise independence from every future dependency; it makes those dependencies visible and assigns them.

This ledger determines whether consumption and evidence survive. A release that works only while the field team holds undocumented context has not produced durable capability.

Exception debt: the shadow product

Custom work can reveal what a product should become. It becomes debt when recurring exceptions have no disposition and field teams maintain code, prompts, connectors, or promises that behave like a second product. “Exception debt” is an operating concept here, not an accounting line disclosed by the cited companies.

Run a weekly disposition review for every material field-created asset:

  1. Upstream to product when the need recurs and belongs in the platform.
  2. Standardize as a delivery asset when the method repeats outside the core product.
  3. Enable self-service when customers can configure it safely.
  4. Price and govern an exception when one context justifies continuing custom work.
  5. Discard when the experiment has produced its useful learning.

Every item needs an owner, decision date, maintenance boundary, and data/IP treatment. Without those fields, upstreaming is aspiration rather than control.

Let the ledgers change the capacity decision

The review should not collapse into one synthetic score. It should produce a route.

  • Add field capacity when qualified demand produces durable consumption, owned learning, and transferable capability.
  • Upstream product work when recurring delivery blocks scale.
  • Standardize delivery when the method repeats but does not belong in the product.
  • Price an explicit exception when customer-specific work is strategically or commercially justified.
  • Stop accepting the pattern when exceptions consume attention without compounding value.

Those decisions require product, services, finance, and client-operating perspectives in the same review. When the ledgers conflict, name the executive decision owner and record the trade: which near-term cost is being accepted, which future benefit is expected, what evidence will test it, and when the decision will be revisited.

The review also needs a time horizon. Delivery can look expensive before adoption stabilizes, while early consumption can look encouraging before support costs appear. Record the expected sequence and the date at which each ledger should show credible evidence. Otherwise, every disappointing result can be explained away as “too early.”

Services are neither automatically accretive nor inherently a drag. They compound when field work produces durable adoption, owned learning, reusable assets, and client capability. They start eating the software when every urgent request becomes permanent labor and the platform never gets to learn.

Run the four-ledger review before adding capacity. The current portfolio already shows whether the delivery system is compounding or quietly building a shadow product.