Customer Kickoff Prep

Customer Kickoff Prep Doc

Produces an internal-only .docx prep doc the AM uses live during the kickoff call. The doc is decision-focused (not discovery-focused) and bakes in Orderful's working-model expectations: 30-minute call, async-first afterward, no recurring meetings.

When to use

Trigger as soon as an AM mentions they're prepping for a kickoff with a new customer — even before they ask explicitly. The whole point is to walk into the call with the snapshot already replayed, partner data already pulled, and decisions teed up.

Workflow

1. Gather inputs (ask once, then research)

Required from the user (ask via AskUserQuestion if missing):

• Customer name — e.g., "Acme Foods"
• AE handoff doc — Google Doc link OR the customer's Salesforce opportunity ID. The handoff doc is the highest-density source; do not skip it.

Optional but useful:

• Customer's Orderful org ID (if already provisioned) — speeds up the network lookup
• Anything the user already knows that should override the handoff (e.g., "a teammate already deployed the Suite App")

If the user hasn't provided either of the required inputs, ask before researching. Do not invent a customer or speculate from a name alone.

1b. Get credentials BEFORE the kickoff (critical)

Do not wait for the kickoff call to ask for credentials. Send a credential collection email as soon as the deal closes / kickoff is scheduled. Request:

• SPS Commerce credentials (if migrating from SPS) — to pull historical transactions and item catalogs
• DSCO/Rithum credentials (if dropship) — to understand retailer connections
• NetSuite access (sandbox + production) — to install SuiteApp and analyze field usage. Ask whether the customer has a sandbox — smaller customers on lower NS tiers may be prod-only (see reference/procure-to-pay.md).
• Current EDI provider details — ISA IDs, partner list, known issues
• Flow direction — Is this Order-to-Cash (customer receives inbound POs) or Procure-to-Pay (customer sends outbound POs to suppliers)? P2P is not native to the SuiteApp and requires custom SuiteScript per transaction type. If P2P, flag immediately: (a) custom script work required, (b) ~2-4 hours per TX type, (c) who builds it (a contractor vendor, Orderful, customer). See reference/procure-to-pay.md for the full breakdown.

Why this matters (validated on Northwind Apparel 2026-05-08): By getting SPS + DSCO + NS access before the kickoff, we arrived with a pre-built partnership, confirmed the correct AAFES EDI path, and had a test 850 ready. AE feedback: "That was extremely productive and very slick!" VP Sales: "Big fan of the kickoff." Compare this to showing up and spending 30 minutes discovering basics.

If P2P is identified, two additional questions are critical at kickoff:

1. What % of POs are drop-ship vs stock? This is THE design question — it determines the entire 856 inbound implementation (Item Fulfillment vs Item Receipt, two completely different NS paths). Acme Medical was 87% drop-ship, discovered May 12 after scripts were already in flight. Ask this during kickoff, not after. See reference/procure-to-pay.md lesson #8.
2. Does the trading partner define the EDI guidelines (leader), or does the customer? This determines who owns the spec. On Orderful, the leader publishes guidelines and Orderful maps between. Don't assume traditional spec exchange is needed. See reference/procure-to-pay.md lesson #15.

Requirements baseline document pattern (validated May 2026): When a P2P or complex onboarding surfaces detailed requirements questions, use the structured requirements baseline doc format: why / what's different / the #1 design decision / status snapshot / doc-by-doc requirements / testing strategy / what we need / timeline / appendix. This pattern got a customer (Jordan, Acme Medical) to deliver detailed, implementable answers for all 7 TX types in under 12 hours. Thin questions produce thin answers; structured frameworks produce structured answers. See reference/procure-to-pay.md lessons #10-11.

Credential sharing: Use 1Password links or the platform's future secret store, not email or Zoom chat. For urgency, accept what the customer sends but flag for rotation.

2. Research in parallel

Hit these sources concurrently. Tools may be named differently in the user's MCP setup; use what's available:

• Confluence — search for "Customer Kick-Off SOP" and read the latest version. Treat the SOP as ground truth on agenda structure, follow-up SLAs, and roles. Flag any drift between SOP and this skill in your output.
• Google Drive / handoff doc — read the AE handoff in full. Pull: contact list, ERP/WMS, current EDI state, partners, document set, comms protocols, technical contacts, SI involvement, signed terms, open questions/risks the AE flagged.
• Salesforce — pull the account context, opportunity stage, ARR, signed contract, AE name, last activity. Cross-check against the handoff for inconsistencies.
• Orderful network — for each named trading partner in the handoff, run search_organizations. Capture: in-network status, ISA ID, org/EDI account ID, number of EDI accounts (multiple often means multiple programs/regions).
• Slack (if available) — quick search for the customer name in #sales and #rnd-updates to surface anything verbal that didn't make the handoff.

