30-day partner onboarding pack to make partners referral-ready

Most partner onboarding dies in the handshake phase. Two directors meet, sign an MOU, promise to "send each other clients," and then nothing usable arrives for weeks. When referrals finally show up, they're missing consent, have no working contact number, or land in someone's personal inbox belonging to a person who left in March.

The gap isn't goodwill. It's that nobody built a structured 30-day runway that forces the partner to prove they can send a complete, consented, routable referral before a real client's wellbeing is riding on it.

This packet is something you can hand to any new partner on day one. It has required fields, consent language the partner's staff can read aloud, a fake referral you run through the whole pipe to catch breakage, acceptance criteria that define "ready," and a 30-day check-in built around one thing: referral reliability. There's also a manager's dry-run checklist so the person running onboarding isn't improvising.

Why most partner onboarding never produces a clean referral

The usual failure isn't dramatic. It's quiet and procedural.

A new partner agency agrees to refer. Their frontline staff were never told what fields you need, so they send a name and "needs housing help" in an email. No DOB, no consent on file, no indication of risk level. Your intake worker now has to call the partner back, who has to call the client back, who doesn't answer. Three days gone. By the time anyone connects, the client has moved, lost the phone, or found another door.

What comes up repeatedly across these partnerships is that onboarding focuses on the relationship and skips the mechanics. Everyone assumes the other side knows the drill. They don't. Your "obvious" required fields are invisible to a partner running a different intake form in a different system.

A second pattern: the partner's leadership onboards, but the people who actually send referrals — case aides, reception, outreach staff — never get the script. So the quality of every referral depends on which individual happened to fill it out. You get one solid referral and four useless ones from the same agency, and you can't figure out why.

The packet below fixes this by treating onboarding like a tested handoff, not a trust exercise. If you already have a solid referral handoff protocol for partner agencies, this packet is the onboarding wrapper that makes partners actually comply with it from day one.

The packet, piece by piece

The whole thing fits in a shared folder or a printed binder. Five components. Keep it boring and complete.

1. Required fields sheet (the non-negotiables)

This is the single most skipped item, and the single most important. Partners can't send what they don't know you need. Spell it out, mark what's required vs. optional, and say why each field matters so staff don't treat it as bureaucracy.

The rule worth pushing here: if a required field is blank, the referral is not accepted — it's returned with a one-line reason. That sounds harsh in week one, but it trains the partner faster than any meeting. A referral that's half-complete costs you more than one that bounces back cleanly.

2. Consent scripts the partner's staff can read aloud

Partners stall on consent because they're unsure what to say, so they either skip documentation or over-explain and scare the client off. Give them word-for-word language. Two versions — one for in-person, one for phone — plus a fallback for clients who hesitate.

In-person consent script: > "I'd like to connect you with [your org] for [need]. To do that, I'll share your name, contact info, and the reason for the referral so they can reach out. You can say no, and it won't affect anything you get here. Is it okay if I share this with them?"

Phone/SMS consent script: > "Before I send this over, I need your okay to share your contact details with [your org]. They'll call you within [X] business days. Do I have your permission? ... Thanks — I'm noting today's date and that you agreed."

Hesitation fallback: > "No pressure. I can give you their number instead, and you can reach out when you're ready. Would that work better?"

Tell partners to log consent as: who obtained it, date, method (verbal/written/SMS), and whether the client wanted a warm handoff or a direct number. For anything touching phone or text contact, pair this with the detail in your SMS and phone consent approach so the partner's documentation survives an audit.

3. The dry-run referral test

This is the part almost nobody does, and it's the highest-value piece in the whole packet.

Before the partner sends a single real client, they send one fake referral through the complete pipeline. You use a test client — "Test Client Alpha," a clearly fake DOB, a phone number that rings to your own desk. The partner fills out the actual form, obtains "consent" using the script, and routes it exactly how they would in production.

1. 1
   The referral form emails to an address that's an alias for someone who left.
2. 2
   The partner's staff can't find your "risk flag" field because their system renames it something different.
3. 3
   The consent date field accepts free text, so three staff members format it three different ways.
4. 4
   The "direct line" turns out to be the main switchboard with a four-minute hold.
5. 5
   Nobody on your side knows who's supposed to acknowledge receipt, so the test referral sits for two days.

Every one of those is cheap to fix during a dry run and expensive to discover with a real client in crisis.

“

Run the first dry run with the staff who will actually send referrals, not just leadership.

4. Acceptance criteria (what "referral-ready" actually means)

Vague onboarding never ends because "ready" is never defined. Write it down as a pass/fail list. A partner is referral-ready when all of these are true:

1. 1
   - [ ] Partner sent at least 2 dry-run referrals with 100% required fields complete
2. 2
   - [ ] Consent documented correctly (who/date/method) on both dry runs
3. 3
   - [ ] Referral reached the correct intake queue, not a personal inbox
4. 4
   - [ ] Receipt acknowledged by your side within the agreed window (e.g., 1 business day)
5. 5
   - [ ] Partner staff can name who to contact when something bounces
6. 6
   - [ ] At least 2 of the partner's frontline staff — not just the director — completed a dry run
