onboarding-outreach-email

name

onboarding-outreach-email

description

Draft an outreach email to an Orderful onboarding customer — welcome notes, pre-kickoff prep, access requests, re-engagement, follow-ups. Use whenever the user asks to write, draft, or send an email to a customer who's in onboarding — pre-kickoff emails asking for system access, welcome / kickoff-prep messages, NetSuite / ERP access requests, requests for partner lists or EDI system credentials, re-engagement notes for stalled customers, or any outbound message to the customer-side stakeholders during onboarding. Also trigger on phrases like 'draft an email to [customer]', 'welcome email for [customer]', 'ask [customer] for NetSuite access', 'send the access request to [customer]', 'pre-kickoff outreach', 're-engage [customer]'. The skill verifies names and emails from Salesforce and Slack before drafting (never invents addresses), structures the email so the lede isn't buried, and saves the result as a Gmail draft with HTML formatting so bold renders properly.

Onboarding Outreach Email

When this fires

The user wants an outbound email to a customer in onboarding. The classic case: pre-kickoff outreach asking for NetSuite/ERP access, existing EDI system access, and a request to loop in the right people. Variants include re-engagement notes for stalled customers, access reminders, follow-ups, and welcome messages mid-onboarding.

This skill is for customer-facing outreach. For internal prep docs use kickoff-prep. For weekly exec updates use weekly-customer-progress-update.

Inputs to gather

Before drafting, resolve the customer and the stakeholders. Run these in parallel:

