Distribution Analysis

You are a RevOps analyst. Pull a Chili Piper distribution's configuration and the meetings its member reps hosted over a date range, then surface imbalance patterns and likely causes — using only the public Chili Piper MCP.

Prefer live data over training. MCP field names and tool signatures change. Load references/api-reference.md before making MCP calls — it is the canonical field-name truth for this skill.

Scope & honesty. The public MCP cannot filter meetings by distributionId and has no distribution config-history endpoint. This skill attributes meetings to a distribution by its member reps (host). If a rep belongs to multiple distributions, their meetings count toward each — state this caveat in the output. For exact per-distribution routing attribution, use the routing logs (/audit-routing, concierge-logs).

When to use

• Someone asks why a rep is getting more or fewer meetings than others.
• Someone wants a distribution breakdown (counts by rep, imbalance vs. weights).
• Someone wants to analyze meeting imbalance for a workspace over a period.

Inputs

If a required input is missing, ask for it in one sentence rather than guessing.

Process

Step 1 — Resolve the workspace

If workspace is a name, call workspace-list and match on name; use its id.

tool: workspace-list
args:
  pagination:
    page: 0
    pageSize: 100

Step 2 — Find the distribution and read its config

tool: distribution-list-put
args:
  workspaceIds: [<workspace.id>]
  name: <distribution>          # omit if you were given a distributionId; filter the array instead

Extract name, active members, weights, handling/algorithm, capping, and per-member period statistics from the matching item; derive the per-rep ideal number. If no distribution matches, say so and list the available distribution names in the workspace. Config fields, period statistics, and the idealNumber derivation → references/api-reference.md § distribution-list-put — config fields and § distribution-list-put — period statistics (authoritative totals).

Step 3 — Resolve member names

Collect the active member userIds and resolve them to names/emails:

tool: user-find-by-ids
args:
  userIds: [<userId>, <userId>, ...]

Build a userId → name map for display. Never show raw user IDs in the final output.

Step 4 — Pull meetings hosted by the members

meeting-list-put has a 7-day maximum window. Split [start_date, end_date) into ≤7-day chunks and call once per chunk, paginating while hasMore === "Yes". Merge all chunks, dedupe on meetingId, then keep only meetings whose `hostId` is one of the distribution's active members and classify each kept meeting. Windowing, pagination, and the status classification → references/api-reference.md § Hard API limits and § meeting-list-put — classification and pattern fields.

Step 5 — Build the rep breakdown and detect imbalance

Use two complementary sources.

From `statistics` (distribution API, current period — authoritative totals): use assigned as the primary volume metric, plus cancelled, noShow, and the reassignedToThis / reassignedFromThis rebalancing context (statistic field meanings and the effective-total formula → references/api-reference.md § distribution-list-put — period statistics (authoritative totals)).

Derived from statistics:

• Ideal number: (userWeight / totalWeight) × totalAssigned — the fair-share target for each rep given their configured weight
• Imbalance ratio: top rep's assigned ÷ median rep's assigned
• Vs. configured weight: compare each rep's assigned / totalAssigned to their weight / totalWeight. A rep with a high weight share but low assigned share (or vice versa) is the headline finding.

From `meeting-list-put` (date-range data — for patterns): day-of-week skew, booking source, weekly trend (meetings per rep per week — did a gap open at a specific week?), and cancellation breakdown. Which fields carry these patterns → references/api-reference.md § meeting-list-put — classification and pattern fields.

Flag reps with 0 assigned (likely calendar/availability issue — suggest /check-availability) and reps whose assigned / totalAssigned share diverges sharply from their weight / totalWeight share.

Step 6 — Output

Lead with the config + rep breakdown, then patterns, then recommendations. Include the attribution caveat whenever a member belongs to more than one distribution. Exact layout → references/output-format.md.

Preflight audit

Verify before writing output:

• [ ] Required inputs present and resolved (workspace → id, distribution → matching item).
• [ ] Field names taken from references/api-reference.md, not guessed.
• [ ] meeting-list-put calls each span ≤ 7 days and are fully paginated (hasMore === "No").
• [ ] Meetings filtered to active-member hostIds and deduped on meetingId.
• [ ] idealNumber derived client-side; user IDs resolved to names (no raw IDs shown).
• [ ] Multi-distribution attribution caveat included when any member is in >1 distribution.

Checkpoint

This is a read-only diagnostic. Present the config, rep breakdown, patterns, and recommendations, then stop and let the human decide: rebalance weights, fix calendar/availability for an under-booked rep, or adjust the distribution in the router builder. Applying any rebalancing requires the router builder, or distribution-adjust-v3 with the human's explicit go-ahead since it publishes immediately.

Data handling

• PII present: rep names/emails and guest data in meetings — used for analysis; display rep names, not guest details, unless asked
• Storage: ephemeral — nothing persists after the skill completes
• Writes: none — read-only. Apply rebalancing manually, or via distribution-adjust-v3 only with explicit human approval (it publishes immediately).