RICK ACQUISITION / POST-FIT PREPARATION

PREPARE THE CAMPAIGN PACK.
A HUMAN REVIEWS IT BEFORE RUNTIME.

This page captures the useful inputs for a post-fit preparation review: your ICP, public signal, offer, proof, constraints and handoff details. The YAML preview is a local draft mapping. It is not the live configuration and it does not authorize outreach. The runtime currently reads offer.json and sequence.json; a human maps and verifies any accepted pack before activation.

There are 43 fields across seven sections; 39 are required. Read the limits and the evidence links before typing. A submitted intake is a request for review, not an accepted engagement, payment confirmation, capacity reservation or delivery promise.

// READ THE LIVE OFFER AND FIGURES FIRST

Evidence and commercial terms move. Do not rely on a stale snapshot embedded in this preparation form. Read the live offer, then inspect the dated receipts and weekly figures before applying.

What this page does: prepare a structured set of applicant-provided details for a separate fit and capacity review. It does not prove a campaign will work, reserve a slot, accept payment, or switch on a runtime.

// WHY WE MAKE YOU WRITE DOWN WHAT WE MAY NOT SAY

Section 05 records proof points, approved answers to objections, and the boundaries that must survive review. never_claim is mandatory because a human should decide what the pack must not imply before any copy or runtime mapping is considered.

The separate copy and runtime review checks the following before anything can be activated:

// INTAKE — SEVEN SECTIONS, 43 FIELDS / 39 REQUIRED

Required fields are marked *. These are preparation inputs for a human review. They are not a claim that the current runtime consumes this YAML shape, and they do not replace fit, capacity, payment or launch decisions.

RELAY ACCEPTED FOR ROUTING
The intake relay acknowledged this application. That does not confirm human inbox review, fit, available capacity, payment, a service start date or runtime activation. Those decisions remain separate and require explicit human confirmation.
Before you submit: this intake is relayed through the shared inquiry path to [email protected] for review. Do not include passwords, API keys, private customer lists, health data or other sensitive personal data. Read the privacy policy; contact [email protected] to request access or deletion.
01 — IDENTITY & SENDING DOMAIN → preparation mapping
The human a warm prospect gets handed to. Must be a person, not "the team".
This is not a cosmetic choice. It becomes sender.stance and lands in never_claim automatically: pick referral_partner and every template that says "we at <vendor>" fails the linter. Client #1 is a referral_partner pack, which is why its copy introduces the client instead of speaking as it.
A subdomain you are willing to burn. Never your primary domain — cold volume on the domain your invoices go out from is how a company loses its email.
Honest answers only. "warm" when it isn't means the first batch bounces and the whole domain is scorched. This field sets your realistic first-send date more than anything else on this form.
Legally required in the footer of every cold email. A template without it fails the linter before it can be enrolled, so this is not optional and there is no way around it.
02 — ICP → preparation mapping
One primary contact per company. We do not email four people at the same firm.
Rough is fine, a guess labelled as a guess is fine. The arithmetic that matters: your reachable universe has to outlast the send cap. At 20/day the list needs to survive 90 days of sending without running dry, or we spend the ramp period re-sourcing instead of selling.
This becomes a hard suppression list at send time, evaluated per recipient and fail-closed. Include current customers and live opportunities — the fastest way to look automated and stupid is to cold-pitch someone who already pays you.
03 — THE TRIGGER SIGNAL → preparation mapping
This is the whole product, so read the question slowly. The mechanic is that we compute something true about a specific company before we write to them. That only works if the thing is publicly observable, per company, without a login. For client #1 it is a review rating and review count — a company in trouble on a review platform announces it to the world. What is the equivalent number for your buyer?
Name the actual public source or provider only. Do not paste a key, token, credential, internal address, or query string. This page records the source for review; it does not fetch it.
This records only a fixed credential category for later review. It never asks for a key, token, password, secret, or owner name.
A number and a comparison, not a vibe. This becomes the gate. Everything below it is not contacted, and a company we cannot measure is never guessed at — it is marked insufficient_signal and a human looks at it.
The single highest-value field on this form and the one nobody expects. Client #1's version: a bad rating caused by trust friction (slow payouts, KYC hoops) is a buy signal, but a bad rating caused by a genuinely broken product is a hard exclude — reputation work cannot fix it, the takedown gets refused because the reviews are true, and the client burns. Your product has the same fork. Find it now or find it in a reply from an angry stranger.
04 — THE OFFER → preparation mapping
The CTA is a word, not a calendar link. It is what got our one reply.
Vague next steps are where warm replies die. If you can't describe it in one sentence, the prospect can't decide to want it.
Becomes the pre-approved answer to "what does it cost?" — an objection that arrives on roughly every thread and that the agent may not improvise.
05 — THE PROOF PACK → preparation mapping — MANDATORY

Three proof points minimum, each with a clean public http(s) URL we can review. Do not paste credentials, private document links, IP/internal hosts, query strings, or fragments. This page records your claims and sources for review; it does not fetch them.

PROOF POINT 1 *
PROOF POINT 2 *
PROOF POINT 3 *

OBJECTION → YOUR ANSWER, VERBATIM

The agent classifies an inbound reply and then sends your answer. It does not compose one. Write these the way you would say them out loud, including the caveats — the caveat is usually the part that converts.

OBJECTION 1 *
OBJECTION 2 *
OBJECTION 3 — THE UNCOMFORTABLE ONE *
Any touch that would speak for you on compliance stays unrenderable until this box has your words in it. That is a hard block in the linter, not a preference.

THE LIST, AND THE ASK

Rick reads it, holds every row with no mail server or no public signal, and keeps the rest for review before any enrollment. Rows outside the ICP you described above are handed back to you rather than emailed.
It is the one figure the closing line types in prose, so it is sourced in your pack like any other number. A pack that types a duration it has not sourced refuses to render at all.
Optional and recorded for review only. Intake does not arm a booking link or promise that it will be used.

NEVER_CLAIM — WHAT THE AGENT MAY NOT SAY, EVEN IF IT WOULD HELP

Three lines are added to every pack automatically and are not removable: no guarantees, no claiming the recipient contacted you first, and no claims about this agent's own results — because it has none, and a tool that inflates its own record is exactly the tool you should not let email your market.
06 — CAPACITY & EXPECTATIONS → separate capacity review
A self-reported capacity input for separate human review. This form does not enforce handoff limits or reserve a slot.
Requested daily volume for capacity review, bounded to the currently published intake range. See the live offer and figures for changing operational evidence; this field is not a runtime cap.
Not automatically a no. But if the claim that makes your pitch land is the exact claim you are not licensed to make, the audit has no payload and we should both find that out today.
07 — LAST FIELD → review context

Nothing has been submitted.

No card on this page. A relay acknowledgement is not fit, payment, capacity approval or runtime activation.

// YOUR PREPARATION DRAFT

Built live in your browser from the fields above — nothing is uploaded to render this. This is a preparation draft mapping for clients/<slug>/, not the verified runtime shape. Runtime currently reads offer.json and sequence.json; a human must map and verify any accepted intake before activation.

clients/your-slug/ — draft

// SEVEN WAYS TO BE A NO

Published because you deserve to know the criteria before you spend time, and because a client we should have refused costs us more than an empty slot does.

Everything asserted on this page about what the agent has done is computed from production logs and published daily, including the days that look bad: /receipts and /this-week.