customer-project-plan

name

customer-project-plan

description

Draft a project plan for an Orderful customer onboarding — typically for a specific trading partner connection (e.g., Day Dream onboarding KeHE). Use when a user asks to 'build a project plan for [customer]', 'draft an onboarding plan for [customer] with [partner]', 'create a project plan for [customer] and [partner]', 'what's our plan for [customer]'s [partner] onboarding', or 'I need a plan and target dates for [customer]'. Produces an event-triggered three-phase plan (Pre-stage, Contract and Testing, Cutover) with explicit exit-criteria checklists per phase, an 'Already done' table that builds reader confidence, an 'In flight' table for active work, and a 'What we own this week' assignments table. Phases anchor to commercial gates (commercials close, contract sign, public launch) rather than fixed calendar dates. Internal and customer-facing variants are produced separately when both are needed — never combined.

Customer Project Plan

What this skill does

Drafts a project plan for an Orderful customer's onboarding to a trading partner. The plan is event-triggered, has three phases with explicit exit criteria, and explicitly distinguishes internal-team consumption from customer-facing consumption. Built from the Day Dream <> KeHE plan iteration (May 2026) — that's the canonical reference example.

When this fires

Use whenever the project needs a structured plan. Typical triggers:

• "Build a project plan for [customer]"
• "Draft an onboarding plan for [customer] with [partner]"
• "Create a project plan for [customer] and [partner]"
• "What's our plan for [customer]'s [partner] onboarding"
• "I need a plan and target dates for [customer]"
• "Status doc for [customer]"

Don't fire for:

• One-off status updates (use slack-project-update)
• Kickoff prep docs (use kickoff-prep)
• AE handoff intake (use handoff-intake)

This skill is specifically for project plans that span multiple weeks and need explicit phase structure.

Inputs to gather

1. Customer — name, Orderful org ID, onboarding stage. If an onboarding profile already exists (<customer>-onboarding-profile.md), read it.
2. Trading partner(s) in scope — the specific partner(s) the customer is onboarding for. If a TP playbook or AOC profile exists, read it.
3. Audience — internal team only, customer-facing only, or both. If both, produce two documents.
4. Status of current work — what's done, what's in flight. Read the project Slack channel, recent emails, and any existing project artifacts. The "Already done" table needs to be accurate or the plan loses credibility on first read.
5. Known gates — which commercial events drive timing (customer's contract with partner, customer's product launch, regulatory deadlines, etc.).

Canonical structure (always use this)

Use this exact section order. Every section has a job.

# {Customer} <> Orderful — {Partner} Onboarding Project Plan

**Updated:** {date} · **Owners:** {names + roles}

## How the plan is structured

Three phases, gated by event triggers rather than fixed dates. Each phase has its own definition-of-done. We don't move to the next phase until the current one's exit criteria are met.

**At a glance:**

| Phase | Duration | Trigger to start |
|---|---|---|
| 1 — {phase 1 short title} | {duration} | {trigger} |
| 2 — {phase 2 short title} | {duration} | {trigger} |
| 3 — {phase 3 short title} | {duration} | {trigger} |

## Phase 1 — {short title}

**Trigger to start:** {event}
**Trigger to exit:** {event}
**Duration:** {duration}

### Already done
| Item | Owner | Status |
|---|---|---|
... (only items genuinely complete; this table builds credibility)

### In flight / next 1-3 days
| Item | Owner | Note |
|---|---|---|
... (active work, with note column for context)

### Phase 1 exit criteria
- [ ] {criterion 1}
- [ ] {criterion 2}
... (checkbox list — phase is done when all tick)

## Phase 2 — {short title}

**Trigger to start:** {event}
**Trigger to exit:** {event}
**Duration:** {duration}

### What happens
{1-2 paragraphs explaining the phase}

### Sequence
1. {numbered steps for clarity}
2. ...

### Phase 2 exit criteria
- [ ] ...

## Phase 3 — {short title}

**Trigger to start:** {event}
**Trigger to exit:** {event}
**Duration:** {duration}

### Sequence
1. ...

### Phase 3 exit criteria
- [ ] ...

## What we own this week

| Owner | This week |
|---|---|
| {Name} | {tasks} |

That's the whole template. No "Risks & gates" standalone section — risks become exit criteria. No "Targeted dates" table — durations are in the "At a glance" table. No "Sources" section — link inline where relevant.

Phase design principles

Phase 1 — Setup

• Purpose: Get the partnership and the customer's integration both built and ready. Two sub-phases run in parallel: 1a configures the TP in Orderful (profile, trade request, relationships), 1b is the customer's integration build (with our help). Both gate on the same external-input set so the customer sees them as one phase.
• Duration: ~2 weeks for integration customers; shorter for connector customers (no build phase).
• Trigger to exit: TP partnership configured AND customer integration consumes a test transaction round-trip.
• Must include: "Already done" table + Phase 1a section + Phase 1b section (when applicable) + "What we need from you" (≤3 bullets).

Phase 2 — Testing & TP certification

• Purpose: Round-trip the wire flow in sandbox with real prior envelopes, iterate on validation errors, get the partner's production cert.
• Duration: typically ~1 week for carrier-side flows, 9 days for Walmart retail, varies by TP.
• Trigger to start: Phase 1 setup complete (both 1a and 1b).
• Trigger to exit: Partner certifies the partnership for production.
• Must include: "What happens" paragraph + "Done when" exit criteria checklist.

Phase 3 — Cutover & monitor

• Purpose: Flip TEST → LIVE, watch first prod transactions, transition to CS.
• Duration: 2 weeks for integration customers; 30 days for connector customers (NetSuite SuiteApp / Workato — they cut over slower and need more monitor time).
• Trigger to start: Partner cert + agreed cutover slot.
• Trigger to exit: N consecutive clean days (2 weeks or 30 days per above).
• Must include: "What happens" paragraph + "Done when" exit criteria checklist.

