Segments covered: subscription software sold to businesses, horizontal or vertical, with its own support, implementation, and engineering teams. Linked workflows: support replies, customer onboarding, incident triage. Linked roles: support leaders, engineering leaders, sales operations leaders, finance leaders.
A software company can use AI to build its product, to run its business, or to supply a capability customers buy. These are three different investments. They need separate owners, measurements, and economic cases even when they share a model provider. This guide maps where AI could change the economics of a B2B software company, what constrains it, and what is actually measured. The workflow and role chapters hold the worked cases and arithmetic; this chapter links to them rather than repeating them.
Three kinds of material appear below and are kept apart. Survey and study results are cited inline with their population, period, and limits. Recommendations are editorial proposals, labeled as such. The company, prices, and usage figures in the economics and sequencing sections are invented teaching examples, not measurements from any firm.
How the business makes money
The model this guide covers sells recurring access to software on contracts, such as annual or multi-year terms, priced per seat, per account, per unit of usage, or by some combination. Revenue can arrive in advance or on a schedule. Where the cost of acquiring a customer is paid up front, the return depends on the customer staying and, ideally, buying more.
Four quantities decide whether that model works:
| Quantity | What it captures | Where AI could move it |
|---|---|---|
| Cost to deliver the service | Hosting, support, implementation, third-party software, and anything else consumed each period to serve customers | Support and onboarding effort could fall; inference inside the product could rise |
| Retention and expansion | Whether customers renew and buy more | Faster onboarding or better support might help; an unreliable AI feature might hurt |
| Cost of acquiring customers | Sales and marketing spend relative to new recurring revenue | Proposal and sales-operations work; not a canonical workflow in this guide yet |
| Product investment | Engineering and product spend relative to revenue | Developer tooling, incident response, and the cost of building and evaluating AI features |
The first row is described here as an economic cost to serve, not an accounting line. Which costs a company presents in cost of revenue, and whether any are capitalized, depends on its reporting framework, adopted standards, transaction facts, and policy. That classification is a question for a qualified accounting reviewer, and the economics chapter explains why a COGS or OPEX label cannot be inferred from the use of AI.
This guide does not cover consumer software, IT outsourcing and systems integration (see the professional services guide for services firms), or companies whose product is a foundation model. Sector-level financial statistics for software publishers are not cited in this guide; they are listed below as outstanding research.
Two lenses: running the company and selling the capability
AI in the company's own operations is judged like any internal investment: effort released, quality preserved, continuing work funded, and a stated way for capacity to become cash or better service. The canonical chapters are the support, onboarding, and incident workflows, and the engineering leader's guide for developer tooling.
AI features sold to customers change the product's economics. Each completed task can carry an inference, retrieval, and storage cost, and the heaviest users may consume far more than the typical account. The feature also needs its own evaluation, failure handling, and pricing decision. No workflow chapter in this guide covers product features yet, so this section stays at the level of decisions and questions. Do not run an internal productivity pilot and a customer-facing feature launch as one experiment; they have different owners, risks, and success measures.
Where AI could touch the value chain
| Process | Capability | Canonical chapter | Benefit mechanism | Benefit location | Do first |
|---|---|---|---|---|---|
| Answering documented product questions | Retrieve, generate | Support replies | Added capacity; possibly avoided contractor spend | Cost to deliver | Assign article owners; fix contradictory documentation |
| Guiding customers through setup | Retrieve, generate | Onboarding | Added specialist capacity; activation is a separate hypothesis | Cost to deliver; retention (unmeasured) | Structured checklists by edition; reliable entitlement data |
| Assembling context during incidents | Retrieve, summarize | Incident triage | Responder capacity; restoration effects unproven | Product investment (engineering spend); risk | Deploy annotations, alert grouping, runbook links |
| Writing and reviewing code | Generate | Engineering leaders | Developer capacity; delivery stability can move either way | Product investment | Measure on your own work before standardizing |
| Recording sales calls and CRM updates | Extract, generate | Sales operations leaders (no workflow chapter yet) | Rep capacity; data quality | Cost of acquisition | Field definitions and ownership |
| Invoices, contracts, collections | Extract | Finance leaders, document extraction | Finance capacity; fewer entry errors | Operating expense | Approval rules and segregation of duties |
| AI features inside the product | Varies | None yet | New value to customers; new variable cost | Revenue and cost to deliver | Cost per completed task and an evaluation set |
| Keeping documentation current | Retrieve, compare | Not covered | Fewer contradictions feeding every retrieval system | Indirect | Ownership and review dates before any automation |
Two rows deserve emphasis. Documentation ownership underlies the support, onboarding, and product rows: a retrieval system cannot answer reliably from articles that contradict each other. And the product row is the only one where AI adds a cost that scales with customer usage; the others release internal capacity.
Constraints that shape every project
Customer data and tenant isolation. A multi-tenant product holds many customers' data in shared infrastructure. Any assistant that reads tickets, logs, or account records must enforce the same boundaries the product does, before retrieval rather than after generation. The support and retrieval chapters describe permission-filtered retrieval; the proposed test is whether another customer's content can reach the model context at all.
Contracts with customers. Enterprise agreements may restrict which subprocessors handle customer data, where it is stored, how long it is retained, and whether it may be used to improve models. These are contract questions for the company's legal team, not engineering defaults. Before sending customer content to a model provider, confirm what existing agreements permit. This guide states no legal requirement.
Liability for customer-facing output. An internal draft waits for a reviewer. A product feature may act or answer in front of the customer, with a service commitment behind it. Specify the acceptable completed outcome, the failure message, and the fallback before choosing a model, and decide who is accountable when the feature is wrong.
Untrusted input. Tickets, logs, uploaded files, and customer documents can contain text that looks like instructions, the prompt-injection risk. The proposed control is architectural: read-only access for assistants, and no tool permission that an instruction in customer content could misuse.
Model and provider change. Model versions change behavior, cost, and output format. Maintain representative evaluation cases and compare each change against the previously accepted configuration, as the model selection chapter describes. A cheaper model that increases correction work, or a more capable one that breaks downstream parsing, is a regression.
Security review by customers. Enterprise buyers may ask detailed questions about how AI features handle their data. Treat the answers as product requirements to design and document, not as marketing copy.
The sector's economics lens
Internal applications: capacity first, cash only with a mechanism
Released effort in support, onboarding, or incident response is capacity. It becomes cash only if a planned expense no longer occurs, such as contractor hours or an unfilled requisition, or if the team absorbs growth it would otherwise have hired for. The workflow chapters show the arithmetic and its sensitivity: in the illustrative support case, a 70% realization assumption turns $5,400 of monthly capacity value into $1,780 of net cash; the illustrative onboarding case is negative on cash at 50% realization; and the incident triage case is a capacity or quality investment with no clear cash path. The finance leaders guide shows how to review such proposals side by side.
Do not count the same improvement twice. If faster onboarding is claimed to improve retention, that revenue effect is a hypothesis to test separately; it cannot be added to the capacity value of the same specialist hours. If support answers improve, fewer repeat contacts show up inside the support effort measure; they are not a second saving.
Product features: contribution per account, not per average user
A capability sold to customers changes the cost to serve with usage. The following fictional example shows why the average user can hide the economics. All figures are invented for illustration.
Assume a subscription of $2,000 per account per month, an existing cost to serve of $400 per account per month, and an AI feature whose inference, retrieval, and retry cost averages $0.02 per completed task. Before the feature, economic contribution is ($2,000 − $400) ÷ $2,000 = 80%.
| Account type | Tasks per month | AI cost | Total cost to serve | Contribution |
|---|---|---|---|---|
| Typical account | 5,000 | $100 | $500 | $1,500 (75.0%) |
| Heavy account | 60,000 | $1,200 | $1,600 | $400 (20.0%) |
Across 100 accounts, 90 typical and 10 heavy, revenue is $200,000, cost to serve is 90 × $500 + 10 × $1,600 = $61,000, and blended contribution is 69.5%. The ten heavy accounts account for $16,000 of the $61,000.
Now suppose the price includes an allowance of 20,000 tasks, with additional tasks charged at $0.04. A heavy account pays (60,000 − 20,000) × $0.04 = $1,600 more, so its revenue is $3,600 and its contribution $2,000, or 55.6%. Portfolio revenue rises to $216,000 against the same $61,000 cost, and blended contribution to 71.8%.
Contribution shrinks with usage unless price follows it
- Flat subscription
- Allowance and overage
- Cost to serve
Show the data
| Account | Tasks | Cost to serve | Flat revenue | Contribution | Revenue with allowance | Contribution with allowance |
|---|---|---|---|---|---|---|
| Typical | 5,000 | $500 | $2,000 | 75.0% | $2,000 | 75.0% |
| Heavy | 60,000 | $1,600 | $2,000 | 20.0% | $3,600 | 55.6% |
The example makes three editorial points. First, measure cost per completed task including retries, not per model call. Second, look at the distribution of usage by account before setting a price; an unlimited allowance transfers the heavy tail's cost to the company. Third, a pricing change is a customer decision with retention consequences, and willingness to pay needs customer evidence. A capability does not create it automatically.
Contribution here is an economic measure for a pricing decision. It is not a statement of how the company will present these costs in its financial statements.
Classification is a separate question
For your finance lead
For AI tools the company buys or builds for its own use, capitalization and presentation depend on the reporting framework, the contract, and the company's adoption status for recent standards updates, not on the use of AI. The economics chapter cites the relevant FASB and IFRS sources, and the finance leaders guide explains how to keep classification apart from the investment case. This guide gives no accounting opinion.
What is measured about adoption and outcomes
For your analyst
Adoption, deployment maturity, and outcomes are different questions. The sources below answer the first and parts of the third, for defined populations.
Business use of AI, Information sector. The Census Bureau's Business Trends and Outlook Survey (BTOS) collects data every two weeks and is representative of US employer businesses, excluding farms. Census Bureau, BTOS In November 2025 the Bureau revised its core question from AI use "in producing goods or services" to AI use "in any business function." Census Bureau, AI Use at U.S. Businesses, May 26, 2026 In the cycle collected September 21 to October 4, 2026 (reference period September 7–20), 50.2% of Information-sector businesses (standard error 1.43 points) answered yes to "In the last two weeks, did this business use Artificial Intelligence (AI) in any of its business functions?", against 23.8% of businesses nationally; 52.0% expected to use AI in the next six months. The two previous cycles' Information-sector estimates were 43.5% and 49.0%. Each reading carries sampling error (the standard error above is 1.43 points), so read the level rather than one cycle's change. BTOS sector estimates, cycle 202620
The Information sector (NAICS 51) is broader than B2B software: it includes publishing, broadcasting, telecommunications, and data processing alongside software publishers. The estimates are shares of firms, not of employment or revenue, and "use" is self-reported and undefined in depth. Estimates under the earlier question wording are not comparable with these and should not be combined with them into a trend.
Share of businesses using AI, by sector
- This guide’s sector
- Other sectors in the guide
- All businesses
Show the data
| Group | Estimate | Standard error | 90% interval |
|---|---|---|---|
| Information | 50.2% | 1.43 pts | 47.8–52.6% |
| Finance and insurance | 40.1% | 1.86 pts | 37.0–43.2% |
| Professional, scientific, and technical services | 42.7% | 1.01 pts | 41.0–44.4% |
| Health care and social assistance | 24.8% | 1.01 pts | 23.1–26.5% |
| Wholesale trade | 21.6% | 1.46 pts | 19.2–24.0% |
| All employer businesses | 23.8% | 0.41 pts | 23.1–24.5% |
Where firms use it. The 2025–2026 BTOS AI supplement asked about AI use by business function over the preceding six months; the Bureau's working paper describes its reference period as November 2025 to January 2026. Census working paper CES-WP-26-25 For all Information-sector businesses, the supplement table reports use in sales and marketing by 25.5%, research and development by 25.4%, strategy and business development by 24.2%, information technology by 23.5%, and customer service by 12.2%. BTOS AI supplement table, 2026
What it replaced. Among Information-sector businesses that used AI, the same table reports that 59.5% used it to supplement or enhance a task performed by an employee and 16.8% to perform a task previously done by an employee; 91.7% reported no change in total employment from AI use in the last six months, 3.8% a decrease, and 4.5% an increase. These are firms' own reports for a six-month window, not measured productivity or labor effects, and they describe the whole Information sector rather than software companies.
Outcomes in support work. The November 2024 version of Generative AI at Work studies 5,172 support agents at one software company and reports a 15% average increase in issues resolved per hour after access to AI suggestions, with results varying by worker experience and skill. Brynjolfsson, Li, and Raymond, version 2 The larger deployment followed a small randomized pilot, and the authors analyze staggered access using difference-in-differences methods; access in the larger rollout expanded at different times, so the study as a whole is not a single randomized trial. Full-text methods The abstract reports that less experienced and lower-skilled workers improved in speed and quality while the most experienced saw small speed gains and small quality declines. Some methods details, including how the productivity outcome was constructed, are not fully documented in the public versions. Use the study to decide what to measure, not as a default savings rate.
Outcomes in engineering work. The engineering leaders guide sets out a small randomized trial with experienced open-source developers and a large observational survey side by side, with their populations and designs. They measure different things and do not establish the effect of AI tools on any particular team.
What is not measured. No attributable source in this guide measures the economics of AI features in B2B software products: cost per task, margin effects, pricing outcomes, or retention effects. No operator has been interviewed and no company's deployment observed for this chapter.
Who is involved
| Role | Owns | Guide |
|---|---|---|
| Support leader | Service promise, resolution quality, knowledge upkeep funding | Support leaders |
| Engineering leader | Shared platform, evaluation gates, access control, developer tooling | Engineering leaders |
| Sales operations leader | CRM definitions, pipeline data that finance relies on | Sales operations leaders |
| Finance leader | Business-case review, realization mechanisms, controls | Finance leaders |
| Product leader | Customer promise and pricing of AI features | Not yet covered |
| Customer success or implementation lead | Onboarding milestones and handoffs | Covered in the onboarding workflow; no role guide yet |
| Security and legal | Data-processing terms, subprocessors, customer security reviews | Not yet covered |
Proposed practice: every AI initiative names a business owner alongside engineering. Support owns resolution quality, product owns the customer promise, engineering owns reliability and access control, and finance reviews the realization mechanism. Knowledge maintenance and evaluation are recurring responsibilities with budget.
Expertise specific to this industry. A general AI builder can build an internal assistant but lacks the product and commercial knowledge an AI feature needs: cost per completed task and usage by account before setting a price; the customer promise, failure message, and fallback behind a feature; the subprocessor, storage, retention, and model-improvement terms in enterprise agreements; and answers to customers' security reviews. This guide places that expertise in-house, with the product leader for the customer promise and pricing of AI features and with security and legal for data-processing terms, alongside engineering for tenant isolation. See Staffing an AI pilot and Choosing and working with an AI partner.
Sequencing: a first move and what follows
The following is a fictional planning example. Wendleby Software is an invented company selling a scheduling and compliance application to mid-sized healthcare-staffing agencies, with about 1,200 customer accounts, a 30-person support team handling about 5,000 requests a month, and an implementation team onboarding about 100 new accounts a month.
First: support drafts on documented categories. Support has the volume, a named knowledge owner, and a reversible starting point: drafts that agents approve. Wendleby measures the baseline first, as the support leaders guide describes, and starts with how-to questions for the current product version. Billing disputes and account-access requests stay out.
What must be true first. Help articles have owners and review dates; the ticketing system can tell the assistant which product version and role the customer has; engineering can enforce that retrieval returns only the requesting account's data.
If it works: reuse the platform. The permission-filtered retrieval and evaluation harness built for support become the base for onboarding guidance on one product edition, following the onboarding chapter. The engineering leaders guide explains why a shared platform comes before one-off builds.
Only then: a product feature. A customer-facing feature is scoped after the team can measure cost per completed task and has an evaluation set for the feature's task. The pricing discussion starts from the distribution of expected usage by account, as in the economics example above.
The counterexample: a smaller sister product should wait. Wendleby also sells a niche reporting add-on with about 400 support requests a month, documentation last reviewed two releases ago, and no article owner. A draft assistant there would retrieve contradictory instructions, and the volume cannot fund the knowledge upkeep. The right move is to assign an owner, retire outdated articles, and build response templates for the ten most frequent questions. Revisit when the documentation is maintained and volume justifies the continuing cost.
Questions for operators, investors, and vendors
For operators:
- Which costs to serve would change, and is any of the change a planned expense that stops, or only capacity?
- Who owns the documentation each AI system will retrieve from, and when was it last reviewed?
- Can the assistant receive the customer's product version, role, and entitlements from a system of record?
- For product features, what is the cost per completed task, including retries, and how is usage distributed across accounts?
For investors:
- Does the company separate AI in its own operations from AI features it sells, with separate owners and economics?
- What happens to contribution per account for the heaviest users of AI features, and how is that priced?
- Are claimed efficiency gains supported by baselines, including review and rework, or by vendor-reported rates?
- How are model version changes evaluated before release?
For vendors:
- How does your system enforce tenant and user permissions before content reaches the model?
- What do you retain, for how long, and is any customer content used to train models?
- Can we export evaluation results, configurations, and logs to reproduce a decision?
- What happens to our workflow when your service is unavailable?
When to wait
Wait when documentation is unowned or contradictory; when customer data boundaries cannot be enforced before retrieval; when volume in the candidate workflow is too low to fund continuing upkeep; when support demand is driven by a product defect that engineering can fix; or when existing contracts do not permit sending customer content to the intended provider. The simpler investments, such as documentation ownership, templates, structured onboarding checklists, deploy annotations, and fixing the defect behind repeated tickets, are worth making whether or not an AI project follows.
Evidence still needed and related reading
Outstanding research: sector-level financial statistics for software publishers from the Census Bureau's current annual business surveys; any attributable measurement of AI feature economics in B2B software; operator accounts from support, implementation, and engineering leaders at software companies; and BTOS estimates specific to software publishers under the revised question wording, if the Bureau publishes them at that level.
Continue with support replies, onboarding, incident triage, engineering leaders, finance leaders, and the economics chapter. Choosing where to begin is covered in choosing a first AI workflow.
Hiring in New York: open roles at NYC AI companies selling enterprise software, read daily from the companies' own job boards. These companies sell AI into the industry; they show which skills vendors are hiring for, not what firms in the industry are hiring.