Research batches that check themselves.
We set up a small system inside your own Google account. It takes a research brief, sources and checks every row against rules you set, files the rows that pass, and brings the rest to you with the reason. Every row keeps its source. Nothing is padded into the file.
A file that looks complete is not a verified file.
Research work rarely fails loudly. It fails with a row that has no source, a link that is dead, a placeholder email and a duplicate entry. All of it survives a visual check and surfaces after the campaign has gone out.
- A list without sources cannot be checked. When a row is questioned, nobody can say where it came from.
- “We need 60 rows” becomes “we delivered 60 rows”. The pressure to hit the number is exactly what pushes bad rows into the file.
- The reviewer sees everything or nothing. Either they re-check the whole batch, or they trust it. Neither is a process.
Which rows are good enough stops being an opinion.
The quality rules live in the run, not in a freelancer's memory. Every row is checked the same way, every time, and the exceptions arrive with the rule that failed. The audit is a Sheet you own, not a mailbox you have to search.
Four steps, and a person still decides.
The checks are code. They never guess a missing field, and nothing is delivered until the exceptions have a decision.
It comes in
A short form sets the topic, the batch size and the minimum source quality. The batch is recorded before any row is sourced.
It gets sourced
Rows are sourced and normalised to one shape: reference, company, contact, category, source URL, source date.
It gets checked
Code checks every rule: required fields present, source live, email domain real, name plausible, category allowed, source fresh, reference unique.
You get the ones that matter
Verified rows are filed with their source and check timestamp. Exceptions go to a queue with the failed rule named, and a pending decision row is created for each.
A verified batch, with the exceptions visible.
Only rows that passed every rule, with the source URL and the check timestamp on each one.
Rows that failed, each labelled with the rule it broke, so a decision takes seconds instead of a re-check.
Who decided what and when, kept beside the batch. The batch can be audited later without trusting the file.
The brief, the size requested and the run timestamps, so scope changes are visible.
If a run breaks, you get an email naming the workflow and the step. A partial batch never passes as a complete one.
The rules are written down, so your team or the next freelancer can read why a row was rejected.
Built and run, not a slide.
Batch RB-470309: 60 rows requested, 52 verified and filed, 8 held back with defect codes, 8 pending decisions. All 52 clean rows passed. All 8 seeded defects were caught. The arithmetic closes.
rows verified
exceptions, with the rule that failed
silently dropped
rule checks passing
Demo environment · sample data · tested on 23 October 2026. Read the case study.
What it does not do.
- The sourcing source is not magic. In the demo the sourcing step reads a fixed fixture so runs are repeatable. In an install it points at the sources you approve or a paid data provider you already use.
- The check is rules, not judgement. It catches mechanical defects. A row that is accurate but useless still needs a human to reject it.
- It does not create demand. It makes a batch trustworthy. Whether a batch is worth commissioning is a different question, and one we will answer honestly.
- One batch per run, quoted per batch. Ongoing weekly batches are a retainer we quote separately.
Start with one batch.
Fixed price, agreed in writing before we start. The batch is deliberately small, because you should see the exceptions before you buy a bigger one.
- Your quality rules written down
- Source URL and check timestamp on every row
- Exception queue with the failed rule named
- Batch and decision audit tabs
- Everything in Starter
- Decision pass on every exception
- Summary email with counts and defects
- Handover notes and the rules written down
Starter is a fixed price. Standard is quoted after your first batch, against the rows, fields and sources you actually need. Prices in USD. Ongoing batches are quoted per batch. No per-row fee and no subscription.
What we need before we quote a batch.
- The topic and the fields you need on every row.
- How fresh a source has to be, and what counts as an acceptable source.
- Who reviews exceptions, and where the decisions should be recorded.
- One sample row you consider good, and one you would reject, with the reason.
The ones we get asked.
Where does our data go?
What counts as an exception?
Can you use our CRM or data provider?
What if we do not know what rules we need?
Send one real batch.
Tell us the topic, the fields you need and how fresh the sources must be. We will tell you what the checks would catch before you commit to a batch.
Demo environment · sample data · fixed-price batches quoted after the brief.