How to use these questions
Vendor conversations are easy to steer toward strengths. A written list of questions, sent to every shortlisted supplier in the same form, turns a sales conversation into a comparison. This kind of vendor due diligence works best when you ask for answers in writing, note who gave them, and keep them with your evaluation records.
Not every question applies to every purchase. Choose those that match the importance of the system: a tool holding sensitive data or supporting a core process deserves more scrutiny than a small utility. Where answers touch security, privacy or legal terms, ask qualified specialists to review them. This article provides general information, not professional advice.
The vendor and its stability
- How long has the company offered this product, and how many customers of a similar size and sector use it?
- Can you speak with a few existing customers whose situation resembles yours? Remember that references are usually chosen by the vendor, so ask about problems as well as successes.
- How is the product developed and funded? What would happen to support and your data if the company were acquired or stopped trading?
- How does the vendor communicate planned changes, and how much notice is given?
No answer here is conclusive, but vague responses on basic matters are information in themselves.
Product and roadmap
- Which of our listed requirements are met today, and which depend on planned features? Ask for the difference to be stated clearly.
- Can we see the unglamorous parts of the product, such as administration, reporting and error handling?
- How are new versions released, and can we delay or test updates before they affect everyone?
- How much customization is possible without special tools, and how does it survive upgrades?
Treat roadmap promises cautiously. A feature that is planned may be delayed or dropped, so avoid basing a decision on one.
Support and service
- What support channels exist, during what hours, and in what language?
- Which support levels are included, and what do higher tiers add?
- Are there written targets for response and resolution, and what remedy applies if they are missed?
- What training, documentation and onboarding help is provided, and what costs extra?
- Who will be our named contact, and how often does that tend to change?
Compare the support commitments with your own needs. If your staff work across time zones or you rely on the system around the clock, support hours matter a great deal. Internal arrangements for handling problems are covered by ideas such as IT service management, and they should line up with what the vendor offers.
Data access and portability
- Who owns the data we put into the system, and how does the contract say so?
- In what formats can we export our data, how complete are those exports, and can we do it ourselves at any time?
- Is there a documented way for other systems to read and write data, and are there limits or extra charges?
- Where is data stored, and can that be specified?
- What is the vendor’s process for deleting our data after we leave, and can it confirm deletion?
These questions are the practical foundation of reducing vendor lock-in. Verify a sample export during the trial rather than relying on a description.
Security and privacy
- What independent assurance or certification does the vendor hold, and can we see the scope and date? Ask for the documents rather than accepting a logo on a web page.
- How does the product handle sign-in, including single sign-on and multi-factor authentication?
- Can we control permissions in detail, for example through role-based access control, and are actions logged?
- How are backups made and tested, and how quickly could service be restored after a major failure? This connects to business continuity planning on your side.
- How would we be notified of a security incident, and within what period?
- Which other companies process our data on the vendor’s behalf?
Do not rely on a general reassurance. Ask for evidence, and have your security and compliance staff, or outside advisers, judge whether it is adequate for your circumstances.
Commercial terms
- What is the full pricing structure: setup, licences, usage tiers, add-ons, support, storage and integration fees?
- How do prices change at renewal, and is there a cap on increases?
- What is the minimum term, how does renewal work, and what are the notice periods?
- What would it cost to add users, reduce users or end early?
Collect these figures for your total cost of ownership calculation instead of comparing headline prices alone.
Exit terms
- What is the process for ending the contract, and what help is available to move data out?
- How long after termination can we retrieve our data?
- Are there fees for exit assistance?
- What happens to integrations and customizations on exit?
A vendor confident in its product will usually answer these plainly. Reluctance to discuss exit is worth noting in your decision record.
Reading the answers
Look for specific, checkable responses over general claims. Notice whether answers match between the sales contact, the documentation and the contract, since discrepancies are common and the contract is what binds. Where a response is unclear, ask a follow-up in writing. Finally, remember that questions complement testing, not replace it: a well-run software pilot shows how the product behaves, while questions show how the supplier does.