How to Spot SaaS Buying Intent on X

Someone complaining about a software bill may want to switch tools. They may also be venting, joking, or discussing a decision they cannot make. Treating all four situations as a sales opportunity produces replies that miss the point.

For a SaaS founder, buying intent on X is best treated as a hypothesis: this person may be trying to solve a problem your product addresses. Your next reply should help you understand that problem, not assume a purchase is coming.

The method below separates what a post actually tells you from what you hope it means. All sample posts and replies are fictional illustrations.

01Separate interest, friction and an active decision

Start by identifying what the person is doing in the post. Talking about a category is different from describing a problem; describing a problem is different from choosing a solution.

• Interest: “What are people building with scheduling tools?” There is a topic, but no stated need to buy.
• Friction: “I spent my morning fixing calendar conflicts again.” There is a problem, but the person has not said they want another tool.
• Active decision: “We need scheduling for three locations before next month. What handles shared staff?” There is a task, a constraint and a timeframe.

These are reading categories, not a predictive score. A person evaluating tools might choose to build their own solution or postpone the decision. Someone venting might explain a serious need when asked.

02Look for evidence you can point to

Before drafting, write down the exact detail that makes the conversation relevant. If you cannot name one without adding your own assumptions, pause.

Four useful details to look for are:

1. The job: What are they trying to accomplish? “Send invoices to overseas clients” is more informative than “improve operations.”
2. The obstacle: What fails in their current approach? A missing export, repeated manual work or an integration constraint gives you something concrete to address.
3. The change: Are they trying alternatives, replacing a tool or preparing for a new requirement?
4. The constraint: Have they named a deadline, budget, team size or necessary feature?

You do not need all four. You do need to distinguish “they said this” from “I suspect this.” A public job title does not establish purchasing authority, and follower count does not establish budget.

03Read the exchange before choosing a reply

The most useful detail may be in a response below the original post. Open the conversation and check whether the problem has already been resolved or clarified.

Suppose an original post asks for analytics recommendations. A reply says, “We tried three options; the blocker was exporting client reports.” If you answer that person, address the export problem. Do not ask them to repeat the original request for general recommendations.

Also check who is speaking. A consultant describing a client's frustration, a founder discussing their own workflow and a developer comparing implementations may need different help. This is the same context check used when finding people worth meeting on X: understand the contribution before deciding what to say.

04Search for problems in the user's words

Build a small vocabulary from real customer conversations you already have permission to use: the task, the current workaround and the obstacle. Avoid putting private customer details into a public search.

For an invoicing product, possible starting phrases include “invoice export,” “manual invoices” or “switching invoicing tools.” These are search ideas, not evidence of demand. Read each result in context rather than treating a matching keyword as a qualified lead.

X's official advanced search guide explains how logged-in users on X.com can filter by words, exact phrases, accounts and dates. Use those fields to narrow a relevant search, then inspect the actual conversation. A recent result can still describe an old or resolved problem.

05Match your response to the evidence

Your first reply should fit the question being asked. If a person explicitly requests recommendations, a relevant product suggestion can be useful. If they only describe friction, a diagnostic question or a practical suggestion may fit better.

If your product actually supports the requested workflow, explain the fit and disclose that you build it. Name any relevant limitation. Do not claim migration support, savings or compatibility you have not verified. For more examples of specific questions, see the follow-up question guide.

06Keep a small record of what happens next

Use a short note for conversations you genuinely intend to revisit: the post link, the stated problem, your reply and the next step the person agreed to. Separate their words from your interpretation.

Useful outcomes include “clarified the requirement,” “asked for a link” or “already solved it.” Likes and profile visits alone do not tell you someone wants to buy. Neither does generating a reply draft.

If they decline or do not answer, avoid repeatedly chasing the same exchange. Return only with a useful reason and appropriate context. Your notes should make the next conversation more considerate, not create a queue of people to pressure.

Replivio can help prepare a first version of a reply; you still need to judge whether the conversation and wording fit. Explore Replivio's reply drafts, then review the target message, remove unsupported assumptions and publish the final reply yourself.

07Frequently asked questions