Skip to main content

Announcing our $20m Series A from GV (Google Ventures) and Workday Ventures Read More

Max Strivens Max Strivens · · 8 min read
How I Built a Customer Support Dashboard in 2 Days Using StackOne MCP

How I Built a Customer Support Dashboard in 2 Days Using StackOne MCP

Table of Contents

Using Claude Code and MCP Tools to Build an Internal Triage System


As a solutions engineer at StackOne, I spend a significant portion of my time supporting customers alongside deeper technical work. The challenge has always been managing the context switching between responsive customer support and tracking these tasks, alongside focused development - two modes of working that fundamentally conflict with each other.

This post covers how I used Claude Code with MCP tools to build an internal dashboard that automates customer issue triage, generates investigation prompts for codebase analysis, drafts customer responses, and extracts action items from meeting transcripts.


The Problem with Slack-Driven Support

The fundamental issue with using Slack as a support channel is that it treats all messages equally. Opening Slack first thing in the morning presents a wall of notifications with no indication of relative priority - an urgent customer issue sits next to a random feature request, and distinguishing between them requires reading everything.

This creates an uncomfortable trade-off between responsiveness and focus. Either Slack notifications stay enabled (constant interruptions that destroy deep work) or they get disabled (risking delayed responses to genuinely urgent issues). Neither option is satisfactory.

We use Pylon for customer issue tracking, which provides better structure than raw Slack threads, but it’s optimised for tracking issues through to completion rather than triaging what needs immediate attention.

What I actually needed was a support triage layer - something that would surface urgent issues immediately, let me batch-handle routine questions, and provide enough context to respond quickly without switching between multiple tools.


Building a Support Dashboard with MCP Tools

StackDash is a single-page dashboard that:

  • Receives issues via webhook
  • Runs them through Claude for triage and prioritisation
  • Presents them in a simple interface organised by priority
  • Generates investigation prompts for Claude Code
  • Drafts customer responses following our communication style
  • Imports action items from Fireflies meeting transcripts

StackDash architecture diagram showing Pylon and Fireflies connecting through StackOne MCP to Cloudflare Workers, Claude, and a React dashboard, producing triaged issues, investigation prompts, draft responses, and meeting todos

Tech stack: React, Hono (Cloudflare Workers), Claude, StackOne MCP, Cloudflare KV


Where Claude Code Hit a Wall

Building the core application was remarkably fast. Claude Code handled the React components, the Hono API routes, the Cloudflare Workers configuration, and the Claude integration for triage logic without much friction.

The friction appeared when connecting external services. I needed data from Pylon (customer issues, message threads, account information) and Fireflies (meeting transcripts, action items). This is where agentic development typically hits a wall - the agent needs to interact with external APIs, but those APIs have their own authentication flows, data structures, rate limits, and quirks that aren’t immediately apparent from documentation alone.

This is where StackOne’s MCP server changed the development dynamic entirely.


How StackOne’s MCP Server Unblocked the Build

StackOne provides MCP servers that expose platform integrations as standardised tools — ready-made MCP tools that Claude Code can call directly. If you haven’t encountered MCP (Model Context Protocol) before, it’s an open standard for giving AI models access to external tools and data. StackOne handles the underlying API complexity while exposing clean, consistent tool interfaces.

The practical benefit was twofold:

  • No dead ends on integrations. Instead of having to build MCP tools myself, I could immediately connect and continue building.
  • Pattern consistency across integrations. Claude Code could apply patterns learned from one integration directly to another.
// Same pattern for both Pylon and Fireflies
const issueDetails = await mcpClient.callTool('pylon_get_issue', { id: issueId });
const messages = await mcpClient.callTool('pylon_get_issue_messages', { issue_id: issueId });
const transcripts = await mcpClient.callTool('fireflies_list_transcripts', { fromDate, limit: 10 });

MCP-Powered Customer Issue Triage

When a new issue arrives via Pylon webhook, the pipeline:

  1. Validates the webhook signature and checks for duplicates
  2. Enriches the issue by fetching full details, account info, and assignee data via MCP
  3. Sends the enriched issue to Claude with a triage prompt

Priority classification combines keyword analysis with customer context weighting:

  • High: urgent, critical, down, broken, security, outage, production
  • Medium: slow, error, not working, issue, problem, bug
  • Low: how-to questions, feature requests, documentation queries

Customer tier multipliers:

StackDash dashboard with three columns: customer issues sorted by priority with Generate Prompt and Draft Response buttons, a to-do list with pending tasks, and dashboard stats showing total issues across medium and low priority


Investigation Prompts for Claude Code

This is the feature I use most. Clicking generate produces a structured prompt containing:

  • Issue details (title, customer, account, tags)
  • Cleaned issue description
  • Full message thread from Pylon
  • Triage summary and investigation outline
  • A task instruction for Claude Code
## Issue: Sync failing for large datasets
Customer: Acme Corp (Enterprise)
Account: acme-corp-prod
Tags: sync, performance, enterprise

### Description
[HTML-stripped issue description]

### Message Thread
[Complete conversation history from Pylon]

### Triage Summary
Data sync operations are timing out when processing datasets exceeding 10,000 records.
Customer reports this started occurring after their data volume increased last month.

### Investigation Outline
1. Check sync service timeout configuration in worker settings
2. Review batch processing logic for large dataset handling
3. Examine database query performance for bulk operations
4. Check for memory constraints in the sync worker process
5. Review recent changes to sync-related code paths

