ICPSignalI wouldn't call someone a potential customer just because they used a word related to my product. They could be writing a tutorial, answering a question, or selling something similar. The word tells you where to look. The rest of the post tells you whether there's anything worth doing.
A buying signal gives you more context: a problem, a requirement, an evaluation, or a reason to make a change. Even then, you have work to do. A person can need help without wanting to buy from you. I'd rather understand that early than build an entire sales conversation around an assumption.
I would check three things first
What are they trying to accomplish? Can you help under the constraints they've described? Is there a reason for a conversation now? Those questions keep me focused on the information in front of me.
Someone asking how to organize a process may need an explanation. Someone comparing two tools with a deadline may need help making a choice. Both can be relevant to your business. They deserve different replies.
| Review question | Useful evidence | What it cannot prove |
|---|---|---|
| Need | A task, problem, or request in the post | That the person has budget |
| Fit | Requirements your offer can meet | That missing requirements do not matter |
| Timing | An evaluation, deadline, or switching discussion | That the person is ready to buy from you |
The same topic can mean very different things
Imagine you sell client approval software. The following posts are made up, but they show why matching a topic is only the beginning. I'd read each one with the same question in mind: what would actually help this person?
- “I wrote a guide to client approvals.” Useful reading, perhaps. There is no stated buying need.
- “How should we organize client approvals?” Start with a process they can use. Find out whether software is even part of the problem.
- “We need approval history and guest reviewers. Which tools support both?” Check those requirements against your product before offering it.
- “We fixed it by changing our internal process.” Learn from the solution. The author may already have everything they need.
A score should send you back to the evidence
ICPSignal matches public posts against your ideal customer profile and explains why a potential lead fits. That explanation is useful because you can inspect the reasoning. If it depends on something the author didn't say, keep that uncertainty in your decision.
I want a score to help me prioritize reading. I don't want it making up my mind for me. A high score doesn't establish budget, identify the person behind a username, or give you permission to contact them wherever you can find them. Those are separate questions.
Read the complaint before offering the alternative
A frustrated customer might want their current product fixed. That's a perfectly reasonable outcome. Look for what they actually ask: help with a bug, a workaround, a missing feature, or a replacement. If they're asking how to solve something in the tool they already use, an immediate sales pitch may be a poor answer.
ICPSignal supports competitor names in a profile and can flag switching discussions. Treat that as a reason to investigate. An explicit request for alternatives gives you a different opening from a complaint with no intention of leaving. Be willing to say their current tool still fits if that's what the facts support.
Learn from the posts you reject
When results are noisy, look for a pattern. Are you getting vendors, students, tutorials, or businesses with requirements you can't meet? Each pattern gives you something specific to change in the profile or exclusions. A vague conclusion that ‘the leads are bad’ gives you very little to work with.
Keep a simple note for the posts you review: why it fits, what is missing, and what you decided to do. Over time, that gives you a clearer description of your customer. Start with one profile in ICPSignal and use the original posts to improve it. The useful part is learning to recognize a situation where you can help.