What Problem Did This MSP Client Need to Solve?
Shane and Hunter open the episode by framing the use case: a co-managed IT client that had two separate ticket boards, one worked by their internal team and one handled by the MSP. The client's point of contact had no visibility into customer satisfaction (CSAT) responses when tickets were closed on either board. Leadership wanted to see how well both teams were performing, but the existing tooling could not produce a report scoped to just that one company.
What Is a CSAT Survey in an MSP Context?
Shane pauses to clarify terminology for listeners outside the managed services industry. A ticket is a request for technical support submitted by an employee or end user. Once the issue is resolved, a CSAT (customer satisfaction) survey is sent automatically asking the user to rate the resolution, typically on a scale of one to five. That rating and the associated question and response are what this automation is designed to surface.
Why Couldn't the Existing Software Generate This Report?
The MSP already had tools that collected CSAT data, but those tools reported across all clients. There was no built-in way to filter or segment results down to a single company. The client needed to see not just overall scores, but also which team, their internal IT staff or the MSP, was handling which interactions and how each was rated. The pre-built reporting simply did not offer that level of specificity.
How Was the Automation Built?
Hunter explains the technical approach. The team used their internal automation platform to connect directly to the SimpleSat API, the tool used to collect CSAT responses. They generated an API key, tied it into the automation platform, and used it to query results scoped to that specific company. From there, the data was pulled from both ticket boards, formatted to show the original survey question, the user's written response, and the numeric rating, then compiled into a clean HTML-formatted email delivered to the client each week.
Can the Report Schedule Be Adjusted?
Yes. While the current implementation fires on a weekly cadence and includes all results as they accumulate, Hunter notes the schedule and scope can be adjusted. If the client later wants only new results from the past week, or a different delivery frequency, the workflow can be updated to match.
What Does This Example Say About APIs and Automation Strategy?
Shane draws out the broader principle: the question organizations used to ask about software was whether it integrated with other tools out of the box. Today, the more important question is whether the tool exposes an API. If it does, custom reporting and connections to other systems become possible even when the software itself lacks that functionality natively. Hunter adds that this same approach can extend to connecting multiple applications across a business, so data flows where it is needed without manual intervention and without adding team overhead.
Where Should Organizations Start with Automation?
Shane shares a common question he hears from leaders exploring automation: what is the lowest-effort, highest-return place to begin? His answer is almost always the same. Start by identifying data sources within the business that are not connected to each other. Bridging those gaps, especially when the underlying tools already support API access, tends to produce fast, tangible results. This episode's example is a straightforward illustration of that principle in action.