Research a batch of prospect domains before they hit your CRM

I want a prospect research desk that my SDRs open every morning and work a whole list at a time. The rep pastes or uploads a batch of company domains, hits Research, and gets one card per company describing what that company's website actually says, so they stop doing this one browser tab at a time next to a spreadsheet. The unit of work is the batch, not the single account: the value is seeing twenty companies side by side and deciding which ones are worth putting in the CRM. Nothing runs on a schedule and nothing is written automatically. This is a review surface where a human makes a call on every row.

The entry screen is a batch composer. The rep can paste domains into a text area, one per line or comma separated, or upload a CSV and pick the column that holds the domain. Normalize what they give you before doing anything else: strip the protocol, strip www, strip any path or query string, lowercase it, and drop duplicates within the batch, showing a small note about how many duplicates were collapsed. Flag anything that is obviously not a domain and let the rep fix or remove it rather than failing the whole batch. Let them name the batch, defaulting to something like the date. Under the composer, list the rep's recent batches with their name, date, how many domains were in them and how many are still unreviewed, so a rep can reopen yesterday's batch and finish it.

The very first thing that happens after Research is pressed, before any scraping and long before anything is written, is a CRM check on every domain in the batch using HubSpot Search Companies filtered on the company domain property. Every card carries a badge from that answer: new, meaning no matching company exists, or already in CRM, in which case show the existing company name, its record owner resolved to a real person's name with HubSpot List Owners, and the record's last modified date. If several companies match one domain, say so and let the rep pick the right record rather than guessing. This badge is the whole point of the CRM check: reps must never create a duplicate of an account a colleague already owns, and they should find that out before they spend time reading the site.

Research each domain with Browserless. Read the homepage first with Smart Scrape or Get Page Content, then use the homepage navigation to discover the pricing page and the careers or jobs page rather than blindly guessing URL patterns, and read those two as well. Where a page is a structured list, such as a plan comparison table or a jobs board, Scrape Elements is a good fallback for pulling it out cleanly. Separately, run Browserless Search Web for recent mentions of the company, keeping results from roughly the last six to twelve months and dropping results that come from the company's own domain, since those are already covered by the pages you read directly. Research the domains concurrently but cap how many run at once, because Browserless plans have a concurrent browser limit and a large batch will otherwise hit it. Cards should stream in and become reviewable as each one finishes instead of the rep staring at a blank screen until the last domain lands.

Each card is a compact, scannable summary, because the rep is comparing many of them rather than reading one deeply. It shows the company name and domain, the CRM badge, a short positioning summary of what the company does and who it says it sells to written in plain language, the apparent pricing model, hiring signals, and the recent mentions worth knowing. For pricing, capture the shape of it: whether it is published at all, whether it is per seat, usage based, tiered or quote only, the names of the plans and any entry price. For hiring, capture what the open roles suggest: how many roles are open, which functions they cluster in, and any location signal, since a hiring push concentrated in one function is the actual buying signal a rep cares about. Every single claim on the card carries a link to the page it came from. A rep may repeat these facts out loud on a call and has to be able to check them in one click.

Degrade gracefully, because the pricing and hiring reads are genuinely best effort. Plenty of companies have no pricing page, no careers page, or a site that blocks automated reading. When a source is missing, the card must say which sources were found and which were not, for example that the homepage was read but no pricing page was found, and leave that section visibly empty. Never invent a pricing model, a headcount or a hiring trend to fill the space, and never present an inference from the homepage as if it came from a pricing page. A card with one good source and an honest gap is useful. A card with a confident guess is worse than useless, because the rep will repeat it.

Every card has two decisions: Push to HubSpot, or Skip. Push opens a short confirmation showing exactly what is about to be written and lets the rep edit the summary text first, since the written brief is what their colleagues will read later. If the badge says new, write the record with HubSpot Create Company, setting the domain, name and whatever firmographic detail the research reliably supports. If the badge says the company already exists, use HubSpot Update Company against that record id instead, and only fill properties that are currently empty or that the rep has explicitly ticked, so the app never quietly overwrites something a colleague entered by hand. In both cases, follow up by attaching the research to the record with HubSpot Create Note containing the edited summary and the full list of source URLs behind it. Always write the rep's edited text, never the originally generated text. Skip marks the card as passed on and optionally captures a one line reason, such as too small or wrong vertical, because that reason is the most useful thing in the whole log for whoever tunes the target list next.

Log every reviewed batch to a Google Sheets tab with Append Values so managers can see which domains were worked and which were passed on without needing access to anyone's screen. Append a row per reviewed domain with the batch name, the date, the rep who reviewed it, the domain, the company name, whether it was new or already in the CRM, the owner if it already existed, the decision of pushed or skipped, the skip reason if there was one, and a link to the CRM record when one was created or updated. Append rows as decisions are made rather than only when a whole batch is finished, since batches often get left half worked, and make sure a re-reviewed card does not silently produce a contradictory second row without it being obvious which is the later decision.

Scope batches per user. Each rep only sees their own batches, their own cards and their own decisions, because two reps working the same target list should not be reading each other's half finished research. The shared spreadsheet log is the team level view. Alongside that, save each domain's research result and reuse it: if a domain was already researched in the last 14 days, load the saved result instead of scraping the site again, and show plainly on the card that it is a saved result with its age, such as researched 6 days ago, with a refresh control for when the rep knows something has changed. Key the saved result on the domain so a rep who pastes an overlapping list next week does not pay to read the same three pages again.

Handle the unglamorous states properly, since a batch of fifty domains will always contain a few bad ones. A domain that does not resolve, a site that blocks the read, a parked page with no real content, a company whose name cannot be determined, a CRM search that errors, a push that fails partway between creating the company and attaching the note. In every case the individual card should show what happened and stay retryable on its own, the rest of the batch must keep working, and a failed push must never leave the rep unsure whether the record was created. Show batch level progress throughout, such as how many cards are researched, how many are reviewed and how many are left.