When a buyer asks for a SaaS demo on X, offer an existing demo if it shows the workflow they named. Suggest a trial instead if they need to test that workflow themselves and your trial lets them do it. If a missing requirement could change which experience fits, ask one focused question first. Check the current thread and what you actually offer before promising any of those options.
Find out what the buyer wants to see
Read the live post and its replies before treating “Can I see a demo?” as a request for a general product tour. Look for the task the buyer wants to accomplish, their current way of doing it and any condition that would make the product useful or unsuitable. A buyer asking to see approvals before switching tools may care about routing a request to the right person, recording a decision or handling an exception. Those are different things to show.
Then check your own options: what each existing demo actually shows, whether the buyer can access it, and what a trial allows them to test without additional setup or permissions. If a live walkthrough is an option, confirm that you can offer one before mentioning it. The buyer’s post establishes what they asked for, not what your team can deliver.
Choose the experience that answers the request
The deciding question is whether the buyer can evaluate their stated workflow through the option you offer. A demo can show a path through the product without making the buyer configure it; a trial gives them room to try their own inputs, provided the relevant capability is available to them. Neither is automatically better. Compare the buyer’s need with the content and conditions of your actual offer.
| What you know | Check before replying | Next action |
|---|---|---|
| They named a workflow you can show. | An available demo covers that workflow and any stated constraints. | Offer that specific demo. |
| They want to test the workflow with their own inputs. | Your trial includes the needed capability and the buyer can reasonably set it up. | Offer the trial; mention relevant setup conditions. |
| A missing requirement could change the choice. | Identify the one distinction that affects what you can show or let them test. | Ask one clarifying question first. |
| Neither available option covers their requirement. | Confirm the mismatch rather than assuming another experience exists. | Say what is unavailable; do not promise a suitable demo or trial. |
A worked choice: “Show me approvals before we switch”
Consider a fictional buyer who posts: “Can I see how your tool handles approvals before we switch?” Assume the seller has an available demo showing how a request moves through approval routing. The seller also offers a trial, but using approvals in it requires configuration. If the thread makes clear that routing is what the buyer wants to see, the seller should offer the approval-routing demo. Sending them to an unconfigured trial would make them do setup before answering the question they asked.
A suitable response would be: “Yes—our existing demo shows a request moving through approval routing. If that’s the part you’re evaluating, I can share it.” This identifies what the demo covers without implying it shows every approval scenario. The seller should use their real access or sharing method when responding, rather than promising a link they have not checked.
Now change one input: suppose “approvals” could mean routing a request or keeping an audit record, and the seller’s demo only shows routing. The decision changes to clarification: “Do you need to see how requests get routed, or how approval decisions are recorded? Our current demo shows routing, so I want to point you to the right option.” If the buyer means audit records and neither the demo nor trial lets them evaluate that requirement, the seller should say so—not present the routing demo as an answer.
Make the next step specific and accurate
For a trial that genuinely fits, name why it helps: “If you want to try approval routing with your own team’s requests, our trial includes that workflow. It does require configuration first; would hands-on testing be more useful than seeing the existing routing demo?” Use that wording only if those trial conditions are true for your product. If you have no suitable demo or trial, a straightforward answer is more useful than an invitation to discover the mismatch later: “We don’t currently have a demo or trial that shows that workflow, so I don’t want to suggest our routing demo covers it.”
ReachFast reads a SaaS product’s website, evaluates public X posts for potential buyers and prepares replies that open on X already typed. The seller chooses whether to send one. If it surfaces a demo request, compare the draft with the live thread and your real demo or trial options, then edit it before sending if needed. Finding the request and preparing text are not the same as providing or scheduling a demo.
