To find your first B2B customers, choose a narrowly defined buyer, look for a recent event connected to a problem you solve, and use that evidence to start a conversation. Confirm the need before proposing a small paid engagement. A buying signal gives you a reason to ask; it does not tell you that a sale is waiting.
Your earliest prospect list should also be a learning tool. You need to discover which problems people describe in their own words, who owns the work, and what they are willing to change. A list of thousands can make those questions harder to answer because every account introduces a different explanation.
Choose a problem you can deliver against now
Write a one-sentence offer with a buyer, a workflow, and a bounded outcome. For example: ‘We help small B2B software teams clean up lead routing when their first sales hires join.’ That is specific enough to guide research. ‘We help companies grow with AI’ leaves you guessing whom to contact and why.
Check your delivery constraints before building the list. If you only support one CRM, need access to a particular data source, or cannot handle an enterprise procurement process, put that in your ideal customer profile. Early enthusiasm is not a substitute for being able to do the work.
Build a small evidence-backed account list
Start with a manageable research batch, such as 20 accounts. This is a suggested workload, not a conversion benchmark. Look through your existing network, company announcements, public professional posts, and relevant communities. A warm introduction can still be your best route when you find a timely reason to talk.
| Field | Useful entry |
|---|---|
| Fit | B2B software company using the CRM you support |
| Observed event | A sales leader describes duplicate lead assignments |
| Evidence | Original public source, event date, and date checked |
| Working hypothesis | Routing rules may need attention as the team grows |
| Unknown | Whether the problem is still open or already owned internally |
| Next step | Ask whether a routing review would be useful |
Separate observation from interpretation in every entry. ‘Hiring two account executives’ is something you can verify. ‘Has budget for our service’ is a conclusion that the job advertisement does not establish. If the original post says the issue has been solved, remove the account from this play rather than finding another excuse to pitch.
Turn one signal into a useful opening
Here is a fictional example. Northline Software’s sales lead posts about duplicate assignments after a team expansion. You provide CRM implementation services and have a relevant routing checklist. Your message can connect the event to that specific resource without pretending to know their internal setup.
Hi Priya — I saw your post about duplicate lead assignments as the sales team grows. Is routing still something you’re sorting out?
I put together a short checklist for checking assignment rules and ownership gaps. Happy to send it if useful.
Only offer a checklist that you actually have. Make it concrete enough to be useful without a call: which rule to inspect, what a conflicting assignment looks like, and how to test a change safely. If someone says the issue is handled or asks you to stop, close the loop instead of moving them into another sequence.
Use discovery to find out what the signal missed
- Ask for a recent example of the problem. What happened, and who had to fix it?
- Understand the workaround. How is the team managing it today?
- Identify the owner. Who would approve changes and help implement them?
- Explore timing. Is there a real milestone, or is this a someday improvement?
- Agree on evidence of success. What would be visibly different after the work?
Keep their answers, including contradictions. A founder who likes your idea but cannot name a current problem belongs in a different queue from a sales manager who can show a recurring failure. Use the pre-outreach qualification guide to keep fit, evidence, and unknowns separate.
Offer a pilot with a clear finish line
For the fictional routing service, a pilot could cover one inbound form, one assignment workflow, a documented set of fixes, and a handover session. Agree on the price, access needed, responsibilities, and acceptance criteria before starting. Do not promise a revenue increase from a change you have not tested.
If delivery is manual at first, say so. Paul Graham’s essay on doing things that do not scale makes the case for founders recruiting and helping early users directly. For this plan, the practical application is to learn which parts of your service deserve to become repeatable before automating them.
Review the learning before increasing volume
After your first research batch, group the outcomes: wrong fit, stale problem, useful reply, discovery held, and paid pilot agreed. A polite reply is not a customer. If several people recognize the problem but reject the offer, inspect the scope and proof. If they do not recognize the problem, revisit the signal and buyer before rewriting the email.
Can you do this without a large audience? Yes: this approach depends on identifying and helping specific accounts. Can you guarantee a customer from 20 accounts? No. The batch is a way to make your assumptions testable, not a promised timetable for revenue.
Next, use the signal-based outreach measurement guide to track what happens after the first conversation, or explore Cnvrted to see its approach to signal-led prospecting.