things i built because they needed to exist.
A 12-project internal automation platform I designed and am building for the AutoVitals support team. The centerpiece is a live command center dashboard with real-time triage queues, active incident tracking, and weekly metrics. The incident detector clusters similar Zendesk tickets to catch outages before customers start calling. The ticket triage system uses AI to categorize, route, and suggest responses. Auto-tag-and-bag links child tickets to problem tickets during incidents and sends customer updates automatically. There's also a health monitor for Twilio/Mailgun/POS integrations, auto-generated weekly reporting, and workflow tools for shop reactivations and data recovery. This is what happens when you let the person who answers the tickets architect the system.
A security incident dropped 100+ tickets in our queue simultaneously. Doing it manually would have taken the team a week. I built a Python automation suite on top of the Zendesk and OpenAI APIs that handled bulk ticket processing, GPT-powered categorization, and real-time team metrics. It now runs daily — reporting dashboards, CLI tools for common operations, automated triage. Cut our manual workload by 40%.
Before you automate customer conversations, you have to know which ones are worth automating. I built an AI pipeline that reads six months of customer-success activity, classifies every conversation by topic and intent with Claude — batched, so it stays cheap — and rolls it up into a dashboard that ranks topics by volume and automation potential. The headline: about 19% of the activity was a clean email-deflection candidate, thousands of near-identical messages that never needed a human. Real data went in; only aggregates came out.
Support performance bonuses used to be calculated by hand every quarter — slow, and easy to argue with. I built a scoring engine that pulls ticket velocity and CSAT straight from Zendesk and computes payout tiers live, automatically excluding incident and problem tickets so nobody gets dinged for an outage they didn't cause. It's backed by 37 unit tests and a golden fixture that reproduces the real quarterly scorecard exactly. When the math is transparent and tested, the arguments stop.
You can't write every doc, so write the ones people actually need. This runs on a daily cron: it pulls 90 days of ticket volume by category from Zendesk, measures what's actually covered across 288 help-center articles and 180+ internal Confluence pages, and flags the high-demand topics with thin coverage in a Gap Inbox. Built test-first. It turns "we should document more" into a ranked list of exactly what to write next.
Our first-reply-time breach rate looked terrible — 82% — and it was lying to us. Agent-created web work-requests were being measured against a customer-facing SLA they never belonged to. I diagnosed it, then built a tag-driven exemption policy that pulls those tickets out of the metric cleanly, with rollback and a full audit trail. Resolution-time compliance came back to ~94%, and the numbers finally meant something. Good metrics measure the right thing — not just something.
I got tired of running the same fifteen commands in the same order every time someone reported a sync issue. So I built a diagnostic toolkit: SQL Server connectivity checks, network path tracing, DNS verification, registry validation, and log aggregation across 200+ client installations. The team went from 62% first-contact resolution to 78%. Not because they got smarter — because the tooling got smarter.
NAPA deprecated their v1 API. Every affected client needed to migrate to v3 without losing a minute of uptime. I built the tracking system, automated the communication workflows, wrote validation scripts for each migration, and developed rollback procedures for anything that went sideways. Every client transitioned with zero downtime. The rollback procedures were never used.
Every new shop that signed on kicked off the same onboarding checklist, typed into Jira by hand. I built a Slack bot that watches the new-shop channel, reads the alert, and spins up a fully formatted onboarding ticket under the right epic — one slash command, done. Templated for the edge cases. Boring work that used to eat time, now it doesn't.
A small, read-only MCP server that gives AI tools safe access to Zendesk — search, counts, tickets, comments, fields, groups. GET-only, no way to change anything. It's the quiet backbone under half the other tools on this page: whenever I want an AI assistant to reason over real support data, this is what it talks to. Modern plumbing, done cleanly.
When we stood up a real support organization, I designed the thing: a four-tier structure, the hiring pipeline, an interview scoring system that builds itself in Google Forms and feeds a scoring sheet, and a twelve-module Tier 1 bootcamp. All of it grounded in analysis of thousands of real tickets — so the org was shaped around the work that actually comes in, not a guess. This is the part of the job that isn't code: figuring out how a team should be built, then building the scaffolding to grow it.
50+ technical articles. Not marketing content — troubleshooting decision trees and step-by-step procedures for SQL Server, API integrations, network connectivity, and distributed systems. Written so the next person who hits the problem doesn't start from zero. Also built the onboarding documentation that cut new engineer ramp-up time by 60%. Knowledge that compounds is the highest-leverage thing you can build.