How to research a software vendor before a demo

Before a software demo, you need a short list of questions the vendor's website cannot answer. A generic company profile rarely tells you whether a required export exists, whether a feature needs a higher plan or how pricing changes with usage.

This workflow produces a requirements table and a demo agenda. It starts with the vendor's current documents, then uses review evidence to decide what deserves a closer question. Begin with two products and a few non-negotiable requirements rather than a long ranking of loosely related tools.

1. Define what the product must do

List the workflows, integration requirements and purchase constraints that matter to your team. Separate a hard requirement from a preference. Give the agent exact product URLs so it does not confuse a parent company, acquired brand or similarly named service.

Connect your agent through Vaaya's installation guide, then use a brief like this:

Compare [product URLs] for [specific workflow and team].
Required: [features, integrations, export/security requirements].
Constraints: [seats, expected usage, region and purchase budget].
Use official docs, pricing, changelogs and security pages first.
Use Vaaya within [research budget], checking prices before paid calls.
For each claim preserve URL, retrieval date, plan/version and evidence.
Use reviews to suggest questions, not to invent verified product behavior.
Return a requirements table, unknowns and a focused demo agenda.

The research allowance is separate from the software purchase budget. This workflow does not create trial accounts, accept terms or buy a plan.

2. Search the official material first

The live catalog includes vaaya/onesearch, with a query and optional domain filters, and vaaya/onescrape, which accepts a small list of URLs. Ask the agent to inspect current inputs and price, then retrieve the relevant product documentation and pricing pages.

Read the page behind a search snippet. A marketing phrase such as “enterprise security” does not establish the exact retention option, deployment region or administrative control you need. Preserve what the document actually says and mark unanswered requirements unknown.

Start with pages that can settle several questions at once. Reuse the retrieved text before paying for another lookup of the same feature. Keep documents tied to the correct product edition and version.

3. Put the price on the same basis

For each product, record the pricing unit, plan, billing period and included limits shown by the vendor. Note minimum seats, required add-ons or usage-based charges where the page states them. Keep unknown taxes, currency conversion and negotiated terms out of a falsely precise total.

If the page requires a sales quote, write “quote required” and list your assumptions: team size, expected usage, support needs and purchase period. If a public price applies only with annual commitment, do not present it as a cancellable monthly plan.

An agent may calculate an illustrative total from stated inputs. It should show those inputs and distinguish that calculation from a binding vendor quote.

4. Read review evidence with context

Vaaya lists openwebninja/trustpilot-search, trustpilot-company and trustpilot-reviews. Company and review lookups use company_domain; inspect the current filters when selecting dates or pages. Use a matching public profile only when it refers to the business or product you intend to evaluate.

Separate an individual reviewer's report from independently verified product behavior. A complaint about an older plan may still suggest a useful question without describing the current product. Preserve review dates and sample boundaries; a small retrieved sample does not represent every customer.

Repeated reports are reasons to test a workflow in the demo. They are not a substitute for reproducing the issue or reading the current documentation.

5. Bring a testable agenda to the demo

Return a table like this. These are review fields, not a scored comparison of actual vendors.

Requirement	Evidence	Plan/version	Status	Demo question
A required workflow	Official source URL	Named edition	Supported, unclear or absent	Ask for the exact steps
An operational concern	Dated review and relevant docs	Known or unknown	Needs verification	Ask to reproduce or explain it

Require a source for every “supported” entry. Distinguish a documented absence from a feature you could not find. Finish with the smallest set of demonstrations and commercial questions that would resolve the remaining uncertainty, and save the source packet for the eventual purchasing review.

Questions

Can a review score decide which software to buy?

It is one observation from a particular sample. Check the product identity, reviewer context, date and recurring evidence against your own requirements.

What if the pricing page says to contact sales?

Record the price as unknown and list the assumptions the quote must resolve. Do not fill the gap with an estimate presented as the vendor’s price.

Does this require dedicated G2 or Capterra APIs?

No. The workflow starts with official pages and supported search/extraction. Use available review sources honestly; do not imply that a particular review-site connector exists without checking the catalog.