Skip to main content
DoneThat

AI Adoption GuideITSelect

Total cost of ownership calculator

Agentic system populates TCO models by pulling list prices, support costs, and migration estimates from vendor APIs and historical data.

IT processPlanSelectDeployProvisionSupportUpgradeReplaceRetire

By Don, DoneThat’s AI coach · updated

What the agent does with your TCO model

A total cost of ownership calculator in vendor selection is only useful when every number has a traceable source. The agent reads your existing TCO workbook or model structure, connects to vendor price feeds and your organization's historical spend data, and fills in rows it can support with citations. List price comes from a vendor API or published rate card. Support and maintenance rows pull from contract history or vendor support schedules. Migration and implementation estimates draw from prior project records or vendor sizing tools where those exist.

What the agent does not do is decide the winner, assume a discount you have not negotiated, or insert a savings percentage because the model looks incomplete without one. Sourcing still owns the decision. The populated model is evidence for comparison, not an award recommendation.

If you are building a shortlist in parallel, run this populate pass before you score vendors. A vendor shortlist scoring engine needs comparable numbers, not rows where one vendor shows a fully sourced TCO and another shows placeholder guesses.

Load list prices, support costs, and migration history

Start by defining which vendors and products belong in this evaluation. For enterprise IT platforms, that often means classes of tools represented by vendors such as ServiceNow, Apptio, SAP Ariba, and Coupa. You are not ranking those vendors here. You are loading the price and cost signals each one exposes so your model can compare like categories: subscription or license, support tier, professional services, and migration effort.

List prices. Point the agent at vendor APIs, partner portals, or exported rate cards your team already uses in sourcing. The agent maps SKUs, user tiers, and module bundles to rows in your TCO template. When a vendor publishes list price only for certain modules, the agent fills those rows and leaves dependent rows empty until you add assumptions sourcing approves.

Support and ongoing costs. Pull renewal history from your FinOps warehouse, procurement records, or ITSM cost allocations. Support rows should cite the contract line or the vendor support schedule the agent read, not a rounded average from memory. If your organization has never bought support for a comparable product, the support row stays blank.

Migration and implementation estimates. Historical data matters here. Prior cutover projects, data migration scope, and integration counts give the agent something defensible to cite. Vendor sizing calculators or statement-of-work templates can supply ranges when history is thin. The agent records which source drove each estimate. It does not collapse a range into a single number unless your model template requires a point estimate and sourcing has signed off on the midpoint rule.

Connect these feeds once per evaluation cycle. Refresh when list prices change, when a vendor updates a module bundle, or when your team loads a new historical extract from a completed migration.

How each line gets a source (or stays blank)

Your TCO template should separate cost categories clearly: license or subscription, support, implementation, migration, training, internal labor, and ongoing operations. The agent walks row by row and attaches a source field the way a good analyst would leave a cell comment.

A license row cites list price from the vendor feed: product name, tier, unit count, effective date. A support row cites either a percentage from the vendor support schedule or an actual renewal amount from a prior contract. A migration row cites a historical project record, a vendor migration estimator output, or an internal benchmark document your team uploaded.

When no source exists, the cell stays empty. That is correct behavior. An empty migration line for a net-new platform is more honest than a invented five-figure estimate so the spreadsheet balances. Sourcing fills blanks with assumptions they can defend in committee, or leaves the vendor out of cost comparison until data arrives.

Illustrative example (no award, no savings claim). Suppose you are comparing two service management platforms and one spend analytics suite. The agent fills subscription rows for all three from vendor list price APIs. Support for the incumbent platform cites last year's renewal invoice. Support for a challenger platform cites the vendor's published premium support rate applied to the quoted subscription. Migration for the incumbent stays empty because you are renewing in place. Migration for the challenger cites a 2023 internal project that moved 8,000 tickets and 40 integrations, with the agent noting scope differences in the source note. The spend analytics row for implementation cites a vendor SOW template range; sourcing enters the point estimate they intend to negotiate. No row shows "estimated savings." The total columns are sums of sourced and sourced-plus-assumed lines, clearly labeled.

Use a budget scenario modeler when you need to stress-test those assumptions across fiscal years. The TCO calculator supplies sourced baselines; scenario modeling applies sourcing-owned ramps, headcount, and renewal timing.

Run the populate pass before committee review

Sequence matters. Populate from APIs and history first. Let sourcing review blanks and add assumptions second. Export a version where every filled cell shows its source type: list price, support schedule, contract actual, migration history, or vendor estimator. Committee packs should make it obvious which numbers are vendor-published, which are your organization's actuals, and which are still open.

Tie contract language back into cost risk without duplicating legal review. When renewal caps, audit rights, or price hold language affects how support rows will behave in year three, flag those rows for a contract risk extraction pass. The TCO model shows what you pay; contract extraction shows what could change what you pay.

For refresh or replacement decisions, pair populated TCO with timing analysis. A replacement timing optimizer uses the same cost categories but focuses on when switching costs cross renewal economics. The calculator answers "what does each option cost if we scope it this way"; timing work answers "when does acting matter."

Failure modes sourcing teams still see

A line with no price cite. The most common failure is a subscription row filled from a stale PDF rate card while the vendor API already moved to a new bundle name. Fix by requiring API or export date on every list price cite and re-running populate when the vendor changes packaging. If the agent cannot match a SKU to your template row, it should leave the row empty rather than map to a close-sounding product.

Treating the model as awarded. A fully populated spreadsheet is not a decision. Finance and IT leadership sometimes read green totals as approval. Keep award language out of the model. Label the document as a comparison workbook. Scoring and governance live in separate steps. Population is data preparation.

Inventing a savings percent. Do not add a row that compares incumbent total to challenger total and expresses the difference as "savings." Negotiated discount, termination fees, and dual-run periods make that number misleading in selection stage. If leadership wants a savings narrative, that belongs after commercial terms exist, not in a TCO template used to shortlist vendors.

Uneven vendor coverage. One vendor's API exposes module-level list price; another exposes only a quote request form. The model will look more complete for the API-rich vendor. Sourcing must notice asymmetry and either request manual quotes for blank rows or exclude those rows from side-by-side totals until parity exists.

Double-counting migration and support. Implementation rows sometimes include first-year support; license rows sometimes include a baseline success package. The agent should respect row definitions in your template. When vendor documents bundle costs, split or tag them so support and implementation do not cite the same dollars twice.

What sourcing should do after populate

Review every blank row and decide whether to request a quote, use a defended assumption, or remove that cost category from this comparison. Challenge any cite that does not match the SKU under evaluation. Re-run populate when vendors refresh list price or when your team uploads new migration actuals.

Hand the reviewed workbook to scoring, scenario modeling, and executive readouts as a single sourced view of cost. The outcome you want is traceability: any stakeholder can click from a TCO line to list price, support row, or migration estimate source. Empty stays empty until sourcing closes the gap. The decision stays with sourcing, with better numbers on the table.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first