Delivery Operations Platform

The home view — KPI tiles, filter pills, ticket table

Open the dashboard and the first thing you see is the state of the whole portfolio. KPI tiles up top, status filters on the left, and a paginated table with full client/PM/priority/RAG-status filtering, search, and sortable columns. State (filter + sort + tab) persists across sessions in localStorage.

Active tickets — default landing view

60 total tickets, 40 actively open, 25 with at least one SLA clock breached, 11 clients with current load. Each row shows ticket ID, summary, client, priority, status, age, PM assignment, and SLA RAG status. The colored stripe on each KPI tile reflects the metric’s health.

All tickets — including closed

Switches scope to all tickets (Open + Reopened + Closed). The same filter and sort affordances apply. Closed tickets stay searchable for post-mortems and historical client checks.

One-click filter by client

Click a client name in the sidebar (or pick from the dropdown) and the table narrows to that account. Useful for “what does Meridian look like right now?” conversations during the weekly client review.

Three SLA clocks per ticket, business-hours-aware

The SLA engine tracks three independent clocks per external ticket (First Response, First Update, Time to Resolve) against per-priority targets, with a 12-hour business-hours window (14:00–02:00 IST, Mon–Fri). Internal tickets get two clocks (no First Response — they bypass that contract). Auto-pause when state flips to awaiting_customer; auto-resume when the customer replies.

SLA-breached filter — the daily triage view

One click on “SLA Breached” narrows to tickets that have blown at least one clock. Red chips and per-clock overshoot labels (“+1.5d”, “+14h”) make the worst offenders obvious. PMs start their day here.

At-Risk filter — before it breaches

“At Risk” surfaces tickets that have used 80%+ of their SLA target but haven’t breached yet. A breach-warner DM also pings the assigned PM in Slack so they can act before the chip turns red.

Ticket drawer — AI triage + 3-clock SLA panel

Click any ticket and a side drawer slides out. Top section shows the AI-generated “What happened” summary plus a “Recommended Next Step” that Claude synthesizes from the comment thread. Below that: full metadata, three SLA clocks with per-target overshoot, and the PM assignment / ETA / action editor.

Drawer scrolled — assignment, RCA notes, csm_handled flag

Scroll the drawer down and you get the PM owner / ETA / action editor, the “PM response not required” (csm_handled) toggle for small or questionnaire-type tickets the CSM resolves without escalating, the RCA / resolution-notes thread, the related-links field, and a “Post to #ops-channel” button that drops a status update into the ticket’s Slack thread.

Per-PM, per-client, per-priority scorecard — what PMs use to track their own work

The Scorecard tab is what each PM opens to see how they’re tracking against their SLA contract. Switch the grouping between PM / Client / Priority. Switch the window between 7d / 30d / 90d / Lifetime / Custom range. Switch the workspace scope between Jira-only / Internal-only / Both combined. Tickets where the CSM handled without needing PM escalation are auto-excluded from PM accountability metrics so the numbers reflect actual PM workload — not random small things the CSM closed.

By PM — the weekly accountability view

Per PM: tickets handled, SLA breached, % First Response Met, % Resolution Met, MTTR, reopens, reopen rate. Bar charts below show open tickets per PM and per-PM First Response / Resolution pass rates side by side. Weekly snapshot runs every Thursday and posts to the team channel.

By Client — the client-health view

Same metrics, regrouped per client. Surfaces which accounts are running hot (lots of tickets, breaches piling up) vs which are quiet. Useful during QBR prep and renewal conversations.

By Priority — the SLA-contract view

Group by P0 / P1 / P2 / P3 to see how the team is performing against each priority’s SLA tier. P0 / P1 should be near-100% First Response Met; lower priorities have more headroom. Exposes whether priority calibration is honest.

Row drill-down — click a PM to see their tickets

Expand any row to see the ticket-by-ticket list that fed the numbers above. Each row links straight to the ticket drawer; the outcome chip (met / breached / in progress) matches what got counted.

Separate workspace for issues the CSM raises herself

Internal tickets are issues a CSM or QA team member spots before any customer Jira exists — routing bugs, audio quality regressions, campaign config glitches. Lives in its own workspace with its own KPI tiles, filter sidebar, table, scorecard, and analytics. Two SLA clocks (no First Response). Never auto-pauses on awaiting_customer because there is no customer in the loop.

Internal tickets — same UI, separate state

10 active internal tickets across Ironwood Collections, Cascade Community Bank, Beacon Credit Co. Each ticket carries a “raised by” field so the team can ask the original raiser for context.

Raise Internal Ticket — modal form

Click “Raise Internal Ticket” from the table header to open this modal. Client + summary + description are required; priority defaults to Medium; ETA is optional; attachments and related links supported. A “Resolved → close” toggle on each ticket closes it inline once the fix lands. State is persisted to internal_tickets.json via a Cloudflare Worker write-proxy, so no GitHub token needed at the browser.

Daily ticket flow, priority mix, time-windowed KPIs

Switch to the Analytics tab for the time-windowed view. Daily raised-vs-closed flow chart, priority distribution donut, KPI tiles for the selected window. Useful in the monthly delivery review to spot trends — is the team raising more tickets than they’re closing? Which priority is growing?

Analytics — 30-day window

60 tickets raised, 20 closed, 40 still open across the 30-day window. Average ticket age: 17 days. Priority distribution shows Medium dominating, with a smaller High and Low slice.

Analytics — 90-day view (full scroll)

Longer time horizon. Same charts, broader trend. The window switcher snaps between 7 days / 30 days / 90 days / All Time without re-fetching anything — all rendered client-side from the cached data.json.

The dashboard talks to Slack so nobody has to write a digest by hand

A Python script (build_digest.py) assembles the daily digest from the live ticket state, the script (post_digest.py) ships it to Slack via chat.postMessage, and per-ticket sub-threading means replies stay organized. The dashboard exposes a preview-before-post modal so the CS lead can sanity-check the digest before it lands in the team channel.

Daily Slack digest — preview before posting

Opens the exact message that will land in the team channel at 2 PM IST. Intro paragraph first (summary of state), then one top-level Slack message per open ticket with status, age, ETA, and SLA chip. Replies thread under each ticket. The “Post Live to Slack” button ships the digest; “Copy Markdown” copies the raw mrkdwn for pasting elsewhere.

EOD Summary — end-of-day team check-in

A second canned summary the lead can paste into the #ops channel at end of day. Shows tickets that moved status, tickets that breached an SLA, and tickets that closed in the last 24 hours. Skips the noisy stuff (filter changes, comment-only updates).

Every feature that ships in the production system

Beyond the screenshots above, here’s the full surface area. Some of these are small quality-of-life features, some are background automation, some are dashboard ergonomics — together they’re what makes the system actually save 150+ hours/month.

SLA & clock math

Ticket workflow

Scorecard & reporting

AI-assisted triage

Slack & notifications

Filters, search & UX

Automation & infrastructure

Auth & security

What it’s built with