The lead pipeline we built for ourselves, filed into GoHighLevel
We wanted our own inbound to stop depending on who remembered to look. The system scans job marketplaces, scores each posting against what we actually do, files the ones that fit into GoHighLevel as a contact and an opportunity, and drafts the reply for a person to approve.
The lead pipeline we built for ourselves, in GoHighLevel
Our own inbound: marketplace postings scored against the work we take, filed into a GoHighLevel pipeline, drafted for a reply, with a person still on the send button.
Our own new business came in the way it comes in for most agencies: referrals, people we already knew, and whoever happened to be looking at a job marketplace that morning. The marketplaces are a real source of work for what we do, and they are also a firehose. Postings arrive constantly, most are wrong for us, and the ones worth answering are worth answering within the hour rather than the next day.
Doing that by hand has a predictable shape. You check often for a few days, you find something good, you write a careful reply, and then a busy week arrives and nobody looks for ten days. There is no record of what was seen and skipped, so the same posting gets read three times by three people, or never again. We were selling follow-up systems to other businesses while running our own inbound on memory.
What made it hard
The first difficulty is that most postings are noise, and noise is expensive in a system that notifies people. A pipeline that forwards everything trains everyone to ignore it within a week. Whatever scans has to be opinionated about what we actually do, and it has to be wrong in the safe direction: better to drop a marginal posting than to cry wolf.
The second is that a good reply is specific. A generic proposal sent quickly performs worse than no proposal, because it reads as what it is. So drafting had to produce something that refers to the posting itself rather than filling a template, and it had to arrive with the context attached so a person can judge it in a few seconds.
The third is that we did not want a robot talking to prospects in our name. Speed matters, but the first thing a potential client reads from us is not a place to save time. Whatever the system drafts, a person sends.
The solution
Four moving parts, with GoHighLevel as the place it all lands.
A scraping actor watches the marketplaces and hands over new postings, which keeps us out of the business of maintaining a scraper against a site that changes.
A scoring step reads each posting against the work we actually take: the platforms named, the shape of the problem, the budget signals, the things that mark a posting as somebody looking for a two-hour fix rather than a system.
Anything that clears the bar becomes a contact and an opportunity in a GoHighLevel pipeline, so a lead from a marketplace sits in the same place, and the same stages, as a lead from anywhere else. That is the part that matters more than it sounds: one pipeline means one answer to what is in flight.
A draft reply is written against the posting and saved with the lead, carrying our booking link, and a notification goes out by Slack and email so somebody can look at it while the posting is still fresh.
The approval step is deliberate. The draft is a starting point with the research already done, not an outbound message waiting for a timer. A person reads it, changes what they want, and sends it. Everything else, the finding, the filtering, the filing and the writing, happens without anyone remembering to do it.
The state lives in its own database rather than in the scraper or in the CRM, which keeps two things true: a posting we have already seen never comes back as new, and the record of what was scored and skipped survives independently of any one tool.
Why this pattern fits businesses like this
Any business with a noisy inbound channel has this problem, whether the channel is a marketplace, a directory, a form or a partner feed. The instinct is to automate the reply. The better order is to automate the finding, the filtering and the filing, then let a person do the part that carries your name.
Putting the lead into the same GoHighLevel pipeline as everything else is what makes the channel measurable. A source that lives in someone's inbox cannot be compared with anything, so it never gets a budget or a decision. A source that lands as an opportunity with a stage can.
Where it goes from here
The next version packages the whole thing as a GoHighLevel Marketplace app, so the pipeline, the drafting and the approval flow install into an account rather than being wired up by hand. If your inbound arrives somewhere nobody is watching, tell us where it lands today.
Certified GoHighLevel Admin and Partner. Koby designs CRM migrations, two-way integrations, billing systems and AI agents for service businesses, and writes from the engagements described on this site.
Published
Questions about this engagement
Why not let the system send the replies itself?
Because the first thing a prospect reads from us should be written by us. The system does the finding, the filtering, the filing and the drafting; a person reads the draft and sends it. Speed matters, but not at the cost of the first impression.
What stops it from flooding the pipeline with junk?
The scoring step is opinionated about the work we actually take and is deliberately biased toward dropping marginal postings. A pipeline that forwards everything gets ignored within a week, which is worse than no pipeline.
Why file marketplace leads into the same pipeline as everything else?
So the channel can be compared with every other channel. A lead sitting in an inbox cannot be measured against anything, so it never earns a decision. A lead that is an opportunity with a stage can be.
Could this run against a different source?
Yes. The scan is the only part specific to the marketplace. Scoring, filing into GoHighLevel, drafting and approval work the same against a directory, a form or a partner feed.
More work
A webhook bridge between a specialty clinic EMR and GoHighLevel
A specialty clinic runs scheduling and charting in its EMR and patient communication in GoHighLevel, with nothing connecting the two. The build is a single verified webhook endpoint that routes every EMR event to its own handler, so the clinic's follow-up reacts to what the EMR already knows.
Learn more
A QR code connector that turns trade show visitors into spa bookings in GoHighLevel
Trade show visitors meet spa businesses on the floor, exchange nothing durable, and the connection ends when the show does. The pilot puts a QR code between them: the visitor registers once, and the introduction continues in GoHighLevel after everyone has gone home.
Learn more
A WhatsApp product assistant for a medical device manufacturer, answering into GoHighLevel
An international medical device manufacturer fields the same product questions over WhatsApp from distributors and clinics, one message at a time. The design is an assistant that answers from the company's own product documentation, with every conversation landing in GoHighLevel and a person one step away.
Learn more
Have a similar problem?
Book a 30-minute call. We will tell you what we would do first and what it would cost.