Prospecting desk that builds account lists from the live web

Build me a prospecting desk my SDR team opens every day to build target account lists from the live web instead of buying a stale list. It uses Hyperbrowser to find and read company websites, HubSpot as the CRM we push approved accounts into, and Google Sheets as the decision log. Nothing reaches HubSpot until a person clicks approve.

The app opens on two things side by side: a library of saved searches, and the review queue. A saved search is one of our ICP definitions written in plain language, for example "UK fintechs, 50 to 200 staff, currently hiring compliance people". Each saved search is stored in the app's own data with a name, the search description, optional must-have and must-not-have keywords, a target number of companies per run, the rep who created it, and the date of its last run plus how many rows that run produced. Saved searches are visible to the whole team but show their owner, and a rep can filter the library to just their own. Reps can create, edit, duplicate, and archive them.

Each saved search has a Find prospects button that kicks off a background agent. The agent turns the ICP definition into several web queries and runs them with the Hyperbrowser Search Web operation, collects candidate company sites from the results, and drops anything already on the suppression list, already in the review queue, or already found by a previous run of the same search. For each remaining company it starts a Hyperbrowser scrape with Start Scrape Job and polls Get Scrape Job Result for the home page and any obvious about, product, careers, and contact pages, then runs Start Extract Job with a schema and polls Get Extract Job Result to pull structured fields out of that content. Hyperbrowser scrape and extract jobs are asynchronous, so every job must be started and then polled until it completes before the agent writes anything. When a careers page is a JavaScript widget or an embedded job board that scraping cannot read, the agent falls back to Start Browser Use Task with an instruction like "open the careers page and list the current openings with titles and locations" and reads the answer back with Get Browser Use Task Result.

Every company the agent finishes becomes one row in the app's review queue, written back as the run progresses so the queue fills in while the rep watches. A row holds: company name, website domain, country and city, what they sell, who they sell to, an estimated headcount plus the signal it came from, careers page activity such as the number of open roles and the relevant titles, contact page details including a named person, role, email, and phone when the site publishes them, two or three short verbatim evidence quotes supporting the fit, the list of source URLs each field came from, the date the pages were read, the saved search and run that produced it, and a status of new, approved, rejected, or snoozed.

Reps work the queue like an inbox. Each card shows the extracted firmographics on one side and the evidence on the other: the quotes, the source links, and the date read, so a rep can check any claim in one click. Cards can be filtered by saved search, by status, and by owner, and sorted newest first. Every card has three actions: approve, reject with a short reason picked from a list such as wrong size, wrong market, already a customer, or no real signal, and snooze with a date, which hides the card until that date and then returns it to the queue. Show a small header count of new, snoozed, approved today, and rejected today.

Approving runs a handler that goes to HubSpot in order. First it calls Search Companies filtered on the website domain, and if that finds nothing, on the company name, so we never duplicate an account we already own. If a match comes back, the card is marked as an existing account, the app shows the rep which HubSpot record it matched, and nothing is created. If no match comes back it calls Create Company with name, domain, city, country, industry, and a short description from the extraction. Then, only when the site gave us a real named person with an email address, it calls Create Contact with that name, email, phone, and job title, associated to the new company. Finally it calls Create Note with the research summary, the evidence quotes, the source URLs, and the date read, associated to the company record so the next rep who opens that account sees where it came from. Show the rep the created HubSpot record links on the card once the push finishes, and if any step fails, keep the card in the queue with the error visible so they can retry rather than losing the work.

Every approve and every reject also appends one row to a Google Sheets log using Append Values, with the date, the rep, the saved search name, the company name and domain, the decision, the reject reason when there is one, the headcount and careers signals, whether it was already in HubSpot, and the source URLs. That sheet is how we see list quality over time, so also give the app a small stats strip reading from the app's own data: approval rate per saved search, rows found per run, and the most common reject reasons over the last thirty days. That view is what tells a manager which ICP definitions are actually working.

Two rules matter more than anything else. Nothing is written to HubSpot without a human clicking approve, so no part of the search agent may call any HubSpot create operation. And rejected companies go onto a persistent suppression list keyed by website domain, which every future run of every saved search filters against, so a company someone already turned down never resurfaces. Let a rep view the suppression list and remove an entry if they rejected something by mistake.