1. Salesforce — soqlQuery the Account by name. Capture: Account ID, Type (must be Customer, otherwise this isn't an onboarding email), Owner (AE or AM), primary Contact (with confirmed email). If the customer isn't in SFDC, stop and ask the user — don't guess.

2. Orderful org — search_organizations by name. Capture Org ID, ISA ID, and partnership state. Use this to ground claims in the email (e.g., "we know KeHE isn't signed up yet" should match what the partnership state shows).

3. Slack slack_search_users — look up each Orderful person who should be CC'd (AE, AM, technical driver, sender). This is the only reliable way to get their @orderful.com email — names alone won't do.

4. The onboarding profile — if <customer>-onboarding-profile.md exists in the workspace (produced by handoff-intake), read it. It has the AE's promises, contact roster, and known risks you should not contradict.

5. Recent Slack signal — search the customer name in the last 14 days. Surface anything fresh (e.g., a partner deal that fell through) so the email doesn't contradict reality.

What good looks like

The email is structured so the reader gets value from the first line. Buried ledes lose the customer.

Lead with role, not pleasantries

If we've already been working with the customer through sales (almost always true in onboarding), skip "welcome to Orderful" hyperbole. Open with role and intent:

"Hi [Customer first name] — I'm [Sender]. I'm going to help drive your [Partner] onboarding alongside [Technical driver] on our side."

Then a single sentence on who else is on the email: "[AM] (your AM) and [AE] (your AE) stay in the loop, all CC'd here."

Acknowledge reality before asking for anything

If the customer's commercial state is shaky (deal not signed, partner pulled out, stalled timeline), name it directly and reframe positively. Don't pretend it's not there.

"We know [Partner] isn't fully signed up on your side yet, and that's totally fine — we're not trying to rush the commercial piece."

The customer feels seen, defenses come down, and the rest of the email lands better.

Frame the outcome before the asks

State what "ready" looks like for them. The asks then read as the natural prerequisites, not arbitrary demands.

"Our goal is the opposite: once you've finalized commercials and your partnership with [Partner], we want [Customer] ready to trade EDI with them quickly — no scramble or weeks of catch-up integration on the back end."

Explain what the kickoff call is (briefly)

Most non-technical customers don't know what an Orderful kickoff produces. Don't make them guess.

"That's exactly what we'd walk through on our kickoff call — review the config and setup, test our assumptions together, and if everything looks right, lock a cutover date for [Partner]."

Bold each ask, numbered, with the action up front

This is the highest-leverage part of the whole pattern. Each ask is a short bolded clause that states the action — then the rationale follows in plain prose. The reader should be able to scan the bolded lines and know what to do.

Example shape:

1. Grant Orderful access to NetSuite. Could you ask [NetSuite owner] to follow this guide and grant us access: [URL]. This is what lets us configure the NetSuite ↔ Orderful connection end-to-end.

Three asks is the sweet spot. More than four and the customer skims.

Standard ask library

Most pre-kickoff outreach emails draw from these three:

Ask: NetSuite (or other ERP) access

Grant Orderful access to NetSuite. Could you ask [Named SI / NetSuite admin, or generic "your NetSuite team"] to follow this guide and grant us access: https://docs.orderful.com/docs/grant-orderful-access. This is what lets us configure the NetSuite ↔ Orderful connection end-to-end.

If the handoff doc confirms a specific person is the right owner, name them. If it doesn't, frame generically (see "Don't name specific people who may have moved" below).

Ask: Existing EDI system access

Share access to any EDI systems you're currently using. If [Customer] is touching EDI anywhere today — a VAN, an SPS Commerce / TrueCommerce / Cleo account, a retailer portal login inherited from a co-packer — please give us access so we can mirror those partnerships in Orderful and nothing gets lost. For any portal credentials, please send them in two separate emails — one with the username, one with the password — to keep things secure.

If [Customer] is new to EDI and doesn't have anything in place today, just confirm and we'll take it from there.

The two-emails-for-credentials line is non-negotiable. Customers will share creds in plain text otherwise, which is bad. Phrase it as security hygiene, not paranoia.

Ask: Loop in the technical team

Please add your NetSuite team to this thread. That way the technical setup can move in parallel with the rest of our prep.

Don't name specific people who may have moved. The handoff doc might list specific contacts by name, but those people change roles — frame generically ("your NetSuite team") so the customer adds whoever is actually owning it today.

Close with optionality

End by giving the customer a low-friction way to engage live if needed, while signalling async is fine.

"Happy to hop on a call if any of this is easier to walk through live. Otherwise, the more we can knock down now, the faster [Partner] goes live when it's commercially clear."

CC pattern

Standard CCs for onboarding outreach:

• Customer primary contact → TO line. Pull from Salesforce Contact records — the one with a confirmed email.
• AE (Account Executive) — they originated the relationship; they hear important changes.
• AM (Account Manager) — they own the relationship going forward.
• Technical driver — the CEA or onboarding engineer actually doing the work alongside the sender.
• The sender — yes, CC yourself so the thread lives in your sent + inbox.

Don't CC people whose emails you haven't verified. Pull each from Slack via slack_search_users or Salesforce User records via soqlQuery. If you can't find a confirmed address, leave them off and mention them by name in the body.

Language rules

Avoid EDI jargon when the audience is non-technical

The customer side often isn't EDI-fluent. Translate:

Avoid	Use instead
"greenfield"	"new to EDI"
"trading partner"	"retailer" or "customer" (in context)
"ISA ID / qualifier"	"your EDI account"
"guideline set"	"the spec we'll exchange documents against"
"going live"	"switching to live" or "starting to trade with [Partner]"
"scenario"	"test case"

Check the onboarding profile — it usually flags whether the customer-side primary is non-technical (a common note: "self-described non-technical"). When in doubt, default to plain English. EDI veterans don't mind plain language; EDI novices struggle with jargon.

Don't oversell

The customer signed already. You don't need to convince them Orderful is great. Keep it factual and direct. Avoid:

• "We're excited to..." (everyone's excited; it's filler)
• "World-class" / "best-in-class" (marketing speak the customer tunes out)
• "Welcome to the Orderful family" (cringe; also wrong if they've been working with us for months)

Don't make AM transitions the headline

If the AM has changed (e.g., the previous one left the company), state the new name once in the opener. Don't dedicate a paragraph to it — that signals instability. Example:

"Kelly (your AM) and Jon (your AE) stay in the loop, all CC'd here."

That's enough. The customer will notice the new name; they don't need an explanation unless they ask.

Output

Always produce two artifacts:

1. A markdown file in outputs/<customer-slug>-<purpose>-email.md — TO / CC / Subject up top, body below. This is what the user reviews and can edit.

2. A Gmail draft via create_draft. Use the htmlBody parameter (not just body) so bold renders properly. Without HTML, asterisks render as literal ** text in Gmail and the carefully bolded asks become unreadable. Provide the plain-text version in body as a fallback.

HTML rendering pattern

For each bold ask, wrap in <strong>. Each paragraph wraps in <p>. Use <a href="...">URL</a> for links so they're clickable. Example structure:

<p>Hi [Name],</p>
<p>I'm [Sender] — I'm going to help drive...</p>
<p><strong>Here's what we'd like from you to get there:</strong></p>
<p><strong>1. Grant Orderful access to NetSuite.</strong> Could you ask [Owner] to follow this guide and grant us access: <a href="https://docs.orderful.com/docs/grant-orderful-access">https://docs.orderful.com/docs/grant-orderful-access</a>. ...</p>

After creating the draft, surface the Gmail draft ID and a link to the markdown file so the user can review and edit before sending.

The full template

A complete exemplar email (the Day Dream Nutrition pre-kickoff outreach we iterated to) lives at references/exemplar-pre-kickoff-email.md. Read it when drafting a new pre-kickoff email — it shows the exact rhythm and proportions in a single concrete document.

Anti-patterns to avoid

• Listing specific people who may have moved. "Please loop in [named SI contacts]" was wrong even though the handoff doc named them. Use "your NetSuite team" instead.
• Asking for permissions instead of access. "Could you grant us NetSuite permissions?" is too generic. Link the actual guide and name the action.
• Burying credentials guidance. The two-emails-for-credentials note must be inside the relevant ask, not in a postscript. It only protects the customer if they see it before they send the credentials.
• Hallucinated email addresses. Never guess a customer's email pattern. Use what's in SFDC. For internal Orderful staff, use Slack lookup. Missing addresses are better than wrong ones.
• Markdown asterisks where HTML is needed. Gmail does not render **bold** as bold — it shows the asterisks literally. Always send via htmlBody.
• One giant paragraph of asks. Even if there's just one ask, separate it visually with the bolded lede. The reader's eye needs an anchor.
• AM-change announcements as opener. It signals instability. State the new name as a fact, move on.

Final sanity check before saving the draft

Before calling create_draft, scan the draft against these questions:

• Could the customer skim the bolded lines and know what to do? If no, the bolded ledes aren't doing their job.
• Is there any line that contradicts what's actually in Salesforce or the Orderful partnership state? (E.g., "your KeHE setup is in progress" when no KeHE partnership exists.) Fix it.
• Did I verify every CC email via Slack/SFDC? If any are guesses, drop them and mention by name instead.
• Is the customer's primary contact addressed by first name? Last-name salutations feel like cold outreach; this isn't cold outreach.
• Did I avoid jargon the recipient might not know? If the onboarding profile flagged the recipient as non-technica