partner-list-intake

name	partner-list-intake
description	This skill should be used when an Orderful customer has provided their list of trading partners (usually as a spreadsheet, email body, or screenshot) and the Implementation team needs to normalize it into something Orderful can act on. Triggers on: "normalize the partner list for [customer]", "process the partner spreadsheet", "classify [customer]'s partners", "the customer sent their partner list", "intake the partner list", "ingest [customer] partners", "I got the partner list, what now". Produces a normalized .xlsx classifying each partner by Orderful network status, EDI vendor, transaction scope, and priority — ready to feed into migration-plan.
version	0.1.0

Partner List Intake

Take whatever the customer sent — messy spreadsheet, PDF, email body — and produce a clean, classified partner list ready for migration planning.

When this fires

The kickoff is done. The customer has sent their trading partner list (or you finally extracted it from them). It's almost never clean: typos, missing transactions, "Walmart" and "Wal-Mart" as separate rows, no identifying codes, mystery acronyms in column headers. This skill makes it usable.

Inputs to gather

• The partner list itself. If the user attached a file, read it. If the user pasted text, read that. If they pointed at an email, fetch the email body and any attachments. If they pointed at a Slack thread, read it. Don't proceed without source data.
• Onboarding profile. Read <customer-slug>-onboarding-profile.md. Note the in-scope transactions and any partner-specific commitments from the AE handoff.
• Orderful org context. If the customer has an Orderful org, fetch get_account_context for it. You'll need the org ID and ISA ID later to look up partnerships.

Step 1 — Extract rows

Pull every row from the source and normalize to these columns:

• partner_name (raw, as the customer typed it)
• partner_name_normalized (best-guess canonical name, e.g. "Wal-Mart" → "Walmart")
• transactions (e.g. "850, 855, 856, 810" — parse aggressively, accept any reasonable format)
• direction (inbound / outbound / both — infer from context if not stated)
• volume_estimate (monthly volume if provided, else blank)
• current_vendor (their existing EDI vendor for this partner — Cleo, SPS, OpenText, TIE, etc.)
• notes (anything the customer said about this partner — special requirements, contacts, etc.)

If a column is missing in the source, leave it blank — don't guess unless guessing is obvious (e.g. retail partner with 850 in scope → direction is almost certainly inbound).

Step 2 — Classify each partner

For every partner, run these lookups in parallel:

In-network check — call search_organizations against Orderful with the normalized name. Classify:

• in_network — Orderful org exists for this partner
• out_of_network — no Orderful org
• ambiguous — multiple matches, needs human review

EDI vendor classification — based on the partner name and known Orderful network knowledge:

• retailer_direct (Walmart, Target, Home Depot, Lowe's, etc. — partner runs their own EDI)
• sps_managed (partner uses SPS Commerce as their EDI gateway)
• van_partner (partner is on a VAN — Cleo, OpenText, TIE Kinetix, etc.)
• as2_capable (partner connects via AS2)
• unknown (can't determine without contacting them)

Use the partner-engagement-guide skill's reference data if available — it has the canonical answers for major partners.

Priority tier — based on volume, transaction count, and AE-flagged criticality:

• tier_1 — top 20% by volume, OR flagged as critical in the handoff doc
• tier_2 — standard
• tier_3 — long tail, low-volume, can wait

Step 3 — Output

Use the xlsx skill to produce <customer-slug>-partner-list.xlsx. Three sheets:

Sheet 1 — Classified Partners All columns from Step 1 plus: network_status, vendor_classification, priority_tier, orderful_org_id (if in-network), notes_for_implementation.

Conditional formatting:

• Tier 1 rows: light orange fill
• ambiguous matches: yellow fill, requires human review
• unknown vendor classification: light red fill

Sheet 2 — Anomalies Rows that need human intervention before this list can be acted on:

• Duplicate partner names that look like the same company
• Partners with no transactions specified
• Partners flagged ambiguous from the network lookup
• Partners the AE promised but that aren't in this list
• Partners in this list that weren't in the AE's promised scope

Sheet 3 — Source Verbatim copy of what the customer sent, so you can always trace back.

Rules

• Don't silently drop rows. If a row looks like junk (empty, header row repeated, "TBD"), move it to Anomalies — don't delete it.
• Don't fake the network check. If the org isn't in Orderful, mark it out_of_network and move on. Don't invent IDs.
• Cross-check against the handoff. If the AE promised "we'll onboard 47 partners" and the customer sent 31, that's an Anomaly worth flagging.
• Preserve the customer's terminology in the raw column. When the AM emails the customer back to ask questions, they need to reference what the customer wrote, not your cleaned-up version.

After saving, output a 4-line summary in chat: total partners, breakdown by network status, count of anomalies needing review, and a link to the workbook. Then suggest: "Next step — once you've resolved anomalies, run migration-plan to build the execution plan."