Set one comparison scenario
Before comparing prices, define the work, people and locations included. List the essential tasks the tool must support and the limits that would matter. Different assumptions can make two prices look comparable when they are not.
Use the same scenario for every option. An illustrative team comparing a tool for one location with an offer covering several locations should separate the quantities before calculating a total. Keep additional modules and optional services visible instead of assuming they are included.
Read the actual billing terms
Record the price, currency, billing interval and any required commitment from the vendor’s current terms. A monthly equivalent and a monthly charge are different things. Include taxes, usage charges or other amounts only when they apply and you have a clear basis for estimating them.
Check trial requirements, the point at which payment begins and how cancellation works. Do not rely on a short promotional label when deciding what the team is committing to. Keep a dated link or record of the offer you actually reviewed.
Count the work of getting started
List the setup decisions, data preparation, import checks and colleague training needed. Estimate effort with the people who would do the work. Mark uncertain amounts as estimates instead of presenting a precise total that the evidence cannot support.
Test a small sample of the migration with fictional or appropriately controlled records. Check which fields, attachments and histories transfer. A tool may fit the ongoing workflow while requiring more transition work than the initial demonstration suggests.
Use a whole-commitment worksheet
You can compare these headings without pretending every item has a monetary value. Some are constraints or responsibilities that the team needs to understand.
Scroll the table sideways to see all columns.
| Area | What to record |
|---|---|
| Subscription | Price, interval, scope and limits |
| Setup and migration | Tasks, owners, estimates and verification |
| Learning | Who needs training and how they will practise |
| Ongoing work | Manual steps and administration that remain |
| Leaving | Exports, attachments, timing and responsibilities |
Test the daily work before valuing the saving
Run the same realistic workflow in each option. Include corrections, an unfinished task and a handover to another colleague. Record which steps remain manual and where the tool provides the information a person needs.
Avoid assigning an impressive time-saving number without measuring the relevant work. An observed trial result should describe the task, conditions and uncertainty. A faster demonstration by someone familiar with the tool does not establish the same saving for every team.
Write the decision with its unknowns
Keep a short record of the scope compared, the terms checked, the workflow results and any unresolved questions. A useful comparison may conclude that one option needs another test, or that the current process remains suitable for the present scope.
For a reusable trial outline, see evaluating software with a workflow. The purpose is a decision your colleagues can explain, with the full commitment visible and the evidence strong enough for the step you intend to take.
Published by Naltyx. Examples are illustrative; any Naltyx product mentioned is our own. How we write.
Let’s talk