Built Turntide’s reporting layer from zero. Surfaced what the team was flying blind on. Sales Partner of the Year, 2022.

When I joined Turntide in August 2020 as Senior TPM for Services, the Technical Services team had exactly one piece of infrastructure: a Zendesk contract, with the basic routing the Engineering Director had set up himself. No data was being captured. Decisions were made off spreadsheets and Slack pings.

Inside that under-used Zendesk instance was a treasure trove of data about the actual business: which products were breaking, why customers were struggling after signup, how long it took to set up the product in the field. None of it was surfaced. None of it was informing decisions. The company was flying blind on its own customer signal.

I started with Zendesk. Once that worked, the rest followed.

Build the reporting layer from zero

Took over the Zendesk admin from the Engineering Director. Designed routing and ticket-data capture from scratch so the system was actually producing usable structured data. Built the first generation of dashboards. Once that worked, word got out: I picked up Jira admin and reporting as the work spread cross-functionally. Salesforce already had a dedicated admin, so I partnered with them and used API calls to build in-app support and data features — the three systems started talking to each other instead of living in parallel.

Surface the strategic answers

Technical Services’ Zendesk data answered three questions the business had been guessing at:

• What were the product issues? Before the reporting layer existed, Product had no structured way to see which units were failing or why. The new ticket-data capture surfaced failure modes by SKU and volume; engineering escalations stopped being anecdotal.
• Why were customers struggling after signing up? Onboarding-friction patterns surfaced from CS ticket clustering and CSAT signals.
• How long does the product take to set up in the field? Field deployment timelines pulled from a combination of ticket data, Jira engineering records, and Operations workflows.

Product was flying blind on its own product. Closing that loop was the single biggest unlock.

Apply it to the 10,000-motor channel transition

When the company decided to transition 10,000 motors from direct to channel sales internationally, I was both the data person and the program person. My reporting fed the ROI calculations and the risk-tradeoff analyses that made the call defensible. The transition was both smooth and painful — partner enablement, VOC capture rebuilding, and reliability tracking through a new sales motion all landed on the same reporting backbone.

Built the layer once. It ran everything after.

If I were doing this over, I would spend less time on the technical integrations themselves and more time on the why. Stakeholders — including me — were swept up in any new automated solution without first asking whether it was the necessary one. The building and puzzle-solving hat is still a strength I carry. But the “why” muscle wasn’t fully fine-tuned until after this exercise.

What I carried into the next role: that calibration, plus a lot of technical depth picked up by working alongside brilliant people and hacking along the way.

Zendesk

Admin from zero. Routing, ticket-data capture, dashboards, structured-data discipline.

Jira

Admin and reporting across engineering and cross-functional work.

Salesforce

Cross-system API integration in partnership with the dedicated admin. Connected Sales/Revenue data to the Services + CS reporting layer.

Dashboards

The visible surface of the reporting layer. Built where the decisions actually happened.

ROI modeling

Spreadsheet-based, fed by the integrated data layer. Backed the 10,000-motor channel transition.