Within a day of the demo, send a short email that restates what you saw, lists what was not shown, and asks for written answers by a date. Written answers are easier to compare, easier to share, and harder to walk back than remarks made on a call.
Why write at all
On a call, answers are fluent and friendly. In writing, they become specific or visibly vague. The email also creates a record. If a feature is later missing, you can point to what was said.
It also treats the vendor fairly. They get your questions in one place and can answer with care instead of improvising.
A simple structure
- Thanks and a one line summary. Say what you tested, for example "three repositories, read only".
- What worked. Two or three specifics. This makes the rest of the email more credible.
- What was not shown. A numbered list of items from your scorecard that scored 0.
- Questions. Short, specific, answerable in a sentence or two.
- A date. Ask for answers by a date that suits your decision timeline.
Sample questions
| Area | Question |
|---|---|
| Coverage | Which ecosystems and file types are read, and how are unsupported files reported? |
| Data | What advisory sources do you use, and how quickly do new advisories appear? |
| Fixes | How are fix versions chosen, and what is tested before a pull request opens? |
| Controls | Can automated actions be disabled by repository and category? |
| Export | Which formats can I export at any time, and does that depend on plan? |
| Data handling | Where is repository data stored, for how long, and how is it deleted? |
| Support | What does support include, and what are response expectations in writing? |
| Roadmap | Which items you mentioned are available today versus planned? |
The last row is the one many buyers forget. Demos sometimes mix shipped and planned features. Ask for each item to be labeled as available now or not.
What to avoid
- Questions already answered in public documentation, which can come across as lazy.
- Long essays. A numbered list gets better answers.
- Hints about competing tools. You do not need to name anyone.
- Quoting a price or asking for a discount before you understand value.
What to do with the answers
Add each answer to your scorecard as evidence. Mark anything that arrives as a promise rather than a fact. If an answer contradicts what you saw in the demo, ask for clarification in writing.
Keep your tone warm and plain. The goal is a clear picture, not a debate.
Closing the loop
Whatever you decide, tell the vendor. A short message saying you are moving forward, pausing, or going another direction is courteous and often prompts useful feedback about what was missing. It also leaves the door open for a later conversation.
Where Safeguard fits
If you want a baseline before writing questions, the free scan at gold.safeguard.sh/scan shows Safeguard's output for a repository of yours. Safeguard's GA features include SBOM and dependency scanning, reachability analysis, policy gates and compliance evidence automation.
Quick check
How soon should I send the email?
Within a day, while details are fresh. Ask for answers within a week.
Should I copy colleagues?
Yes, your team lead and one engineer. Shared questions keep everyone aligned.
Last reviewed: 19 October 2026.
