demosaas

Evaluating business software

Try the software before you talk to anyone selling it

A demo is the only stage of buying software where you can find out what it does instead of being told. These guides are about using that stage properly: which kind of demo proves what, what to test while you are inside one, and what to ask for when a demo is not enough.

An evaluation sheet with three columns: saw it work, was told, could not test. Five rows, each ticked in one column SAW ITWORKWASTOLDCOULDNOT TEST Did my own taskWrong inputRestricted userExport everythingTen thousand records
The sheet every guide here comes back to: for each thing you need, how do you know?

Seen is not the same as said

Keep two columns. What you watched the software do goes in one; what somebody told you it does goes in the other. Most bad purchases were made from the second column.

Bring your own task

A demo is built to make one path look effortless. Do the job you actually have, with the awkward detail left in, and see how far you get without help.

A demo has limits. Name them

Sample data and one user cannot show you scale, permissions or an integration. Write down what the demo could not prove, then ask for that evidence another way.

Demos to try it on

  1. Listed demosBusiness software demos you can open yourself, each described by what it is, what it asks first and what it does with what you type. Vendors: list yours from that page.

The guides, in the order you would use them

  1. Demo, sandbox, trial, pilotSix ways a vendor lets you see software, and the questions each one can and cannot answer.
  2. What a demo hidesNine things no demo environment shows you, and how to get evidence for each of them anyway.
  3. The demo checklistWhat to do in your first hour inside a self-serve demo. Tick it on screen or print it.
  4. Questions for a sales demoWhen the only demo is a call: how to send scenarios ahead and make the presenter leave the script.
  5. The evaluation scorecardComparing two or three products on evidence, with criteria fixed before the first demo.
  6. Proof of concept planOne question, success criteria written first, a real data sample, a time limit and a written result.
  7. Demo data and privacyWhat is safe to type into a demo, what to check first, and how to build test data that is realistic but not real.
  8. Worked exampleThe checklist run against a real public demo by the company that operates it, including what that demo cannot prove.
  9. GlossarySandbox, tenant, seed data, proof of concept, pilot, SSO, SLA, DPA: the vocabulary, in plain words.

Who this is for

Anyone who has been asked to choose software for a team and does not want to choose it from a slide deck: an operations lead picking a system the warehouse will live in, an engineer asked whether a tool does what the sales page says, a founder buying the first piece of software that other people will depend on.

The guides assume business software sold to companies, where a wrong choice costs months because the data and the habits move in with it. They do not assume a procurement department. Most of what is here can be done by one person in an afternoon.

What this site is, and is not

It is a set of guides and a directory of demos. The directory lists demos, not products: each entry says what kind of demo it is and how it treats a visitor, and none is rated, ranked or reviewed. A demo is listed only because its vendor asked, and nobody pays.

The guides name no product except the publisher's own, which appears in one worked example that runs the checklist against a demo we operate and says plainly what that demo cannot show. Who publishes the site, and the rules it is written under, are on the about page.