What wasn't working.
Customer support had no direct way to look up the account, order, or usage data behind a ticket. Every non-trivial question meant filing a request to engineering, who would write a one-off query, pull the data, and hand it back.
This ate a significant part of engineering’s week on work that added no product value, and it slowed support’s ability to resolve tickets quickly. Neither team had a clear view of how much time the pattern was actually costing.
What we actually did.
As Product Manager, I mapped the actual questions support was fielding day to day, not a generic list of what a CRM should do. That list became the spec.
We built a purpose-fit internal CRM that surfaced exactly that data on the support team’s own screen: account status, order history, usage patterns, and recent activity, with no developer in the loop.
We kept the scope narrow on purpose. Rather than a general-purpose data browser, we built for the specific questions support actually asked, which kept the tool fast to build and fast to use.
Where the interesting calls were.
The hardest call was prioritizing this against feature roadmap work. It looked like an internal favor, not a product. We treated it as one anyway, because the ongoing cost of the status quo, developer hours lost every week, was higher than the cost of building it properly.
We measured both sides of the trade on purpose: developer time recovered and support case throughput gained. That made the case for the investment concrete instead of anecdotal.
We resisted building a comprehensive admin panel. Comprehensive tools take longer to build and are slower to use day to day. We optimized for the specific workflow in front of us.
The numbers after we shipped.
Developer time spent on support queries dropped by half, and engineers got that time back for feature work instead of one-off SQL requests.
Support case throughput increased by 30%, since the team no longer waited on engineering to answer routine account and usage questions.
One tool replaced what had been an ongoing, ad hoc process running between two teams.
Things I'd carry into the next case.
Recurring “quick favors” between teams are usually a sign a real tool is missing. The hidden cost adds up faster than it looks.
Internal tools deserve the same product rigor as customer-facing ones. Understand the actual workflow before building anything.
A win on one team’s time is often a win on another’s too. Look for the second-order beneficiary before deciding whether something is worth building.