Chromatic · DeAndre Harris

From customer cases to support systems

As a Senior Support Engineer at Chromatic, I work exclusively with priority enterprise customers on support cases, alongside our Solutions Engineers. Those conversations happen over Slack, email, chat, and video, and can involve anything from CI behavior and monorepos to Storybook extraction, resource loading, account access, or build limits.

I want the customer to understand what went wrong and how to move forward. When customers had allowed Chromatic through their firewalls but still couldn’t publish builds, I traced the problem to an S3 upload host our documented wildcard rule didn’t cover, then corrected the guidance.

Other investigations led me to document MCP authentication failures, including differences in how agent clients read OAuth configuration, and rework our guidance on account access, roles, SSO, and SCIM. Fixing a gap in the documentation is part of resolving the problem, especially when another customer is likely to run into it.

Owning the support platform

Our old support setup wasn’t a good fit for customer conversations in Slack. I proposed moving from Intercom to Plain and led the migration across the organization, handling authentication, data imports, cutover, and post-launch monitoring. I remain Plain’s point person and administrator.

As part of that work, I integrated Plain chat into our documentation site, with email verification before a chat begins and labels on support links to route requests to the right queue.

Plain workflow showing request filters, account and priority labels, and regional assignments — The primary workflow I configured in Plain filters requests, applies labels, and routes work by region.

Making day-to-day administration safer

A subdomain can point to several accounts, and an investigation may continue through a project, build, and story once we’ve found the right one. Gathering that context through raw GraphQL was cumbersome, particularly when Support or Solutions Engineering needed to make an administrative change.

I built Chroma in Go so the team could investigate accounts and builds and handle routine administration without sending every task to Engineering. It runs as a CLI and an MCP server, redacts personally identifiable information by default, and requires confirmation before destructive actions. I maintain it using weekly anonymous telemetry summaries in Linear, which have helped me find and fix problems such as GraphQL schema drift.

Illustration of an account search in Chroma using example data — An illustrated walkthrough of finding an account, investigating a build, checking usage, and previewing an administrative change in Chroma. The data is illustrative.

Chroma previews a user deletion with redacted details and affected accounts and apps. — A recording of Chroma showing which accounts and apps a user deletion will affect, asking for confirmation, and saving an audit log after the operation.

Turning repeated work into shared knowledge

Answers in old tickets and Slack threads were difficult for the next engineer to find and reuse. I built tooling for reusable support snippets and packaged our support workflows into an agent plugin to help the team investigate cases and document what they learned.

The snippets live in version control and sync to Plain, with Slack-based authoring that lets teammates preview a proposed reply before submitting it for review. The Support Engineering agent plugin uses one maintained source to generate packages for OpenAI, Claude, and Cursor.

Its triage workflow brings together the conversation, documentation, account and build details, and related engineering issues. It distinguishes what we’ve verified from what the customer reported and what we’re still investigating, then recommends a next step and drafts a reply for the engineer to review. When it can’t reach a source, it says what’s missing.

Illustration of Plain Ops workflows for investigating a customer case — An illustrated walkthrough of Plain Ops, showing how snippet authoring and Support Engineering workflows help turn a case investigation into an answer the team can reuse.

Slack form for proposing a Plain support snippet through Snippetsss — A recording of Snippetsss taking a proposed reply from a Slack form through a preview and into a pull request, with review or auto-merge safeguards.

For resolved cases, a separate workflow checks for gaps in customer documentation, snippets, and the internal knowledge base, then recommends and drafts additions for someone to review.

I also built a learning workflow for engineers picking up a case or reviewing its resolution. It explains the relevant terms, points to evidence and similar cases, and includes checks that could disprove the diagnosis. I want the engineer to understand how we reached an answer and be able to apply that reasoning to the next problem.

Explaining customer usage

When a customer asks why their usage increased, I want to explain what changed using their actual data. I built a workflow that retrieves the account’s usage export and runs a JavaScript analyzer to investigate possible drivers, including build volume, browser changes, and TurboSnap behavior.

The analyzer does the arithmetic, accounting for copied and bypassed snapshots and the export’s multipliers. It rejects unsupported fields and invalid data, flags discrepancies between exported totals and calculated components, and uses the exported billable amount when present. The AI works from those results when interpreting the change.

Before drafting a customer reply for review, the workflow checks relevant account or build details and product guidance. Every number in the reply must trace to the analyzer’s output; if data or access is missing, the engineer gets an explanation of what’s needed to continue.

Using operational data to improve routing

When assignments felt uneven, I looked at the routing data to understand how availability affected who received work. I proposed and ran a regional-routing pilot, tracking assignment distribution, time unassigned, response times, SLA breaches, and capacity pressure.

Regional routing became the permanent model, with requests going to the regional team first and the wider team available as a fallback.

Routing proposal showing EU or Americas coverage during business hours, availability and capacity checks, and a fallback to the wider team — My proposal routes requests to the regional team first, checking availability and capacity before falling back to the wider team.