Why a demo is different from the product
When you become a customer, your data is covered by a contract: who may access it, where it is stored, how long it is kept, what happens after a breach. A public demo usually has none of that. You have agreed to, at most, a set of website terms, and the environment was built to be disposable.
None of this is a criticism. A demo that demanded a contract before letting you in would not be much of a demo. It means the caution has to come from you.
What to keep out
- Personal data. Names, addresses, phone numbers, dates of birth, identity numbers, health or payroll information about real people: customers, staff or anyone else. They did not agree to be test data.
- Customer and supplier records. Your customer list, your prices to each of them, your supplier terms. This is commercially sensitive whether or not it is personal.
- Credentials. Never connect a demo to a live system with real keys, and never reuse a password from anything that matters. If a demo asks you to connect your accounting or email account to "see it working", stop and ask for a test account.
- Regulated or controlled data. Anything covered by export control, a security classification, a customer confidentiality agreement or a sector rule. A demo environment has not been assessed for it, and its location may be unknown to you.
- Real documents. Uploading last month's actual invoice or contract to test an attachment feature puts all of the above into the demo at once.
What to check before typing anything
A well-run demo tells you these things on its first screen. If it does not, look in the terms, and if they are silent, assume the cautious answer.
| Question | Why it matters | If you cannot tell |
|---|---|---|
| Is my workspace private? | Some demos are one shared environment where every visitor sees every other visitor's entries | Assume shared. Enter nothing you would not post publicly |
| How long is it kept? | A demo may be wiped in hours, or kept indefinitely | Assume kept. Do not rely on deletion you cannot confirm |
| Does it send email or messages? | Test records with real addresses can send real notifications to real people | Use addresses on a domain you control, or ones that cannot receive mail |
| Who at the vendor can see it? | Sales teams often watch demo activity to judge interest | Assume it is watched |
| What did I agree to? | Website terms may allow use of what you enter | Read them once; they are usually short |
Build data that is realistic but not real
The opposite mistake is testing with "Test 1, Test 2, asdf". Meaningless data hides exactly the problems you are looking for. What you want is invented data with the same shape as yours.
- Copy the structure, not the content. Take ten real records and rewrite them: same number of line items, same kinds of units, same awkward cases, different names and numbers.
- Keep the difficult cases. The partial delivery, the order with forty lines, the customer with two sites, the part with a revision letter. These are what you are testing.
- Use names that are obviously invented. A fictional company name is safer than a slightly altered real one, and nobody will later mistake the record for a real customer.
- Use addresses that cannot receive mail. The reserved domains example.com, example.org and anything ending .example exist for this purpose and are never delivered.
- Keep the set. Save the invented records in a file. You will reuse the same ones for every product you look at, which is what makes a comparison fair.
When real data is the point
Some questions cannot be answered with invented records: whether your import file loads, whether the product copes with your volume. That is the job of a proof of concept, and it moves you out of the public demo into an environment covered by an agreement. Before any real data is sent:
- A confidentiality agreement in both directions, signed.
- A data processing agreement if the sample contains personal data and the law that applies to you requires one. Ask your own adviser; requirements differ by country and sector.
- A dedicated environment, separate from the shared demo and from other customers.
- A smaller, cleaner sample than you first thought of. Remove the columns the test does not need. A test of whether orders import does not need the contact's mobile number.
- A deletion date, and a written confirmation when it has happened.
What a careful demo looks like from outside
You can tell a fair amount about a vendor from how their demo treats strangers' data. Signs of care: the first screen says what happens to what you enter; each visitor gets a separate workspace; sample data uses invented names; nothing in the demo sends mail to the outside world; old workspaces are removed on a schedule. Signs of the opposite: other people's test entries visible in the lists, real company names in the sample data, or no statement at all.
The Cargovate demo, which we run, states on its entry page that each workspace is visible only to the person who made it, that it is deleted automatically, and that nothing real should be put in it. We built it that way for the reasons on this page, and the walkthrough shows how to check claims like those from the outside.
If you already entered something real
It happens. Delete the records inside the demo if you can, then write to the vendor through their contact page, say what was entered and ask for the workspace to be removed. If credentials were involved, change them now and do not wait for a reply. Then add a line to your checklist for next time.