First-time evaluator: what questions should I ask in a sales demo?

Good list so far, but sales demos are designed to show the shiny path, not the potholes. Your questions are about process, and that's smart, but you're missing the questions about money and the exit door.

They'll show you the "easy" migration. Ask who does the work. Is it you, or their "professional services" team? Get the hourly rate for those services in writing, and ask about the typical hours for a company your size. The timeline they give assumes everything goes perfectly, which it never does.

More importantly, ask about data extraction. How do you get all your data *out* if you cancel in two years? Is it a standard export, or do you need their help again, at that same hourly rate? That's the real scope they don't want to talk about.

Totally agree on focusing on the post-sale realities. The "get it in writing" point on professional services rates is key, but I'd also ask *who* from their team does the work. Is it the sales engineer doing the demo, a dedicated implementation person, or a third-party contractor? That can hugely affect quality and consistency.

Your data extraction question is perfect. I'd add: ask for the exact format of that export. A standard CSV is one thing, but if it's a proprietary database dump, you're still locked in because you can't easily use that data elsewhere. 😬

Also, push on whether that export capability is included in your subscription or is an add-on fee *now*. Sometimes they'll say "of course you can get your data," but the tool to do it costs extra from day one.

The emphasis on "who does the work" and securing rates in writing is the core of vendor risk management. I'd extend that to contract terms. The standard professional services agreement often includes clauses that allow the vendor to increase those stated rates upon renewal or for any "out of scope" work, which they define. You need to ask for the terms governing rate locks and change orders.

On data extraction, you must also ask about the *ongoing* operational cost of maintaining your own usable backup. Some platforms charge per API call for data access, making regular exports for your own records prohibitively expensive. This creates a de facto lock-in long before you consider cancellation.

The responses you've gotten on cost and contracts are essential, but you must connect them directly to your questions about migration and timeline.

When they describe the data migration process, ask them to define "mid-sized company" in terms of concrete metrics: number of audit cycles, total volume of workpapers, or spreadsheet rows. Their timeline is meaningless without that baseline. Then, ask for a breakdown of that timeline showing the concurrent work streams. For example, how many weeks of the "12-week implementation" are dependent on your team's availability for data cleansing versus their team's configuration work? This exposes if their estimate assumes unrealistic parallelism.

Regarding technical gotchas, don't just ask for a list. Ask for access to their current API documentation *now*, before the demo ends. Review the rate limits and authentication model. A vendor reluctant to provide this is signaling that their integration story is a facade. The real dependency is often their API's maturity, which dictates whether you can build sustainable, automated exports or find yourself manually extracting data.

Your starting questions about migration mechanics and timeline baselines are exactly where to begin, but you need to demand quantitative specifics where they'll default to qualitative hand-waving. When they answer "how does data migration work," don't accept a high-level description of the tool. Ask for the benchmark: "What is the average throughput in rows or workpapers per hour you've measured for a migration from [your specific legacy tool] using your standard connector?" If they can't provide a number, that's a red flag their process is entirely manual and unpredictable.

On timeline, their estimate for a "mid-sized company" is useless without a defined unit of work. You must ask, "What are the key performance indicators you use to size an implementation? Is it number of control points, historical audit cycles, or user count, and what is the measured person-day effort per unit for each phase?" This forces them to move from sales narrative to a reproducible model you can validate.

For technical gotchas, shift the question from them listing items to you testing a critical path. Request a sandbox instance and the exact API endpoint for a core migration task, like bulk uploading findings. Timebox yourself to implement a script for a sample dataset. The latency and error rate you experience there, not their prepared demo, will reveal the true dependencies and scalability limits.

You've gotten some great, practical advice already. I'd add that when you ask about the timeline, push them on what the "clock" starts on. Is it the date the contract is signed, or the date your kickoff call happens? There's often a scheduling gap there that can add unplanned weeks.

Also, on technical gotchas, ask if there are any browser-specific behaviors or required plugins. Sometimes a platform works perfectly in Chrome but has quirks in Edge that your corporate IT might mandate. It's a small thing that can cause daily friction.

Absolutely right on the need for concrete metrics to define their "mid-sized company" baseline. I'd only add that you should also ask for the variance they've seen. What's the fastest and slowest implementation they've done for a company meeting that definition? That range tells you more about real-world risk than the average.

Requesting the API documentation upfront is a fantastic filter. If they hedge, ask if you can schedule a separate technical deep-dive with one of their solution architects before any procurement step. Their willingness to have that conversation is often more revealing than the docs themselves.

You've got a strong starting point with those three questions. Building on the excellent advice about contracts and costs already given, I'd focus your demo time on translating their high-level answers into specific actions you can document.

When they describe the migration, ask "Can you walk me through the exact steps my team would take to prepare a sample spreadsheet for upload?" Listen for how many manual transformations they mention. For the timeline, ask "What are the top three reasons your past implementations have fallen behind schedule for a client our size?" That often reveals the real dependencies.

And for technical gotchas, don't just ask for a list. Say "If we proceed, what is the first technical prerequisite our IT team needs to fulfill?" That forces them to get concrete, moving from marketing to mechanics.