Internal vs. customer-facing — separate documents

Do not try to make one document serve both audiences. Two documents.

Internal version

Includes:

• Specific transaction IDs, partnership IDs, AOC issue numbers
• Comparable customer references for context ("matches Olipop's setup")
• Named internal owners (Isaiah, Ashwath, Kelly)
• Acknowledgment of known gotchas pulled from other customers' onboardings
• SFDC hygiene items, parking-lot items
• Slack draft references
• "What we own this week" with individual names

Customer-facing version

Same phase structure as internal. Apply these strict rules — they are non-negotiable:

Strip from customer-facing:

• All transaction IDs, partnership IDs, internal ticket numbers, ediAccount IDs.
• All references to other Orderful customers (Hirschbach, Toro, Meyer, etc. — the customer doesn't care that another carrier already does this).
• Internal Orderful operational details (who files what, internal Slack channels, AOC profiles, MCP tokens).
• AM checklist items (contract clause confirmations, API key issuance status, admin invite grants, internal write-permission checks). These stay internal-only.
• Tactical "On our side, in flight" sections. Customer doesn't care about our internal todo items.
• Meta items in the "What's already done" table — project channel established, project plan prepared, etc. Only items that move the customer's confidence stay in.
• Internal-only jargon (translate "ediAccount" → "your EDI account", "trade request" → "set up the connection", "wire data" → "actual transactions").
• "What we own this week" (internal-only).
• Bottom summary tables that duplicate the in-phase "What we need from you" bullets.

Customer-facing structural rules:

• "What's already done" table in Phase 1: load-bearing items only. Contract signed, account live, TP-side research findings, program identification. 4–6 rows max.
• "What we need from you" in Phase 1: exactly 3 bullets. Simple and light. No long parentheticals, no internal-ambiguity caveats baked in (if a question has internal nuance like an SCAC variant ambiguity, simplify externally and resolve internally).
• Phase 1a / Phase 1b sub-phase pattern for integration customers: 1a = TP setup in Orderful, 1b = customer's integration build in parallel.
• Phase 3 = 2 weeks of monitor for integration customers (not 30 days — that's the connector default).
• Drop any "What we own this week" or "What we own" summary tables — the Phase 1 "What we need from you" bullets cover the customer-side asks.

The reference exemplar for this shape lives at references/exemplar-customer-facing-plan.md (TMSEZ — Sunburst → Walmart, 2026-05-21). Read it before drafting a new customer-facing plan.

Anti-patterns to avoid

• Fixed calendar dates. "Phase 2 starts June 1" creates a fiction we don't control. Use event triggers ("Phase 2 starts when KeHE commercials close").
• Risks section. If something's a risk, it belongs in the exit criteria of the phase it threatens — not in a separate risks section that everyone ignores.
• Stretch goals based on partial info. "Hit X by July 1" — if we don't fully understand X, drop it. The KeHE Compliance Program was cut from the Day Dream plan for exactly this reason.
• Trying to combine internal + customer-facing. They have different audiences, different language, different sensitivities. Two documents.
• Padding "Already done" with aspirational items. Only put items genuinely complete in the Already done table. If it's in flight, it goes in the In flight table. If it's not started, it goes in exit criteria. The Already done table is the credibility anchor; padding it breaks trust.
• Owners as roles, not names. "Implementation team" doesn't ping anyone. "Isaiah" does.
• Sources section. Link inline if a specific item needs a source. A dedicated Sources section reads as bibliography filler.
• Forgetting the "What we own this week" table. Without it, readers don't know what to do tomorrow. This is the highest-leverage section for driving action. (Internal version only — customer-facing uses "What we need from you" inside Phase 1.)
• Including AM checklist items in the customer-facing plan. Contract clause confirmations, API key issuance status, admin grants — these belong in the internal plan only. The customer doesn't see our internal todo list.
• "What's already done" inflated with meta items. Project channel established, plan prepared, intake complete — these don't move the customer's confidence. Only load-bearing milestones go in this table (contract signed, account provisioned, TP-side findings, program identification).
• Phase 3 defaulting to 30 days. That's the connector pattern (NetSuite SuiteApp customers). Integration customers (custom API/SFTP builds, TMS platforms) cut over and stabilize in 2 weeks.

Iteration patterns (from real use)

The Day Dream <> KeHE plan went through 4 drafts before landing. Patterns to expect:

1. Draft 1: too long. Will include risks section, sources, stretch goals, targeted-dates table, multiple paragraphs of context. ~10 sections.
2. Draft 2: too sparse. Will overcorrect into a single-table plan that loses the phase structure.
3. Draft 3: customer-facing-only. Will lose internal-team-actionable detail.
4. Draft 4: works. Keeps phase structure with exit criteria, adds back the "Already done" / "In flight" tables, drops Risks + Sources + Stretch.

If the first attempt feels right at 3 sections, suspect it's too sparse. If it has more than 7 top-level sections, suspect bloat. Target: How structured + 3 phases + What we own this week = 5 sections.

Final sanity check before sharing

• Are phases anchored to event triggers, not calendar dates?
• Does each phase have an exit-criteria checklist?
• Is the "Already done" table accurate? (No aspirational items.)
• Are owners named, not roled?
• Is internal vs. customer-facing the right shape for the audience?
• Did I cut things we don't fully understand (compliance programs, regulatory items, partner quirks we haven't researched)?
• Is there a "What we own this week" or "What we need from you" table at the bottom?
• Is the total length ≤ 1.5