When AI Cuts the Hours, Your Contract Needs a Better Unit of Value
AI can reduce the time required to complete service work. That does not automatically tell a buyer what the work is worth—or whether the result is usable.
The distinction is becoming commercial, not theoretical. Tata Consultancy Services reported rising AI-related revenue while its traditional services business remained under pressure. Reuters described the broader shift as AI undermining the billable-hour model even as it creates demand for new services.
For an operating business, the practical response is not to avoid AI-enabled providers. It is to buy a defined business result with measurable acceptance criteria, controlled exceptions, and evidence—rather than treating fewer labor hours as proof of value.
What changed
Documented fact: On October 8, 2026, TCS reported results for the quarter ended September 30. The company reported $7.642 billion in quarterly revenue, 0.5% sequential growth in constant currency, a 24% operating margin, and $9.6 billion in total contract value. Manufacturing revenue grew 3.1% sequentially in constant currency.
Company-reported AI measure: TCS said annualized AI revenue reached $3.1 billion, exceeded 10% of revenue, and rose from $2.6 billion in the prior quarter. “Annualized AI revenue” is TCS’s commercial reporting measure. It is not evidence that customers received a particular return, saved a specified number of hours, or achieved independently validated operating outcomes.
Independent reporting: Reuters reported on October 9 that AI is putting downward pressure on prices as it reduces the time required for some tasks, while also creating demand for AI-enabled services. Reuters characterized the shift as a challenge to the traditional billable-hour model.
Analyst opinion, not a settled fact: An analyst quoted by Reuters called the pressure an “AI deflation impact.” Morningstar analysts said they saw a path for further AI-revenue growth at TCS. Those are market interpretations and forecasts, not guarantees about vendor margins, customer savings, or future demand.
Still unresolved: The public materials do not disclose how much of TCS’s AI revenue is fixed-fee, usage-based, outcome-based, or billed by time. They do not establish how the company classifies mixed AI and traditional work, the margin of its AI services, the cost of customer-side process change, or the share of projects that achieve their intended operational result.
Fewer hours are an input change, not a business outcome
A service provider may use AI to draft code, reconcile records, produce product content, analyze tickets, prepare quotes, or test workflows faster. That efficiency can create real value. It can also create a pricing dispute if the buyer measures value only by labor hours while the provider measures value by the deliverable.
The operating question is not “How many hours did the model save?” It is “Did the process produce the right result, at the required quality and risk level, with lower total cost or better service?”
Total cost includes the time spent correcting errors, reviewing exceptions, maintaining integrations, managing model changes, responding to incidents, and completing work manually when the automation cannot proceed. A fast output that requires extensive rework is not an efficient outcome.
Choose a unit of value the business can verify
Before negotiating price, define the unit the operation actually consumes:
- eCommerce: an accepted product record, a correctly resolved return, or an order released without preventable rework.
- Industrial distribution: an accurate quote delivered within the service target, a validated substitute, or an exception routed with complete evidence.
- Manufacturing: a production schedule that passes material, capacity, maintenance, and safety constraints; or a quality record accepted against the control plan.
- Operations: a case resolved at the promised service level, with required approvals and a complete audit trail.
- Marketing: an approved asset that passes brand, rights, claim, and channel checks—not merely a draft generated in seconds.
The unit should be close enough to a business outcome to matter, but specific enough to validate. Revenue growth, “transformation,” and customer satisfaction may be important goals, yet they are often influenced by many factors outside one provider’s control. Use a layered scorecard: output acceptance, cycle time, quality, exception rate, rework, total cost, and downstream operational impact.
Build the baseline before the automation
An outcome contract needs a reference point. Record the current process before deployment:
- volume and seasonality;
- cycle time and queue time;
- first-pass acceptance and rework;
- error and exception categories;
- labor, software, and oversight cost;
- service-level performance;
- customer or supplier escalations; and
- risk events, outages, and manual interventions.
Define how the baseline will be adjusted when product mix, transaction volume, data quality, staffing, or business rules change. Without that discipline, “savings” can become a debate about assumptions rather than a measured improvement.
This is core operations design: establish what work enters the process, how success is measured, who owns exceptions, and which system is authoritative.
Put acceptance criteria outside the model
Do not let the model decide whether its own output is correct. Use deterministic validation wherever the business rule can be expressed clearly.
For a quote, validate customer identity, contract price, inventory, lead time, product compatibility, freight rules, tax treatment, credit status, and approval thresholds against authoritative systems. For product content, validate required fields, units, identifiers, restricted claims, brand rules, and channel specifications. For production planning, validate capacity, material, tooling, maintenance, labor, safety, and release status.
Specify tolerances, required evidence, and fail-closed behavior. Missing or contradictory data should create an owned exception, not a confident guess.
Use a commercial structure that matches the work
Many AI-enabled services will need a blended model rather than one universal price:
- Discovery and implementation: fixed scope with defined deliverables, environments, integrations, security controls, testing, training, and acceptance.
- Managed service: a base fee for availability, monitoring, maintenance, support, governance, and capacity.
- Volume or outcome bands: pricing tied to accepted units, service levels, or validated process outcomes.
- Exception pricing: defined rates for out-of-scope cases, degraded source data, unusual integrations, or human specialist work.
- Change control: explicit treatment of new products, workflows, rules, models, data sources, and regulatory requirements.
- Shared savings: used only when the baseline, cost allocation, attribution method, measurement period, and audit rights are agreed in advance.
Avoid incentives that reward the provider for suppressing necessary exceptions, narrowing service quality, generating more activity, or shifting work back to employees. The contract should reward accepted work and durable improvement, not invisible cleanup.
Controls belong in the contract and the workflow
Least-privilege access
Give the provider and its automation only the systems, fields, records, environments, and actions required for the approved service. Separate read, draft, update, send, approve, and execute permissions. Review access when scope changes and at contract renewal.
Human approval gates
Require named approval for financial commitments, customer promises, supplier selection, product substitutions, safety decisions, regulated records, public claims, and changes to production systems. The approval control should record what was reviewed, by whom, and against which criteria.
Auditability
Preserve the request, relevant source data, model and version, instructions, tool calls, validation results, exceptions, approvals, final output, affected records, and outcome. Contractual audit rights should cover the evidence needed to reproduce billing and investigate failures without demanding unrelated vendor intellectual property.
Exception ownership
Define which exceptions the provider resolves, which remain with the customer, service targets for each class, escalation paths, and the evidence required for closure. Track exception volume and age; otherwise apparent automation gains may simply become a growing manual queue.
Vendor and model risk
A vendor and model risk review should cover subcontractors, model providers, data use, retention, geographic processing, security, model changes, service dependencies, intellectual-property terms, incident notice, audit support, portability, and termination assistance.
Monitoring and unit economics
Monitor acceptance, cycle time, error rate, exception rate, human-review time, rework, cost per accepted unit, provider availability, model changes, and downstream complaints. Measure the entire workflow, not just inference cost or task duration.
Incident response, rollback, and manual fallback
Define stop conditions and who can invoke them. Maintain a known-good configuration, reversible releases, data-correction procedures, customer and supplier notification criteria, and a tested manual path for priority work. Connect those steps to the organization’s AI incident-response plan.
What buyers should ask now
- Which business unit does the price buy: an hour, a transaction, an accepted deliverable, an availability level, or a measured result?
- How is acceptance determined, and which checks are independent of the model?
- What is excluded, and who owns each exception?
- Which model, data, and workflow changes require notice, testing, or approval?
- How are rework, human review, outages, and manual fallback included in total cost?
- Can the buyer reproduce invoices and service results from the audit record?
- What happens to data, integrations, prompts, configurations, and operating knowledge at exit?
The management question
AI can make service delivery faster and can support better commercial models. But speed does not remove the need to define value. It makes that definition more important.
Before buying an AI-enabled service, ask: What measurable unit are we paying for, how will we prove it was accepted, and who owns the exceptions when automation cannot safely finish the work?
If those answers are explicit, the business can adopt AI constructively while giving both buyer and provider a fair, auditable basis for pricing and performance. If they are vague, the contract may preserve the language of transformation while moving the argument from billed hours to unverified outcomes.
