Account research before outreach: do the homework, show the working
Account research before outreach, on evidence: Runner reads a company's own public pages, files each claim with its source and when it was read, suggests a queue, and a person decides.
Updated
The short version
- Runner reads a company's own public pages on a research account you connect yourself, and files every claim with its source and the time it was read.
- Your team scores fit on five criteria, four rules outrank the total, and a person records the decision with a written reason.
- Research is evidence for a decision and never permission to contact anyone — which is exactly what makes it safe to lean on.
Runner does the homework before anyone sends a word
It's Thursday night. A demo request has just landed from a company nobody on the team has heard of, and tomorrow's first reply will be one of two emails: the one that could have gone to anybody, or the one that shows somebody looked.
Account research before outreach is the difference, and it only helps if it produces the right things before a person acts: what the company is, what it sells, which of those things you know and which you're guessing, and where each one came from. Research that arrives as a confident paragraph with no sources is a rumour with good formatting.
That's the homework Runner takes on. A teammate points it at a company, or a batch of them, and picks a recipe; Runner does the reading. What it finds lands as evidence on the account record, each claim with its source and the time it was read, so whoever writes the first message has something specific in front of them and can check where it came from.
Runner follows four named recipes, and each card says what it reads
Research runs as four named recipes, not a free-form crawl. Each recipe's card in the launcher says which kinds of source it's allowed to read and the most a single run may spend, before anybody clicks anything.
The reading happens on a research account you connect yourself, on your own key; there's no shared research account behind it. On that account, the reading is the company's own public website — working out which company a domain belongs to, and summarising the site and what the company sells. Give the run a budget and a recipe whose ceiling sits above it is refused before a page is read; a recipe with nothing set up to read for it refuses the run and records why, rather than improvising a source.
Before a run starts, the launcher tells you which reader is about to run: a live read of the public web, or a preview on sample output that visits no outside websites. That sentence is worked out from the reader that will actually run rather than typed once and trusted, and every version of it ends the same way — the run authorises no outreach.
Ask for the same recipe on the same company again soon after, and Runner hands back the run it already did instead of reading the site twice.
Runner files every claim with its receipt
Each piece of evidence is stored with where it came from and when it was read, and the database turns away a claim that arrives without a source type or a time. Each one is labelled for what it is — a fact, an inference, an unknown or a risk — and on an account's research page, the risks are listed first.
A run that fails, is refused for its budget or breaks a source rule keeps no evidence at all. Nothing half-read sits on the record looking finished.
Evidence ages in plain sight. Once a claim is no longer fresh it's marked as ageing, and later as stale, so last spring's pricing page doesn't pass for this week's.
Nothing gets quietly overwritten. A teammate can review a claim — verified, disputed, corrected or dismissed, with a note — without editing the claim itself. A correction is filed against the original, which stays on the page, dimmed and marked as superseded, with the correction threaded beneath it.
Facts about a company are shared by every product you run. Fit isn't: each product judges it separately, and one product's assessment is never inferred from another's.
Picture this
Northwind's homepage said it sells to hospitals when Runner read it in March. In June a teammate hears on a call that it has moved to clinics, and files that as a correction to the March claim. The March claim stays on the page, dimmed, with June's threaded under it — so the next person to open the account sees that the story changed, and when, instead of whichever version happened to land last.
Your team scores fit, and four rules outrank the total
Once there's evidence, a fit assessment turns it into a suggestion about where an account belongs. The scorecard has five criteria, each worth up to two points, the same for every account. A person gives each criterion its points, ticks the evidence those points rest on and writes a line on why — and the card says so when a criterion has points with no evidence behind them.
Save it, and the assessment is kept beside every earlier one, with the version of the scorecard that produced it. The history shows what changed since the last save and flags it when the scorecard itself changed, so an old total and a new one aren't read as like for like.
The suggested queue — qualified, manual review, insufficient evidence, nurture or disqualified — comes from rules we wrote, not from a model, and the product describes it as a suggestion about your time rather than a decision anyone has made. Four rules outrank the total, and no score gets past them:
- A score never qualifies an account on its own. It suggests a queue; a person records the decision, with a written reason.
- If even one criterion rests on nothing but unknowns, the account stays out of the top queue, however well the other four scored.
- If the evidence is marked as contradicting itself, the account is held at manual review, whatever it scored.
- A disqualifier someone recorded outranks all of it, and the database refuses to save a disqualified account as anything but the lowest fit.
Evidence-based lead qualification means a person signs the call
The scorecard decides what somebody looks at first. Marking an account qualified is a separate act by a person — a score never makes that call — and each decision is written down with who made it, the state the account moved from and the reason they gave.
Qualifying an account already recorded as a duplicate, or excluded outright, is refused. One last marked short on evidence needs evidence added since that decision. For everything else, qualifying takes four things:
- A written reason. A decision with a blank one is turned away before it's recorded.
- Evidence from that account's own record, attached to the decision.
- Every risk on record for the account named in the decision, so a flagged concern gets answered rather than scrolled past.
- A next step that's ready to go — and a ready next step needs an owner, a due date and a measure of success.
The short version
The scorecard orders the pile. A person makes the call, writes down why, and points at the evidence they used.
Runner never treats research as permission to contact, and that's the point
Research is evidence for a decision. It is never permission to contact anyone, and Runner says so itself — in the launcher, whichever reader is about to run, and on the research pages where fit is scored.
That's deliberate, and it's what makes the research worth leaning on. Whether a person may be contacted at all is settled by a separate check that reads consent and opt-outs, and nothing a research run finds is one of its inputs. So a finding has no reason to be dressed up: the reading can be thorough, the queue can be ambitious, and nothing in it sends anything to anybody.
It also keeps research about companies. A run reads what a company publishes about itself and files it as evidence about that company. It creates no contact, and finding people or their email addresses isn't something Runner does.
Picture this
A ten-person dev-tools startup — call it Northwind — lands in the top queue on Friday afternoon. Nothing goes out. On Monday a teammate opens the account, sees the page Runner read and when it read it, and writes a first line about something Northwind actually published. The message is specific because a person had the evidence in front of them, and it reads like it was written for Northwind, because it was.
Where the research stops
A teammate starts every run, for one account or a batch, and the runs in a batch go one after another rather than all at once. Everything else on this page comes back to a few plain bounds:
- Four named recipes, each limited to the sources its card names.
- The live reading happens on a research account you connect yourself, and it reads the company's own public website.
- Evidence and a suggested queue come back; the decision stays with a person, with a written reason.
- Research is never permission to contact anyone, and it looks for no people or email addresses.
One system for the whole path
The mechanism above is one of the jobs Runner does on one record, under one login. Access is by application.