Sending without a named human approving
Refused by the database itself. A send row whose approval is missing, rejected, or recorded by 'system', 'agent' or 'auto' cannot be written at all.
Trust
Most of this category publishes none of this. We would rather you check than take our word, so everything below is specific enough to be checked, and nothing here describes something we have not built.
The one thing on this page we cannot state yet, and why that is the rule working.
A dedicated company for takethemeeting is being incorporated. Until it is registered we are not naming it, because a legal entity is a matter of public record and not a marketing line. The engine takes the same view: it refuses to run a sending wave at all unless a declared legal entity is configured and named in the message. So there is no version of this where a client's first email goes out from an unnamed company. The entity, its number and its registered address will appear here and in the contract before anything is sent on anyone's behalf.
Everyone we rely on, and what each one is for. Eight of the sixteen companies we studied in this category publish no list at all.
| Who | What they are | Why we use them |
|---|---|---|
| Neon | Postgres database, London (eu-west-2) | Client records, signals, drafts, approvals and the ledger |
| Vercel | Application hosting and CDN, London region | The console and this site |
| Companies House | UK statutory register, Crown copyright | Entity verification and corporate-subscriber screening |
| Certificate transparency logs | crt.sh and Certspotter, public logs | Detecting hostnames a company has newly published |
| Cloudflare | Public DNS resolver over HTTPS | Reading published MX, SPF, DMARC and verification records |
| MillionVerifier | Email verification | Confirming an address exists before anything is queued |
| Anthropic | Language model for drafting | Writing drafts a human then approves. Voice rules are enforced in our code, not by the model |
| Attio or HubSpot | Client's own CRM, where they have one | Writing activity back into the system the client already owns |
Client data stays in the client's own workspace and database. We do not pool records across clients, and one client's engine cannot read another's. Data is held in the UK and EU.
Buying a commodity is sensible. Passing it off as your own technology is not, so here is the split.
| Capability | Which | Why |
|---|---|---|
| Signal discovery from public registers and logs | Built | This is the moat. Reading primary sources and computing what changed is our code, not a vendor's feed |
| The approval gate | Built | Enforced by a database trigger, so our own code cannot bypass it |
| Compliance screening and refusals | Built | Country tiers, corporate-subscriber screening, sender-identity checks, opt-out re-checked at send |
| Scoring, drafting and the queue | Built | Ours, because the reasoning has to be inspectable |
| Email verification | Bought | A commodity. We integrate it and gate on it |
| Language model | Bought | A commodity. The constraints around it are not |
| Panel-based intent data | Neither | It requires operating a publisher co-operative. If a client needs it we would license it and say so rather than pretend to originate it |
| Person-level website de-anonymisation | Refused | Structurally US-only, and the honest match rate is 10-15% against 80% claims. It is a consent problem for a UK buyer |
A control nobody can see is a policy. Each of these is enforced in code or in the database schema, and each refusal is recorded as a row the client can read.
Refused by the database itself. A send row whose approval is missing, rejected, or recorded by 'system', 'agent' or 'auto' cannot be written at all.
PECR regulation 23 bars marketing email where the sender's identity is disguised or concealed, and it applies to business email too. A wave refuses to run if the sending identity does not resolve to a declared entity, a declared domain and a real name.
Suppression is re-checked at the moment of sending, not only when the draft was written, because the gap between those two moments is where most breaches happen.
If we cannot confirm from the statutory register that the target is a corporate subscriber, it is held for a human rather than mailed.
Per-mailbox and per-channel caps are enforced in code with a warm-up ramp. Refusals are recorded rather than silently dropped.
The list a vendor never publishes, which is why it is worth reading.
We hold no security certification. We are not ISO 27001 or SOC 2 certified and will not imply otherwise; when that changes we will publish the certificate number rather than a badge. We have no published client results yet, so every number on this site is labelled illustrative where it is illustrative. We do not operate an intent panel or an identity graph, and we will not resell one while describing it as our own data. And we do not send anything without a human approving it, which is the one claim on this site that is enforced by something other than our good intentions.