7. 7
   - [ ] Urgent/risk-flagged test routed faster than a routine one

If any box is unchecked at day 30, the partner isn't "failed" — they're "not live yet," and you extend. That framing keeps it operational instead of personal.

5. Manager's dry-run checklist

The person running onboarding needs their own one-pager so quality doesn't depend on their memory. Hand the onboarding manager this:

1. 1
   Kickoff (Day 1–2)

   Deliver the packet. Walk the required-fields sheet live. Confirm which partner staff will send referrals — get names.

2. 2
   First dry run (Day 5–10)

   Receive the fake referral. Time how long acknowledgment took. Log every field that was blank or malformed.

3. 3
   Debrief (Day 10)

   Send the partner a short list of what broke. No lecture — just the list and the fix.

4. 4
   Second dry run (Day 15–20)

   Different staff member if possible. Confirm fixes held.

5. 5
   Acceptance review (Day 25–30)

   Run the checklist. Mark ready / not-yet-ready.

The manager's job throughout is to watch the seams — the handoff points between the partner's system and yours — because that's where referrals rot.

A simple workflow for the dry-run test

Here's how the test referral actually moves, start to finish:

Partner's frontline staff opens the real referral form → fills every required field using Test Client Alpha → reads the consent script aloud and logs consent (who/date/method) → submits via the normal channel (form, portal, secure email) → referral lands in your intake queue → your intake worker acknowledges receipt and starts a stopwatch note → worker checks each required field against the sheet → any gap gets logged and returned with a one-line reason → partner corrects → re-submits → clean pass recorded.

The whole loop should take a small amount of active work, spread across a day or two. If it takes a week, you've just learned exactly how a real referral would have gone — which is the point.

The 30-day check-in agenda (built around reliability)

The final check-in isn't a "how's it going" conversation. It's a 30-minute review with a fixed agenda, all pointed at whether referrals will arrive clean once things go live.

30-day check-in agenda:

1. 1
   Dry-run scorecard review (10 min)

   How many test referrals, how many required fields complete, average acknowledgment time.

2. 2
   Breakage log walkthrough (8 min)

   Every failure found, whether it's fixed, who owns the open ones.

3. 3
   Staff coverage check (5 min)

   Which partner staff are trained and have sent a successful test. Single-person dependency is a red flag.

4. 4
   Consent spot-check (4 min)

   Pull one dry-run consent record. Is it complete and audit-ready?

5. 5
   Go-live decision (3 min)

   Ready, extend, or escalate — using the acceptance criteria, not gut feel.

Once a partner goes live, roll them into whatever ongoing referral feedback loop and scorecard routine you already run, so quality doesn't quietly decay after month one. Onboarding gets them to clean. The feedback loop keeps them there.

A real scenario

A mid-size family-services agency took on four new referral partners in one quarter — a shelter, a clinic, a school district liaison, and a food-security nonprofit. Before using a structured pack, roughly 4 in 10 incoming referrals from new partners were missing consent or a working phone number, and intake was spending somewhere around 6–8 hours a week chasing clarifications.

They ran this 30-day packet with all four. The dry runs surfaced predictable breakage: the clinic's form was emailing a departed staffer, and the school liaison had no risk-flag field at all. Both issues were fixed in week two.

By the end of 30 days, three of the four partners were live and sending referrals with complete required fields close to 90% of the time. The fourth — the food-security nonprofit — didn't pass; their single referring staffer went on leave and nobody else had done a dry run. That "not-yet-ready" call was itself a win, because it caught a single-person dependency before a real client fell through it. Time spent chasing new-partner referrals dropped to a couple of hours a week.

The numbers matter less than the mechanism: the breakage was found on fake clients, not real ones.

When this packet makes sense — and when it's overkill

Use it when:

1. 1
   you're onboarding a partner you don't have a long track record with
2. 2
   when referrals involve consent and risk flags
3. 3
   or when past partners have sent you incomplete referrals and you're tired of cleaning them up.

It's overkill when:

1. 1
   you and the partner already share a case-management system and referrals flow through a validated integration with enforced required fields. In that case the system is doing the policing; a full dry-run packet is redundant.

Who should skip it:

1. 1
   very occasional, one-off referrals between two workers who know each other well. Building a 30-day runway for a partner who'll send you two referrals a year is wasted effort. Save the structure for partners who'll become a real pipeline.

Save the structure for partners who'll become a real pipeline.

Where software quietly helps

None of this requires software. It works on paper and in a shared drive. But the parts that break most — required-field enforcement, consent logging, acknowledgment timing — are exactly the parts that an operational platform can make automatic. When the referral form won't submit until required fields are filled, when consent is captured as structured data instead of free text, and when acknowledgment timers run without anyone managing them manually, the dry run stops surfacing the same five failures every time.

The packet is what you hand the partner. The point is to make referral reliability a tested outcome instead of a hopeful one — so by day 30, a new partner isn't promising to send you good referrals. They've already proven they can.

The packet is what you hand the partner. The point is to make referral reliability a tested outcome instead of a hopeful one — so by day 30, a new partner isn't promising to send you good referrals. They've already proven they can.