# CRM Demo Checklist

**SoftwareGlimpse** · Updated 15 Aug 2026  
**Type:** CHECKLIST · **Stage:** EVALUATE  
**JTBD:** Run buyer-led CRM demos with identical live scenarios and same-day scores.

> Run the same buyer-led demo script with every vendor. Use this during vendor demos to control the agenda, force the same live CRM tasks on every product, and mark results the same day — before the next session overwrites your memory.

## How to use

1. **Pick the scenarios** — Choose 6–10 rows from your must-haves; drop anything you cannot check in one session.
2. **Send the brief** — Agenda, stage names, exit checkpoints, and sample record names 48 hours ahead.
3. **Assign roles** — One facilitator, one scorer, plus the seller, manager, and admin who will use the CRM.
4. **Run the agenda** — Hold the time boxes; hand control to your people for at least one task.
5. **Score the same day** — Mark every row with evidence before the next vendor session starts.
6. **Follow up and hand off** — Send written questions, then transfer results to the Vendor Scorecard.

## Result key

| Result | Meaning |
| --- | --- |
| Pass | Verified with evidence |
| Partial | Met with limits or a workaround |
| Fail | Does not meet a required check |
| Not tested | No evidence yet — do not invent a Pass |

## Evidence that counts

- A task completed live on visible records during the session
- Screenshot or session recording with a timestamp
- Written vendor answer sent after the demo
- Product documentation for the edition you were quoted

## Evidence that does not count

- A slide claiming the capability
- “We can show that in a later workshop”
- Marketplace listings or logo walls
- Notes written from memory days afterwards

## Checklist

### 1. Demo prep & agenda

Set the session up so the vendor demonstrates your process, not their showcase.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1.1 | Buyer-owned agenda sent in advance | Vendor-led agendas drift into feature tours you cannot compare. | Must-have | Send a timed agenda 48 hours ahead: short intro, live task block, admin block, manager block, Q&A. | | | |
| 1.2 | Stage names and sample records shared | Vendors can only run your process if they have your names and records. | Must-have | Send your stage list, exit checkpoints, and anonymized account, contact, and deal names with the agenda. | | | |
| 1.3 | Identical script booked for every vendor | Sessions that cover different ground cannot be compared afterwards. | Must-have | Book the same session length and the same scenario list for each shortlisted vendor. | | | |
| 1.4 | Mailbox or calendar access arranged | Email sync can only be proven with a mailbox someone in the room controls. | Nice-to-have | Confirm whether a buyer mailbox can connect for the session, or agree the vendor demonstrates on theirs and you retest in trial. | | | |
| 1.5 | Scorer named and score sheet ready | Nobody scores accurately while also running the room. | Must-have | Name one scorer and share a blank sheet with one row per scenario before the session opens. | | | |

### 2. Live CRM tasks

Run these in the same order with every vendor. Mark only what appears on a record.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 2.1 | Create account, contact, and deal live | Shows whether the objects and required fields fit your process before anything else is discussed. | Must-have | Ask the vendor to create all three from your sample pack, with required fields set and the records linked on save. | | | |
| 2.2 | Advance a deal through your stages | Stage names and exit checkpoints are where generic demos usually break down. | Must-have | Move a deal through two of your named stages; ask how an exit checkpoint such as next step or amount is enforced or warned. | | | |
| 2.3 | Set an owner and a dated next step | Unowned deals with no next action are the most common pipeline failure. | Must-have | Set owner and next-step date on the open deal, then confirm both appear in a list or board filter. | | | |
| 2.4 | Log an activity on the intended record | Daily adoption depends on activity capture landing where people look for it. | Must-have | Log a call or note on the contact and confirm it appears on the related deal timeline. | | | |
| 2.5 | Show an email landing on a contact or deal | Email sync is the most common gap between what a slide claims and what the edition does. | Must-have | Sync or log one message, point at the record it lands on, and note which edition the behaviour requires. | | | |
| 2.6 | Merge a duplicate contact or account | Merge behaviour decides whether your data stays usable after import. | Nice-to-have | Merge two sample records and confirm related deals and activities follow the surviving record. | | | |

### 3. Manager & admin views

The people who coach the pipeline and maintain the system should see their own screens.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 3.1 | Pipeline board filtered by owner and stage | Managers need weekly status without exporting to a spreadsheet. | Must-have | Filter the board by owner and stage using the deals created earlier in the session. | | | |
| 3.2 | Stuck or ageing deals surfaced | Coaching depends on finding the deals nobody has touched. | Must-have | Ask for a view of open deals with no next step, or with time in stage above a threshold you name. | | | |
| 3.3 | One admin change made live | Ongoing admin effort is part of the product, and you only see it by watching someone do it. | Must-have | Ask the vendor to add a field to the deal layout or change one permission during the session, not offline. | | | |
| 3.4 | Forecast view built from session deals | Forecast screens on slides rarely match what the quoted edition includes. | Nice-to-have | Open a forecast or commit view containing the deals created live, or record which edition unlocks it. | | | |

