Make the Demo Survive August

Somewhere around February, you sit down for a software demo while registration questions are arriving, hiring paperwork is unfinished and somebody needs the latest version of the health form. The salesperson shares a polished screen. A camper profile appears. The cursor moves cleanly from tab to tab. Nothing is misspelled, nobody has entered the same parent twice, and the Wi-Fi never drops.

You can watch that presentation and learn almost nothing.

A useful demo is closer to a fire drill. You supply the situation, the vendor works inside the product, and every awkward pause becomes information. The goal is not to see what the software contains. It is to see what the software makes your staff do when camp is full, the office is loud and a parent is waiting on the phone.

Bring your own camper

Vendor sample accounts are built for demonstration. The household is tidy. Forms are complete. Balances make sense. Every person has a distinct email address.

Your database will not look like that.

Before the meeting, write a fictional household that resembles the records your office actually handles. Give the campers different sessions. Add separated parents with different permissions. Include a grandparent who pays but should not receive health information. Leave a required form unfinished. Put money on the account, then change something that affects the balance.

Ask the salesperson to create that household from scratch while sharing the screen. Do not accept a tour of a household prepared earlier. You need to see where relationships are defined, how permissions are assigned and what happens when the family structure does not fit the default path.

Then change the facts. Move a camper to another session. Add an authorized pickup person. Correct the primary email address. Mark a form incomplete after it was previously accepted.

That is where the product starts telling the truth.

Narration is not execution

A weak demo relies on sentences that begin with “you can.” You can export that. You can customize this. You can give staff access. The feature may exist, but the explanation conceals the steps, permissions and cleanup attached to it.

Ask to see the action completed.

If the vendor says reports can be customized, request a report using fields you chose. If staff permissions can be restricted, ask the presenter to create a role and show what that user sees. If an email can be sent to families with missing forms, have the presenter build the recipient group and display the message preview.

Stay quiet while the work happens. A salesperson filling silence with commentary can make a long workflow feel shorter than it is. Watch the cursor instead.

Also notice when the presenter leaves the main application. A spreadsheet, separate document editor or support portal may be a sensible part of the process. It is still part of the process, and your staff will have to use it.

Ask August questions

A demo usually takes place in a quiet room during the buying season. Your consequential software use happens when campers are on property.

Put the presenter inside that day.

Say a counselor brings a camper to the health center, but the nurse cannot find the latest medication instructions. Ask how the nurse locates the record and how the system shows who last changed it. Say a parent calls the office to change an authorized pickup person while the camper is already assigned to an activity. Ask where the change appears and which staff members are notified.

Then test the handoffs. Registration data may need to reach transportation, food service, cabin assignment or the health center. The relevant question is not whether the data exists. It is how the right person receives the current version without rebuilding a list.

Use situations with interruption built in:

• A staff member begins a task, gets pulled away and returns later.
• A family submits a correction after an internal report has been created.
• Two employees edit the same record.
• A seasonal user opens the wrong camper profile.
• Internet access becomes unreliable at a field location.
• A parent calls from a different email address than the one on file.
• A form is complete, but the answer requires staff follow-up.

Ask what the software records, what it warns about and what it permits. Those are different things.

The clicks that count

Counting clicks alone is crude. A short workflow can still be confusing, and a longer one may contain sensible checks. What matters is the amount of judgment your employee must supply between clicks.

Watch for screens where the user has to remember an internal code, know which similarly named report to select or understand a status label that is not explained on the page. Those demands become training obligations. They also become support requests when seasonal staff arrive.

A useful demo table looks like this:

Demo test	What to watch
Correct a family relationship	Whether the change updates connected records or requires separate edits
Move a camper between sessions	How capacity, billing, forms and assignments respond
Find an incomplete health item	Whether staff can see the missing information without opening each record
Restrict a seasonal staff account	What the employee can view, change, download and send
Reverse a payment entry	How the correction appears in the family account and internal history
Export an operational list	Which fields are available and how current the export remains
Record a parent communication	Where the note lives and which users can see it
Resume interrupted work	Whether drafts, filters and unsaved changes remain available

Do not rescue the presenter by simplifying your request. If the workflow depends on a setting that is not enabled in the demo account, ask the vendor to explain who enables it, how long that setup takes and whether it belongs to ordinary configuration or paid services.

The distinction matters at contracting time. A checkbox already available to your administrator is different from a customization request, even if both produce the same screenshot.

Dazzle has a proper place

A clean dashboard is pleasant. Automated messages can be useful. A colorful mobile view may make the presentation feel current. None of those screens deserves extra weight simply because it demonstrates well.

Presentation-friendly features tend to be visible and self-contained. Camp operations depend on less photogenic work: correcting records, controlling access, tracing changes and recovering from mistakes. Those tasks rarely produce the moment in a demo when everyone nods.

Treat artificial intelligence features the same way you treat any other feature. Give the tool a camp-specific task, inspect the source information it uses and ask where its output is stored. If a staff member must verify the answer before acting, include that review in the workflow. The animated response is not the whole transaction.

Be equally cautious with phrases such as “fully integrated.” Ask which system holds the original record, how often information moves, what happens after a failed transfer and where staff see the failure. Integration is a chain of ownership. The demo should show the links.

Make permissions visible

Software access is often demonstrated from an administrator account because that account can reach every screen. Most employees will not use that view.

Ask the presenter to switch roles during the meeting. A health center employee should not be represented by a narrated description of health center access. You need to see the actual menu, search results, exports and camper record available to that role.

Test subtraction, not only addition. Remove permission after a seasonal employee has already downloaded a report. Ask what remains in the system history. Disable the account. Ask how an administrator reviews active users and identifies accounts that should no longer exist.

The product’s permission model may fit the way authority works at your camp, or it may force broad access because narrow roles are difficult to maintain. You cannot see that from the administrator dashboard.

Support belongs inside the product test

When the presenter encounters a problem, do not let the moment disappear. Ask how your employee would get help with the same issue during camp.

Have the vendor show the support path rather than naming it. Where does the user submit a request? What account information is attached automatically? Can the employee include a screenshot? Where can an administrator see previous requests? If support access varies by contract or season, ask for that language in writing.

Training deserves the same treatment. A library of videos is not the same as task-level guidance available while an employee is stuck. Ask the presenter to find the instruction for the exact workflow that caused trouble in the demo.

A support promise sounds generous in a sales conversation. A support process is something you can inspect.

End with the failed task

Before the meeting ends, return to the moment that went poorly. It may be the household permission change, the session move or the report that required an export and manual cleanup.

Ask the presenter to perform it again using the recommended method. Then request written confirmation of any configuration, service or contract condition required to make that method available in your account.

A polished demo shows how software behaves when everything has been prepared for it. Your job is to remove that preparation and put August on the screen.