A practical decision guide
Software pilot checklist
Find out whether the software works for your team before committing to a rollout. Give every option the same tasks, record what happened and resolve essential gaps.
1. Define the decision the pilot must support
Write a short decision statement: “Can this plan support our request-to-approval workflow with the roles we use today?” Name the person who will approve the outcome, the people doing the work and the date by which you need an answer.
Keep a proof of concept and a pilot distinct in your plan. A proof of concept can settle a narrow technical question, such as whether a connector handles one record type. A pilot should also show whether people can complete the workflow and recover when something goes wrong.
Choose a small set of essential tasks and agree what counts as success before opening the trial. A successful sales demonstration is a lead to investigate; record your own result on the plan you would actually buy.
Define your software requirements2. Turn requirements into acceptance tests
Use an expected result that a colleague can judge without guessing your intent. Include an ordinary case and an awkward case. The table is a starting point; change the tasks to match the work your team needs to do.
| Test | Sample and action | Acceptance evidence |
|---|---|---|
| Daily workflow | Create a request, assign it and complete its approval. | The right person can act; status and ownership survive each step. |
| Permissions | Try the task as a member, guest and administrator. | Each role sees and changes only what your policy requires. |
| Integration | Send a record, retry it and change a mapped field. | Expected values arrive; duplicate handling and errors are understood. |
| Export | Export records with an attachment and a relationship. | Open the export elsewhere and list anything missing. |
| Recovery | Make a safe, deliberate mistake in test data. | Record how to identify it, correct it and confirm the correction. |
3. Keep the sample and conditions comparable
Prepare a non-sensitive sample with the record types, roles and exceptions that matter. Keep an untouched copy so you can repeat the exercise in the second option. Write down the plan, deployment, region, browser or device where they affect the result.
Let the intended users attempt the task. Record any coaching, vendor intervention or manual workaround. A task completed with help is useful evidence, but it is not the same observation as someone completing it independently.
Separate setup effort from the task itself. A long initial import and a difficult daily workflow create different costs. If you time a task, record the conditions and avoid presenting a small pilot as a general productivity benchmark.
4. Record outcomes without hiding unknowns
For each option, mark the requirement Meets, Partly meets, Does not meet or Unresolved. Keep a short note with the source or test, exact plan and observation date. Link to the original documentation when it establishes a fact; keep your interpretation separately.
An unanswered question is unresolved, not a failed test. Give it an owner and a concrete next action, such as requesting a sample export or repeating a task on the proposed plan. A trial restriction may leave a question open even when the paid product could meet the requirement.
Use the scorecard to compare weighted preferences on the criteria answered for both options. Check its shared evidence coverage as well as the score. A high number based on a small shared subset is not a complete evaluation.
Fill in the software evaluation matrix5. Make a go, revisit or stop decision
Review the must-haves first. Any failed or unresolved essential test needs an explicit resolution before you treat the pilot as accepted. An attractive average score cannot make an essential workflow work.
For a go decision, record accepted trade-offs, the exact offer, a rollout owner and a rollback condition. For revisit, write down the missing evidence and when it will be checked. For stop, preserve the reason so a future team does not repeat the same discovery.
Compare costs using the same seats and period, including implementation and overlap with the existing tool. Then use a migration rehearsal to test the handover before moving the live workflow.
Plan the software migrationYour decision checklist
Checkmarks stay on this page only. Use your browser’s print command to keep a copy.
Common questions
How long should a software pilot take?
Plan around the tasks and evidence needed for the decision. Allow time for setup, use by the team and follow-up questions. A trial expiry is a deadline to manage, not proof that the evaluation is complete.
What if the trial does not include a required feature?
Keep the test unresolved. Ask for a demonstration on the proposed plan, a temporary entitlement or written documentation, and distinguish those forms of evidence from your own hands-on test.
Should a pilot choose the product with the highest score?
Review essential requirements first. Then use the shared scores, evidence coverage, costs and accepted trade-offs to support a decision. The scorecard does not choose a winner.