/no-show-analyzer

name: no-show-analyzer
description: Analyzes Chili Piper meeting no-show patterns by trigger type, routing path, rep, or workspace using meeting-list-put and concierge-logs to surface actionable optimization opportunities
version: 0.3.8
api_note: "concierge-logs: optional page/pageSize pagination added (DISTRO-4576, max 100 per page, default 20); Step 3b and preflight updated to paginate high-volume routers; 2026-07-23: DO-5176 (edge PR #996) added assigneeIds, hostIds, guestEmail, meetingTypeIds as optional server-side filters to meeting-list-put — useful for pre-filtering by specific hosts or meeting types before grouping client-side. 2026-08-14 (CEH-11330, edge PR #1076): concierge-logs MCP response is now {items: [...]} instead of a bare top-level array — paginate until items is empty or shorter than pageSize. 2026-09-09 (CEH-11656, edge PR #1173): concierge-logs page size capped at max 100 (default 20) — pageSize: 500 replaced with pageSize: 100 throughout."
references:
  - api-reference
  - analysis-methodology
  - output-format
inputs:
  - name: date_range
    type: string
    description: "Period to analyze: 'last-7-days', 'last-30-days', or 'YYYY-MM-DD:YYYY-MM-DD'. For trigger/route breakdown, concierge-logs caps at 30 days. Meeting data can go further but loses routing context."
    required: false
    default: "last-30-days"
  - name: workspace
    type: string
    description: "Workspace name or ID to scope the analysis. Omit for org-wide."
    required: false
  - name: group_by
    type: string
    description: "Primary dimension: 'trigger' (lead source type) | 'route' (matched routing path) | 'rep' (assignee) | 'workspace'"
    required: false
    default: "trigger"
  - name: flag_threshold
    type: number
    description: "No-show rate (%) above which a segment is flagged. Default: 30."
    required: false
    default: 30
outputs:
  - name: summary
    description: Overall no-show rate and meeting volume for the period
  - name: breakdown
    description: No-show rate by the selected dimension, sorted highest to lowest
  - name: flagged_segments
    description: Segments above the threshold with root-cause hypotheses
  - name: recommended_actions
    description: Specific routing or confirmation flow changes to test
tools_required: [chili-piper-mcp]
human_decision_point: "Review flagged segments and decide which routing rule or confirmation flow change to test first"
writes_to: "Salesforce task (optional) — created by human after reviewing recommendations"

No-Show Analyzer

You are a GTM data analyst with deep knowledge of Chili Piper's meeting and routing model. Your job is to pull meeting data and routing context for a given period, calculate no-show rates, flag problem segments, and surface specific actions for the human to test.

> **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 (the tools' own descriptions are unreliable).

When to use

• You want to know where meeting no-shows concentrate (by trigger, route, rep, or workspace) for a period.
• You need root-cause hypotheses and testable actions to reduce no-show rate, not just a number.
• You're running the optimization loop: measure a baseline now, change one thing, re-measure in 30 days.

Inputs

| Input | Required | Default | What it controls | |-------|:--------:|---------|------------------| | `date_range` | — | `last-30-days` | Period to analyze: `last-7-days`, `last-30-days`, or `YYYY-MM-DD:YYYY-MM-DD`. Trigger/route breakdown caps at 30 days (concierge-logs window). | | `workspace` | — | org-wide | Workspace name or ID to scope the analysis. Omit for org-wide. | | `group_by` | — | `trigger` | Primary dimension: `trigger` \| `route` \| `rep` \| `workspace`. | | `flag_threshold` | — | `30` | No-show rate (%) above which a segment is flagged. |

Process

Step 1 — Resolve inputs and validate

Parse the user's request for `date_range`, `workspace`, `group_by`, and `flag_threshold`.

**Date range constraint check:** If the requested range exceeds 30 days AND `group_by` is `trigger` or `route`, warn the user: > "concierge-logs has a 30-day maximum window. I'll analyze the most recent 30 days for trigger/route breakdown. For longer periods, use `group_by=rep` instead."

If `workspace` is provided as a name (not ID), call `workspace-list` first to resolve it to an ID. The two windowing limits → `references/api-reference.md` § Hard API limits — two separate windows.

Step 2 — Fetch meeting data

`meeting-list-put` accepts at most a **7-day window per call**. Split the requested range into 7-day (or shorter) chunks and issue one call per chunk:

tool: meeting-list-put
args:
  start: <chunk start, ISO-8601>
  end: <chunk end, ISO-8601>
  status: ["Completed", "NoShow", "Active"]
  workspaceIds: [<resolved workspaceId>]   # include only if workspace was specified
  pagination:
    page: 0
    pageSize: 200

Results are in `response.data.list[]`. Paginate each chunk while `response.hasMore === "Yes"`, then merge and deduplicate on `meetingId`. The status filter rationale, envelope shape, `hasMore` string gotcha, and pagination → `references/api-reference.md` § Status values in `meeting-list-put` and § Hard API limits.

Classify each merged record and build the `meetingId → effective-status` map → `references/analysis-methodology.md` § Classify each merged meeting record.

Step 3 — Fetch routing context (only for `trigger` or `route` grouping)

Skip this step if `group_by=rep` — rep is available directly from `meeting-list-put` via `hostId`/`hostEmail`/`hostName` (the host name is already included, so no separate lookup is needed).

**3a. List all routers:**

tool: concierge-list-routers
args:
  workspaceId: <resolved workspace ID, or omit for all>

Use `routers[N].router.id` as the routerId, `routers[N].router.name` for display, `rout