### 4. Roles in the room

A demo where only the vendor touches the keyboard tells you very little.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 4.1 | A seller runs at least one task | Vendor-driven clicks hide how the product feels for the people who use it daily. | Must-have | Hand control to a seller for one scenario — creating a deal or logging an activity — and note how long it took. | | | |
| 4.2 | A manager asks their own questions | Forecast and coaching needs get lost when one person speaks for everybody. | Nice-to-have | Reserve time for the manager to drive the pipeline and stuck-deal views themselves. | | | |
| 4.3 | The future admin attends | Admin burden lands on a named person, and that person should watch the work. | Must-have | Confirm the intended admin joins and asks about users, fields, stages, and weekly hygiene. | | | |

### 5. Same-day scoring & follow-up

Close the session out before the next vendor overwrites what you saw.

| # | Check item | Why it matters | Required? | Test / Scenario | Result | Evidence | Notes |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 5.1 | Every scenario marked before the next session | Memory fades fast, and the loudest voice wins late debriefs. | Must-have | Mark Pass / Partial / Fail / Not tested for each row within the same working day. | | | |
| 5.2 | Evidence attached to each result | A result without proof cannot be defended in the decision meeting. | Must-have | Attach a screenshot, recording timestamp, or written vendor answer to every row that is not Not tested. | | | |
| 5.3 | Unrun scenarios recorded as Not tested | Inventing a Pass to fill a gap destroys comparability across vendors. | Must-have | Where the vendor declined or ran out of time, mark Not tested and write the reason. | | | |
| 5.4 | Open questions logged with owner and due date | Gaps found in a demo tend to disappear until contract pressure brings them back. | Must-have | Send written follow-ups the same day for anything a must-have depends on, and note what it blocks. | | | |
| 5.5 | Results transferred to the scorecard | This checklist records what you observed; the scorecard applies weights and compares. | Must-have | Copy the marks and evidence into the Vendor Scorecard rather than re-scoring from memory later. | | | |

## Worked example

_Hypothetical Vendor A / Vendor B scenario for teaching the artifact — not a SoftwareGlimpse case study._

**Requirement:** A seller advances a deal through our stage names, with an owner and a dated next step visible on the record.

| Scenario | Result | Note |
| --- | --- | --- |
| Vendor A | PASS | Ran our stage list in the session; owner and next-step date appeared on the deal and in a board filter. |
| Vendor B | PARTIAL | Advanced a deal on their sample pipeline but could not show our stage names during the session. |

**Evidence:** Observed live in the demo session; screenshot filed the same working day.

## FAQ

**What does this checklist deliberately leave out?**

Requirements definition belongs in the CRM Requirements Template, and weighted comparison belongs in the Vendor Scorecard. This checklist covers one thing: what you make each vendor do live in the demo, and how you record it the same day.

**Should we send vendors the whole scoring sheet?**

Send the agenda, stage names, exit checkpoints, and sample record names so they can prepare a sandbox. Keep the weights and the pass bar internal so the session tests the product rather than the vendor’s ability to read your rubric.

**How long should a demo be?**

Most teams work well with 60–90 minutes: a short intro, most of the time on live record tasks, a brief admin and manager block, then Q&A. Longer sessions tend to drift into feature tourism that nobody can score.

**What if the vendor cannot run a scenario live?**

Mark it Partial or Not tested with a reason, and log a written follow-up. Do not accept a promise of a later workshop as a Pass for a must-have — carry it into the trial plan instead.

**Can we change the script between vendors?**

Only with explicit agreement and a note on what changed and why. Silent changes to the scenarios are the fastest way to end up with results you cannot compare.

**Who should be in the room?**

A facilitator, a separate scorer, a seller who will create deals, a manager who runs pipeline reviews, and whoever will administer the CRM. Add IT or security if email sync or SSO is in scope. Keep it small enough to stay disciplined.

**How does this connect to a trial?**

Anything marked Partial, Fail, or Not tested becomes a trial task. Demo scenarios prove the product can do it; the trial proves your team can do it on real data.

## Related journey

1. [CRM Requirements Template](https://softwareglimpse.com/resources/crm-requirements-template/)
2. **CRM Demo Checklist** (this resource)
3. [CRM Evaluation Checklist](https://softwareglimpse.com/resources/crm-evaluation-checklist/)
4. [CRM Vendor Scorecard](https://softwareglimpse.com/resources/crm-vendor-scorecard/)
5. [CRM Business Case Template](https://softwareglimpse.com/resources/crm-business-case-template/)

## Related tools

- [CRM Vendor Scorecard](https://softwareglimpse.com/tools/crm-vendor-scorecard/)
- [CRM Requirements Builder](https://softwareglimpse.com/tools/crm-requirements-builder/?start=1)
- [CRM Finder](https://softwareglimpse.com/tools/crm-finder/)

---

Source: https://softwareglimpse.com/resources/crm-demo-checklist/