A PSA budget is credible only when it includes more than the subscription. The economic decision combines licenses, implementation, data migration, integrations, internal project time and the cost of operating the old stack during transition. This guide gives consulting leaders a repeatable way to build that budget without relying on a vendor's headline price.
Start with the operating problem, not the license
Write down the processes the new system must improve: opportunity handoff, staffing, time capture, project control, billing and forecasting. For each process, estimate today's manual effort, error risk and delay. A low license price has little value if the firm must keep separate tools for CRM, resource planning or invoicing.
Define the population that will actually use the product. Some vendors charge every employee, others charge managers or active users, and others use modules or usage. Model expected headcount and role changes for three years so that a pricing model that looks attractive today does not become a penalty during growth.
The six components of total cost
Use six budget lines: recurring subscription, initial configuration, data migration, integrations, internal change effort and ongoing administration. Request each line separately in the commercial proposal. If a supplier bundles them, ask for assumptions, included hours and the rate applied to extra work.
Internal effort is real even when no invoice is issued. Include the time of the executive sponsor, process owners, data owners, pilot users and finance reviewers. Also include parallel running, because many firms keep spreadsheets or a legacy system for one or two closing cycles while they validate outputs.
Build a three-year TCO model
The basic formula is: three-year TCO = recurring fees + one-off services + internal effort + transition cost + expected change requests. Apply the same scope and headcount scenario to every finalist. Show the base case, a growth case and a downside case in which implementation takes longer.
Do not mix recoverable taxes with economic cost, and do not hide annual price increases. Record currency, payment timing, indexation, minimum commitment, renewal notice and exit fees. A simple table with one column per year is usually more useful than a complicated ROI spreadsheet.
Compare value with a measurable baseline
Link the budget to outcomes the firm can observe: days from month-end to invoice, late timesheets, manual reconciliation hours, unbilled work, forecast preparation time and percentage of projects with a current margin view. Capture the baseline before implementation and assign an owner to each measure.
Keep benefits conservative. Count time savings only where the work can actually disappear or be redirected. Treat improvements in utilization, win rate or margin as scenarios rather than guaranteed vendor benefits. The companion PSA guide explains the functional scope behind those outcomes.
Questions to put in every vendor quote
Ask what is included in onboarding, how many data imports are covered, which integrations are standard, what support response is contracted and how data can be exported. Confirm whether sandboxes, API access, storage, AI usage, additional entities and historical records create extra charges.
Request a written definition of “live.” A configured tenant is not the same as an adopted operating system. A useful milestone requires agreed data quality, trained process owners, a completed billing rehearsal and a successful reporting reconciliation.
Make the decision auditable
Score cost separately from functional fit, implementation risk, security and adoption. Keep the evidence used for every score: proposal version, demo scenario, reference answer and contract clause. This prevents the cheapest headline from dominating a decision whose largest costs often appear after signature.
Before approval, let finance test the TCO, operations test workflows, IT test architecture and end users test the pilot. The final recommendation should state assumptions and conditions, not pretend that one number predicts the future. Then carry those assumptions into the implementation checklist.
Which pricing model penalizes growth
Per-employee pricing is easy to understand and predictable for the vendor, but it taxes growth in the delivery population even when the number of decisions does not rise in proportion. It suits stable firms where nearly everyone uses the system daily.
Per-manager or per-active-user pricing aligns spend with the people who decide, and it is usually more efficient in firms that grow their delivery bench. Its risk is the definition of an active user: ask in writing what counts as activation, how often it is measured and what happens to someone who logs in once a month.
Per-module pricing looks flexible and often hides the fact that the capability you actually need lives in the tier above. Consumption pricing, typical for AI features or storage, has the opposite problem: it is impossible to budget accurately in year one. Where it appears, insist on a contractual cap and alerts before you reach it.
The costs that arrive in year two
Year one attracts attention and budget. Year two exposes the decisions that were closed badly: process changes that require reconfiguration, integrations that break when the ERP updates, new reports nobody knows how to build, and an internal person who spends a few hours every week maintaining rates, roles and templates.
Budget that ongoing administration explicitly and name its owner. In firms of 30 to 100 consultants it usually equates to a steady fraction of a role rather than a one-off spike, and it is the difference between a system that ages well and one that drifts back to spreadsheets. Add the exit cost as well: a contract that does not guarantee a complete export in a reusable format turns a three-year decision into a ten-year one.