Skip to main content

Customer Success Technology Operations

The reporting, automation, and systems layer behind a healthcare-technology customer success organization.

Context
Tebra / Kareo · healthcare technology
Period
2017 – 2023
Categories
AutomationAnalyticsBusiness AnalysisIntegration

Executive Summary

At Tebra (and Kareo before it), I worked in the operational engine room of customer success for a healthcare-technology company: the Snowflake SQL behind customer-success metrics, the Salesforce and Gainsight configuration behind customer workflows, the Jira Service Desk processes behind support operations, and the custom reporting that let leadership see what was actually happening.

The Work

  • Customer-success metrics and reporting built on Snowflake SQL: account-level customer health, adoption, and operational measures consumed by CS leadership.
  • Analysis of declining CSAT scores: identified the key indicators and presented strategic recommendations to executives for policy development.
  • Custom reporting for federal subpoenas and search warrants, built with legal and database teams. Data work where precision and defensibility are non-negotiable.
  • Salesforce and Gainsight administration and reporting: the systems where customer reality is recorded, kept useful and trustworthy.
  • Jira Service Desk workflow design and reporting for operational teams.
  • Process improvement across the seams, in the gaps between systems and teams where customer experience actually degrades.
  • All of it in a regulated healthcare-data environment, with the data-handling discipline that implies.

Automation Spotlight: Turning a Manual Follow-Up Into a System

The clearest example of the operations work: a customer-outreach process that used to run entirely on people remembering to do it. When a ticket needed information or data from a customer before it could move forward, an agent had to send the request, remember to follow up, chase again, and eventually close it by hand. Things fell through the cracks constantly.

I rebuilt it in Jira Service Desk as an automated state machine. The system sent the outreach on a schedule up to three times; if the customer never responded, it closed the ticket automatically; and if the customer replied by email, it reopened the ticket and routed it back for review. The same automation moved tickets between the customer-facing role and the analysts, so an analyst could weigh in on what the customer's data could and couldn't support while the customer-facing teammate handled the conversation.

I paired it with a pre-payment data checklist: a short, plain-language guide that helped customers understand their own data and what was and wasn't possible before they paid. It caught data problems early, set honest expectations, and cut the downstream rework that happens when someone buys something their data can't actually support.

Why It Matters Here

This chapter is why I'm comfortable in the space between 'the data team' and 'the business': years of being the person who owned both the SQL and the stakeholder meeting. It's also where I learned that most reporting problems are process problems wearing a costume, a lesson that transfers to every domain I've worked in since.

Skills Demonstrated

  • Snowflake SQL and custom reporting for customer-success metrics
  • Jira Service Desk workflow automation: ticket state machines, scheduled auto-outreach, auto-close and reopen, and role-based routing
  • Data-quality gating and QA checklists that catch problems before they become rework
  • Salesforce and Gainsight administration and reporting
  • Process improvement in a regulated healthcare-technology environment
  • Technical/non-technical stakeholder translation as a daily practice

Skills in this project

  • Snowflake SQL
  • Jira Service Desk automation
  • Workflow automation
  • QA & data validation
  • Salesforce
  • Gainsight
  • Process improvement
  • Regulated-data awareness