KEVIN DUMPIT

What I’ve Built

The work I’m most known for lives in the Case Studies section of this site. The short version:

I took operational problems that most support organizations accept as facts of life — slow new hire ramp times, uneven workload distribution, quarterly performance review backlogs — and treated them as design problems. Each one got a structured solution, built under real organizational constraints: no CRM customization, no new fields, no formal program budgets, no top-down approval.

The results were measurable and durable. New hire time-to-performance dropped from nine months to three. Average Speed of Answer went from twenty minutes to five. Initial Response SLA attainment climbed from 35% to 95% — and held there, within two percentage points, in the years that followed. Quarterly performance review delivery compressed from two to three weeks down to the same week as scorecard release. The operational infrastructure these systems created contributed to team-wide efforts that aided in retaining enterprise accounts representing $8M in ARR and surfaced early risk signals that helped prevent implementation project debooks valued at $300–400K.

I also know what it takes to build with resources, not just without them. The capstone of the case study series is a designed concept for an AI-forward case management dashboard — RAG-powered coaching, agentic evaluation, continuous performance signals — that lays out exactly what organizational alignment, technical infrastructure, and governance would be required to move from constraint-driven instruments to an integrated system. I can build in scrappy mode. I can also architect for scale.

Where I’ve Operated

My career has spanned the full support lifecycle — from hands-on case resolution to team-scale operational design. I started as a frontline associate building deep technical proficiency in the SuiteCloud platform, expanded into SuiteCommerce Advanced, and progressed into a vertical lead role where I served as the technical authority and escalation lead for the product area.

As a manager, the scope grew substantially. I inherited a team covering two product verticals, then led the post-acquisition support ramp for two additional products — building the support function from the ground up for lines that came in through acquisition with no existing infrastructure. I led the support launch for a net-new platform product and expanded my team’s coverage to a sixth vertical. At peak scope: twelve direct reports — frontline associates, subject matter experts, and technical leads — across Toronto and Manila, covering six product areas.

Post-restructuring, I transitioned to a Support Operations Lead role. The scope didn’t change. I continue to manage the Toronto and Manila teams, lead the ramp projects I started, design the processes and mentoring the case studies document, and now carry additional involvement in launching the company’s next-generation platform. The title is different. The operating altitude is the same.

How I Think About the Work

Four principles run through everything I build. They emerged from the case studies, but they’re how I think about operational design in general:

Structure the workflow before you automate it. The form fields that trained associates to document cases correctly are the same fields that make a knowledge base machine-readable. Automation that follows good structure scales. Automation that replaces bad structure just scales the mess.

Embed skill-building into daily practice, not training events. Muscle memory built during live casework is more durable than knowledge acquired in a classroom. The best enablement systems don’t feel like training — they feel like doing the job correctly.

Use AI to make itself unnecessary. The most valuable thing AI can produce is often not an answer — it’s a tool that no longer needs the AI to run. Distill the intelligence into an instrument. Let the instrument do the work.

Freed capacity finds its own highest use. Every hour recovered from manual assembly, batch review, or administrative catch-up is an hour available for the work that actually requires a human: the coaching conversation, the judgment call, the relationship with the customer.

What Holds a Team Together

Systems and metrics tell part of the story. They don’t tell all of it.

The teams I’ve led have operated through structural headwinds — compensation gaps between sites, limited opportunities for career progression, organizational restructuring that changed titles without changing workloads. None of that is unusual in enterprise support. What was unusual was the response: the team stayed together. They showed up, they solved problems, and they faced the next challenge without relent.

That doesn’t happen because of a process document or a Saved Search. It happens because the people on the team trust that their manager sees the situation clearly, communicates honestly, and builds systems that make their daily work better rather than harder. I take that seriously. The operational infrastructure I design exists to serve the people running it — not the other way around.

What I’m Looking For

I’m drawn to roles where operations, people development, and AI strategy intersect — where the question isn’t just “how do we support customers?” but “how do we design the system that makes great support the path of least resistance?”

If that resonates, I’d welcome the conversation.