trading-partner-playbook

name

trading-partner-playbook

description

Produce a deep-dive playbook on a specific trading partner (KeHE, Target, Kroger, etc.) by mining Confluence, Intercom, Jira, Slack, and the Orderful platform for everything Orderful institutionally knows about that partner — comm channel, ISA IDs, document types, onboarding flow, testing process, gotchas, reference customers. Use when a user asks to deep-dive a trading partner, build a TP profile, research a partner before onboarding a customer, or stop asking customers questions whose answers we already have. Triggers: 'deep dive on [partner]', 'build a playbook for [partner]', 'what do we know about [partner]', 'research [partner] before we ask the customer', 'TP playbook for [partner]', 'partner intelligence on [partner]'. Output: a structured Markdown playbook any AM, CEA, or onboarding engineer can read in 5 minutes to skip rediscovery.

Trading Partner Playbook

What this skill does

For a specific trading partner (KeHE, Target, Kroger, Wegmans, etc.), aggregate everything Orderful institutionally knows about that partner across our internal knowledge bases and produce a single structured playbook. The output saves AMs, CEAs, and onboarding engineers from asking customers to bring back intel we already have.

When this fires

Use whenever someone is about to onboard a customer to a partner Orderful has touched before, or wants to understand a partner without starting from zero. Typical triggers:

• "Deep dive on [partner]"
• "Build a playbook for [partner]"
• "What do we already know about [partner]?"
• "Research [partner] before we ask the customer for X"
• "Before we send [customer] to gather info from [partner]…"
• "TP intel for [partner]"

This skill earns its keep when the alternative is the customer being asked to surface things we could've told them ourselves (comm channel, doc types, testing process, EDI spec — all things our institutional knowledge usually answers).

Don't fire for:

• A brand-new partner Orderful has never touched (the answer will be "we don't know anything yet — go ask the customer")
• One-off transactional questions ("what's KeHE's test ISA ID?" — just look it up directly)

Inputs to gather

1. Partner name — required. Common formats: full name ("KeHE Distributors"), short name ("KeHE"), or alias ("KeHE Foods"). Search all variants.

2. Customer context (optional but useful) — if the user is researching for a specific customer onboarding, capture the customer's name. The playbook can include "What we'd ask this specific customer to bring back" tailored to what's truly unknown.

3. Depth target — quick (key facts only, ~5 min run) or thorough (every source, including individual production-error tickets, ~10–15 min run). Default to thorough unless the user says otherwise.

Sources to mine — AOC first, then everything else

Step 0 (ALWAYS first): Check Jira AOC for an existing network profile

Before mining anything else, query Jira for an existing canonical network profile in the AOC (AgentOrgContext) project. Network profiles follow the naming convention {PARTNER}_NETWORK_PROFILE.

• searchJiraIssuesUsingJql with project = AOC AND (summary ~ "{partner} NETWORK_PROFILE" OR summary ~ "{partner} PROFILE").
• If a match exists, pull the full description with getJiraIssue (markdown format).
• Read it end-to-end before going further. This is your baseline; you're looking for deltas, not building from scratch.
• If no match, note that explicitly in the output (a new profile may need to be created) and proceed to mine the other sources fresh.

The AOC profile uses a defined structure (Identity, Setup, Supported Transactions, Gotchas, Compliance & Fines, Pre-Onboarding Checklist, Key Reference Links) and a confidence-level scheme (VERIFIED / HIGH / MEDIUM / INFERRED). Mirror that structure and confidence scheme in your playbook output so the diff against AOC is mechanical and the sync-tp-network-profile skill can propagate deltas back cleanly.

Then mine the other sources to find what AOC doesn't already cover

Run these in parallel. Don't serialize.

1. Confluence

Search for partner-specific pages:

• text ~ "[Partner Name]" AND type = page
• High-value pages live in the NT (Network Team) space, especially the master partner-requirements pages (search space.key = NT AND text ~ "[partner]")
• Look for the partner in industry-specific roll-up pages (e.g., "Grocery & Food Distribution — EDI Partner Requirements" for grocery partners, "Big Box Retail" for Target/Walmart-shape partners)
• Look for QBR / EBR pages for any customer who's traded with this partner

Pull the most relevant 2–3 pages with getConfluencePage in markdown format.

2. Intercom — Help Center + conversations

• search_articles with phrase: "[partner]". If a partner-specific article exists (very common in the SUC/Network Team space), pull it with get_article — these are gold.
• search with object_type:conversations q:[partner]. The first page of results usually surfaces:
  • Recent customer-side questions about the partner ("how does X work with [partner]?")
  • Production error tickets (look for "(via SPS Commerce)" or AS2 / VAN tags in titles)
  • Onboarding form / trade request notes from automated workflows
  • Recent configuration change requests (855 mapping tweaks, N1 loop exclusions, etc.)
• For high-signal conversations, fetch with fetch (use conversation_<id> prefix). Internal admin notes contain the institutional knowledge — read past the customer-facing replies.