### Task
Investigate this issue in the codebase. Identify the root cause and suggest fixes.

Pasting this into Claude Code provides targeted analysis rather than starting the investigation from scratch each time.

StackDash issue detail view showing a generated investigation prompt with issue title, customer details, and structured markdown ready to paste into Claude Code


AI-Drafted Customer Responses

Response generation follows a strict style guide encoded in the system prompt. Core principles:

  • BLUF - Bottom Line Up Front
  • Concise - typically 2-5 sentences
  • No problem repetition - don’t restate what the customer already told you
  • Specific next steps - always

The prompt engineering here took more iteration than the actual code - getting responses that sound like they came from the team rather than generic AI output requires real examples and structural constraints.


Importing Meeting Actions from Fireflies

Fireflies records and transcribes customer calls. The import flow:

  1. Fetches recent meetings filtered by date range and participant
  2. Retrieves summaries with action items via fireflies_get_meeting_summary
  3. Sends them to Claude for extraction

The extraction prompt emphasises explicit assignments only - phrases like “Max will handle the config update” qualify, but inferred assignments do not. This prevents the todo list from filling up with items that weren’t actually assigned.

Extracted actions use a sourceId format of fireflies:{transcriptId}:{action-slug} for deduplication, so re-importing meetings doesn’t create duplicates.

StackDash to-do list showing an action item imported from a Fireflies meeting transcript, with Import Meetings button and pending tasks


Deploying on Cloudflare Workers

The entire application runs on Cloudflare Workers:

  • Edge performance globally, zero cold starts
  • KV storage for key-value persistence without managing a database
  • Minimal configuration - entry point, compatibility flags, KV namespace binding
compatibility_flags = ["nodejs_compat"]

[[kv_namespaces]]
binding = "ISSUES_KV"
id = "..."

Basic authentication protects the dashboard, which is adequate for an internal tool accessed by a small team.


Two-Day Development Timeline

Day 1 - Core pipeline

  • Webhook handler with signature verification
  • MCP client integration
  • Triage logic with Claude
  • KV storage layer
  • Basic React frontend

Connecting Pylon via StackOne MCP was essentially configuration rather than implementation - no time spent reading API documentation, handling authentication flows, or figuring out data structures.

Day 2 - Automation features

  • Customer response drafting
  • Meeting action import
  • Inline todo editing
  • Error handling and polish
  • Investigation prompt generation

Adding Fireflies followed the exact same pattern as Pylon. Claude Code handled most of the implementation while I focused on architecture decisions and prompt engineering. (We’ve written more about the Fireflies + Claude Code workflow separately.)

The speed came from eliminating the integration tax. Normally, connecting two external services represents a significant chunk of a project - reading docs, handling auth, mapping data structures, dealing with rate limits. With MCP tools already built and available, that entire category of work disappeared.


Results: From Slack Chaos to Structured Triage

The dashboard now handles the daily support triage workflow effectively:

  • Issues get automatically prioritised as they arrive
  • Investigation prompts and response drafts are generated without context switching
  • Meeting actions automatically surface as todos
  • Checking the dashboard twice daily has replaced constant Slack monitoring

Potential future work: webhook-triggered Slack summaries, automatic ticket creation for high-priority issues, broader rollout to the solutions engineering team.


Build Tools First, Ask Questions Later

When building with Claude Code, the bottleneck isn’t writing application code - that moves quickly. The bottleneck is connecting to external systems, because the agent lacks the accumulated context that makes API integration tractable.

This suggests a different approach to tooling strategy: build the MCP tools first, before you necessarily know exactly how they’ll be used. The upfront investment pays off multiplicatively when you can spin up new applications without hitting the integration wall each time.

I didn’t build StackDash because I had a detailed specification in mind - I built it because the tools were there and the application became obvious once connecting things was trivial.

If you’re building internal tools that need to connect to multiple platforms, StackOne’s MCP server significantly reduces integration overhead and lets you focus on the workflow logic that actually differentiates your tool.


FAQ

MCP (Model Context Protocol) tools are standardised interfaces that let AI models interact with external systems — APIs, databases, SaaS platforms. Instead of writing custom API integration code, you connect MCP tools and the AI agent calls them directly. StackOne provides pre-built MCP tools for platforms like Pylon, Fireflies, and dozens of others.
You configure MCP servers in your Claude Code setup, and the tools become available for the agent to call during development. Claude Code can discover available tools, understand their schemas, and call them as part of building your application — the same way it reads files or runs terminal commands.
This dashboard took two days. Day one covered the core pipeline (webhooks, triage logic, storage, frontend). Day two added automation features (response drafting, meeting import, prompt generation). The main time savings came from MCP eliminating the integration work — no API docs, auth flows, or data mapping.
An MCP server exposes a set of tools that AI agents can call over a standardised protocol. StackOne's MCP server, for example, gives agents access to 50+ platform integrations (CRMs, HRIS, ticketing systems, meeting tools) through a single consistent interface. You connect once, and the agent gets access to all the tools.
Yes. MCP is an open standard — any AI model or agent framework that supports MCP can use StackOne's tools. The protocol isn't specific to Claude or Anthropic.

Built with React, Hono, Cloudflare Workers, Claude, and StackOne MCP

Put your AI agents to work

All the tools you need to build and scale AI agents integrations, with best-in-class security & privacy.