Skip a source only if the connector isn't available — don't skip it because the handoff "looks complete."

3. Synthesize into the doc structure

The doc has a fixed section structure — do not add or reorder sections. Variables are content within sections.

1. Title block — INTERNAL — PRE-CALL PREP / [Customer] × Orderful — Kickoff Call / one-line subtitle
2. Goal of this call — frame as decision/sequencing, not fact-finding. Always include "Three things must come out of this 30-minute call".
3. Attendees — Customer side + Orderful side, with role and what they own
4. What we already know — replay this in first 3 min (bullet list, ~6–10 items)
5. Orderful network intel — pre-pulled (table: partner, status in network, ISA/org ID, implication)
6. Agenda — 30 minutes (table: time, topic, what good looks like)
7. Decisions to lock on the call (table: decision, owner, why now)
8. Expected questions & prepared answers (table: if they ask, you say)
9. Risks to flag (verbally — don't solution) — bullet list
10. Exit criteria — don't end the call without (checklist)
11. Post-call action items (within 1 business day) — bullet list

4. Bake in Orderful's working model (always)

These principles are non-negotiable and must show up in the agenda, decisions, Q&A, exit criteria, and action items:

• 30-minute call, not 60
• Async-first afterward — NO recurring meetings on the calendar
• Same-business-day email responsiveness expected from the customer
• 30-min sync available on demand, not standing
• Escalate after >2 business days of no customer response
• SPS pricing comparison — never bring it up; redirect to time-saved if raised

If the SOP in Confluence has been updated and contradicts these principles, flag the conflict at the top of the doc with a clear note for the user.

5. Generate and validate

If a build script is available (scripts/build_prep_doc.js), use it. Otherwise, produce the doc content directly in markdown format that can be converted.

Validate:

• Section order matches the template
• All seven Orderful working-model principles appear somewhere in the doc
• No mention of weekly standups or recurring meetings
• All trading partners from the handoff appear in section 5
• The "three things" in section 2 match the actual decisions in section 7

6. Deliver

Save to /outputs/[CustomerName]_Kickoff_PrepDoc.docx (or .md if docx generation not available). Briefly summarize what changed vs. boilerplate — e.g., "Network shows Partner A in-network but Partner B missing standalone — flagged that B likely trades under A's ISA."

Tone of the doc

This is a doc the AM reads while on the call. Keep it scannable, not prosy.

• Use bullets and tables, not paragraphs
• Each Q&A answer should be ≤2 sentences — long enough to actually answer the question, short enough to glance at
• Risks should be one line each — flag the issue, not solution it
• Decisions table: prescribe a recommendation when there's a sensible default (e.g., "First partner: Partner A (recommended)"), don't just list options

The New Onboarding Model (validated May 2026)

The Northwind Apparel and Timberline Lumber onboardings proved a fundamentally different approach. Apply this model to every kickoff.

People (Old → New)

Process (Old → New)

Systems (Old → New)

Key Principle

Don't wait. Don't discover. Arrive prepared.

Get credentials early → pull historical data → pre-build partnerships → mock real transactions → walk into kickoff with a working demo, not a blank canvas. The customer's first impression should be "this is already running" not "let's talk about what we need."

Customer Communication Rules

Don't expose NetSuite internals to customers. When sending questions to customers, translate technical NS details into business language they can answer:

Learned on Northwind Apparel (May 2026): First email draft included raw NS field names. Customer wouldn't know what custbody1=1 means. Rewrite in business terms they can answer without NS expertise.

What this skill is NOT

• It does NOT generate a customer-facing kickoff deck. We've moved away from those — the kickoff is a 30-min decision call, not a presentation. If the user asks for a deck, push back: "we've stopped using kickoff decks — the prep doc is what you walk into the room with, and the working model after the call is async."
• It does NOT do customer research from scratch. If there's no AE handoff, ask the user to point you to it before proceeding. Don't fabricate.
• It does NOT replace reading the SOP. The skill bakes in current Orderful expectations, but the SOP is the source of truth — pull it every run.

Example invocation flow

1. User: "I'm running customer Acme through the kickoff SOP next week, prep me"
2. AskUserQuestion: handoff doc link (required), Orderful org ID (optional)
3. Pull SOP from Confluence, handoff from Drive, account from SFDC, partners from Orderful network — in parallel
4. Build doc content keyed on what was found
5. Write doc to /outputs/Acme_Kickoff_PrepDoc.docx
6. Reply with the link + 3-bullet summary of what's notable in the prep