Questions to Ask When Implementing New Software
For the person rolling a new software tool out to a team or department. Twenty questions covering licensing and renewal terms, access control, data export, support commitments, and what the first week looks like for someone who has never seen the product.
The questions
Open any question for the note
What tool or habit is this replacing, and are we genuinely turning that off?
Why ask it
A tool that replaces nothing becomes another tab people forget to open, and you keep paying for the thing it was meant to retire. If the honest answer is that both will run, you are buying an addition and should price it that way.
Who inside the company asked for this, and who will administer it?
Why ask it
Software with an enthusiastic requester and no named administrator degrades fast: nobody removes leavers, nobody prunes unused fields, nobody owns the renewal. Ask whether administration is in someone's objectives or a favour they agreed to.
How is this licensed, and what happens to the price as we grow?
Why ask it
Per seat, per active user, per record, and per usage all behave very differently once the team doubles or a busy month arrives. Ask for the cost at your realistic size in two years, not the cost today.
What does the contract say about increases at renewal?
Why ask it
The first-year discount is the part they lead with; the renewal uplift is the part that decides your three-year cost. Look for a cap in writing, an auto-renewal notice window, and whether the discount applies to added seats mid-term.
Does it support single sign-on, and is that included in our tier?
Why ask it
Charging for single sign-on as an enterprise upgrade is common, and without it you inherit orphaned accounts every time someone leaves. Confirm the tier, and confirm that user provisioning and deprovisioning are covered too.
Who can see what, and how granular are the permissions?
Why ask it
Many products offer only admin and member, which means the intern can export everything or nobody can do anything. Test the permission model against your actual worst case, such as a contractor who needs one project and no salary data.
Where is our data stored, and can we get all of it out in a usable format?
Why ask it
Ask for a real export from a real account, not a description of one. Products that export only the current view, or only CSV without attachments and history, are much harder to leave than the sales conversation suggests.
What uptime do you commit to, and what actually happens when you miss it?
Why ask it
Most service credits are token amounts and require you to notice and claim them. The more useful part of the answer is their public status history and how they communicated during their last significant outage.
What is in your security documentation, and who on our side has to approve it?
Why ask it
Ask for their current audit report, penetration test summary, subprocessor list, and breach notification terms early, because the review is often the longest step in the whole rollout. Finding out in week five that legal needs six weeks is how launch dates slip.
What does support include: hours, channels, response times, and does that change by tier?
Why ask it
Business hours in another timezone means no help during your morning, and chatbot-first support means your admin becomes the real first line. Ask what a severity one ticket looks like and who is allowed to raise one.
How does this behave at our volume, and what happens at ten times that?
Why ask it
Products that feel instant with a demo dataset can stall on a hundred thousand records or a report spanning three years. Ask for a customer at your scale, and ask about record limits, API rate limits, and report timeouts specifically.
What has to be configured before the first real user logs in?
Why ask it
The list usually includes fields, workflows, templates, permission groups, and integrations, and it takes longer than anyone estimates. Getting it written down converts a vague launch date into a task list with an owner per item.
Are we launching to everyone at once, or one team first?
Why ask it
A first team gives you a small, forgiving group to find the configuration mistakes, plus people who can help the next wave. Launching to everybody simultaneously means every problem arrives at once, into a support function that has never seen the product.
What does the first week look like for someone who has never seen this?
Why ask it
Walk it literally: the invitation email, the first login, the first task they must complete, who they ask when it fails. Rollouts are usually lost in that first hour, not in month three.
Which of our existing tools does it connect to, and how deep does the connection go?
Why ask it
An integration can mean full two-way sync or a link that posts a notification, and the marketing page rarely distinguishes them. Ask which fields sync, in which direction, how often, and what happens when a record is edited on both sides.
What will we still be doing by hand after this is live?
Why ask it
Every tool leaves a residue of manual work, usually reporting, reconciliation, or copying data into a second system. Naming it now stops the rollout being judged as a failure for not solving something it was never going to solve.
What is on your roadmap that we are being asked to wait for?
Why ask it
If a decisive feature is coming next quarter, you are buying a promise, and roadmap dates slip routinely without malice. Ask for it in writing with a remedy, or plan on the product exactly as it exists today.
How often do you change the interface, and do we get any control over when?
Why ask it
Frequent unannounced redesigns mean retraining and a spike in support tickets you did not schedule. Ask about release notes, advance notice, and whether admins can preview or defer changes.
If we cancel, what happens to our data and how long do we have to retrieve it?
Why ask it
Retention after termination is often thirty days or less, and read-only access sometimes ends the moment the contract does. Settle the export window and format before signing, because after notice is served you are negotiating from a weak position.
Which customers have stopped using this, and do you know why?
Why ask it
Every vendor loses accounts, so a claim otherwise means they are new or not being straight with you. A specific answer, such as churn among very small teams or companies that needed a feature they chose not to build, tells you whether you resemble the people who left.
Rolling Out Software People Will Actually Use
Practical guidance for the conversation itself
During Evaluation
Run a Trial With Your Own Data and Your Own Worst Case
Demo environments are curated. Load a real subset of your records, then attempt the ugliest task you actually do: the exception case, the month-end report, the record with fifteen attachments. Products separate sharply at that point, and the difference is invisible in a scripted demonstration.
Start the Security and Legal Review Immediately
Procurement, privacy, and security review usually take longer than configuration. Request the audit report, subprocessor list, and data processing terms in the first week of evaluation so the review runs alongside your testing rather than after it.
Ask for a Reference at Your Size, Then Ask the Awkward Question
Vendors will offer references. Use the call to ask what the reference underestimated, how long onboarding really took, and what still annoys them. The useful information arrives in the second half of that conversation, after the polite summary.
Get Renewal Terms Settled Before the Discount
Negotiating the renewal cap, the notice period, and the price of additional seats is easy while they want the deal and nearly impossible eleven months later. Treat the multi-year cost as the number you are agreeing to, because that is the number you will pay.
A Workable Rollout Order
- 1Configure in a sandbox, including permissions and any integration, before inviting a single real user.
- 2Pick one team with real work and a tolerant manager, and run them live for two or three weeks.
- 3Collect every point of friction from that team, then fix the ones that made a routine task slower.
- 4Write the short guide from what that team actually got stuck on, not from the vendor's documentation.
- 5Recruit two or three people from that team as the visible first line of help for the next wave.
- 6Expand by team, not by feature, and turn off the thing being replaced for each team as it goes live.
- 7Review usage after a month and remove seats and fields nobody touched.
Warning Signs in the Answers
- Single sign-on priced as a premium tier tells you how the vendor thinks about security and about upselling.
- An export that will not include attachments, comments, or history is a lock-in mechanism regardless of how it is described.
- Reluctance to name a customer of your size usually means they do not have one.
- A support answer that starts with the knowledge base and the community forum means your administrator is the real support function. Budget their hours accordingly.
- Any critical requirement answered with a roadmap date should be treated as unavailable. If it matters, make the contract contingent on it.
- Watch for per-record or per-API-call pricing on something that scales with your success. Model the cost at three times your current volume before signing.
Common Pitfalls
Buying for the Manager's View Rather Than the User's Work
Dashboards sell software and daily data entry decides whether it survives. If the tool produces excellent reporting by adding six fields to a task someone does thirty times a day, that person will stop filling it in and the reporting will become fiction.
Skipping the Turn-Off
Leaving the old spreadsheet, inbox folder, or previous product available guarantees a split. Set a date, communicate it, archive the old thing read-only, and expect one or two weeks of complaints. The alternative is paying for two systems and trusting neither.
Letting Configuration Drift Without an Owner
Six months of ad hoc custom fields, half-used workflows, and departed users still holding licences is the normal end state without an administrator. Give one person the responsibility, an hour or two a week, and a quarterly cleanup on the calendar.
Underestimating Data Cleanup
Importing duplicates, blank required fields, and free text where codes belong reproduces your existing mess in a place that is now harder to fix. Decide the cleanup rules before import and accept that this work needs someone who knows the domain, not the vendor.
Measuring Logins Instead of Outcomes
Adoption dashboards count activity, which is easy to satisfy and easy to fake. Go back to the reason you bought it: is the task faster, is the error rate lower, has the reporting replaced a manual process. Take a baseline before launch or you will have nothing to compare against.