3. Jira

• searchJiraIssuesUsingJql with text ~ "[partner]" ORDER BY updated DESC
• Watch out — partner-name searches return high result counts. Constrain with created > "2025-01-01" and maxResults: 15 first. Surface the most recent issues only.

4. Slack

• slack_search_public_and_private for partner name in EDI contexts ("[partner] EDI", "[partner] 850", "[partner] onboarding")
• slack_search_channels to see if there's a dedicated partner channel
• Filter out noise (bot DMs, the requesting user's own past posts)

5. Orderful platform

• search_organizations for the partner name. Many large partners have multiple ediAccountIds under one organizationId (different divisions, regions, or comm channels). Capture every ISA ID and test ISA ID.
• For one or two existing partnerships, pull get_account_context to see actual comm channel naming conventions, guideline sets, and live document types.

6. Salesforce

Usually low-value for partner research (Accounts are mostly customers, not partners) but worth a quick check:

• soqlQuery SELECT Id, Name FROM Account WHERE Name LIKE '%[partner]%' — sometimes the partner is a customer too

Output structure

Save as outputs/<partner-slug>-trading-partner-playbook.md. Use this exact structure so downstream consumers (AMs, future runs, the email-draft skill) know where to look.

# <Partner> — Trading Partner Playbook

**Generated:** <date> · **Sources:** <list>

## TL;DR — what we already know
<2–4 sentence executive summary. The reader should know the comm-channel verdict, the standard document set, and whether the partner is "easy" or "has quirks" before they finish reading this section.>

## <Partner> platform footprint in Orderful
| Field | Value |
|---|---|
| Organization ID | <id> |
| EDI Accounts | <count + summary> |
| Connection model | <direct AS2 / VAN / SPS / Edict / etc.> |
| Help Center article | <link if exists> |
| Confluence reference | <link to canonical NT-space page> |

### ISA IDs in our network
<Table of ediAccountId, prod ISA, test ISA, notes. Mark which are most-active based on recent ticket evidence.>

## Connection type — answered
<One paragraph stating the default comm channel assumption and why. If multiple paths exist, surface the most-common one and note when each alternate applies.>

## Typical document type set
<Table of doc types with direction and purpose. Note which are required vs. optional. Include 997.>

## End-to-end onboarding flow
<Numbered or arrow-flow walkthrough from "customer creates trade request" to "live trading." Include auto-accept behavior, form expiration windows, contractor binding, testing prerequisites.>

## Testing contacts
<Email addresses, phone numbers, portal URLs. Call out "Do NOT use [X]" addresses if known.>

## Common gotchas (from real tickets)
<Bulleted list. Each item must reference a real ticket, ticket pattern, or doc page. Specifics matter — segment-level rules, expiring forms, ordering quirks. No generic "EDI can be tricky" filler.>

## What we actually need from the customer
<The shortest possible list of things the customer must surface that we cannot know from internal sources. Usually: their assigned vendor number, portal access confirmation, any vendor-specific compliance requirements.>

**What NOT to ask the customer to surface — we already know it:**
<List of things this playbook answered. This is the punch — it's what makes the skill worth running.>

## Other Orderful customers trading with <Partner>
<Sample list of reference customers, their state (LIVE/Testing/Setup), and which doc types they've configured. Useful for finding pre-built scenarios / guideline sets.>

## Sources
<Linked sources used to build this playbook.>

Special section if customer context was provided

If the user named a specific customer (e.g., "before we ask Day Dream to bring info from KeHE…"), add a section at the end:

## Implications for <Customer>'s situation
<Trim the "what to ask the customer" list to ONLY what's genuinely unknown for this specific customer. Cross-reference against any existing pre-kickoff email, kickoff prep doc, or onboarding profile — if those documents asked the customer to bring back things this playbook now answers, flag that explicitly so the AM can update the outbound.>

Always enumerate (don't paper over)

Two questions deserve first-class treatment in every playbook, because every multi-entity partner has answers that vary by program/division:

• Which entity to use. Large partners often have multiple Orderful EDI accounts under one organizationId (KeHE has 7, others may have 3–10). Always list every ediAccount you find with its ISA + qualifier + use case, identify the default (usually the most-active in recent tickets), and note when alternates apply.
• Which transaction-flow variant. Many partners support more than one TX flow shape (e.g. standard X12 OTC 850/855/856/810 vs. legacy grocery 875/880; or direct AS2 vs. SPS-mediated). Always identify the default for new customers AND name the alternates so the playbook reader knows when to pivot.

If either question genuinely has only one answer, say so explicitly — silence is ambiguous.

Confidence tagging — required

Every claim in the playbook must be tagged with one of: VERIFIED / HIGH / MEDIUM / INFERRED. Same scheme AOC uses, identical rubric:

• VERIFIED — from Orderful API, platform, or directly confirmed by an Orderful team member
• HIGH — from Orderful docs, Help Center, Intercom tickets with identifiable customer context, Slack with timestamp + author
• `M