What we’ve learned (so far) building the Voice of Customer program at Grafana Labs
Go behind the scenes of Grafana Labs’ Voice of Customer program to learn how we bring user feedback together, use AI to scale analysis, and more.
At Grafana Labs, we’ve spent the last few years building a Voice of Customer (VoC) program that helps our product, engineering, support, and go-to-market teams understand and use feedback from our OSS and Grafana Cloud users.
To support this program, we’ve built a foundation of shared data and workflows that bring together feature requests, support tickets, and other sources of feedback, making it easier for teams to analyze user input and focus on what matters most to them.
This post gets into how all that works behind the scenes: how we bring the data together, use AI to expand our analysis while keeping human judgment, and help teams find and act on user input more easily.
First, why share this now?
AI is (obviously) everywhere, but feedback programs might be one of its most promising use cases yet. We’re seeing more companies invest in AI-driven VoC programs, and at Grafana Labs, AI has already dramatically expanded the scope of ours.
We’ve spent the last few years building that program for a very large and diverse user base. Across Grafana Cloud and our OSS projects, our users range from individual developers and open source contributors to some of the world’s largest companies. Their feedback comes through feature requests, support tickets, customer calls, Slack conversations, GitHub issues, community forums, and direct conversations with our teams.
Bringing all of that feedback together and making it reliable and accessible has required a lot of data work and a lot of iterations to the program. We know many other teams are navigating similar challenges, so we wanted to share a closer look at how we’ve built our program, what we’ve learned along the way, and what we’re still figuring out.
“One shared system” means fixing the data first
This lesson has been the foundation for everything else we’ve built in the program.
Before AI tools were part of our everyday life, our VoC program focused primarily on collecting and managing feature requests in one purpose-built platform. Once we realized we could analyze structured and unstructured feedback at scale, the program expanded significantly.
We made sure that feedback (from sources like Aha!, GitHub, Slack, Gong, and Zendesk) was available in our BigQuery database. However, much more still remained scattered across individual tools. We worked closely with our data team to identify what we needed to be centralized in BigQuery. They did an enormous amount of work to standardize the data, create reliable and easily queryable BigQuery tables for each source, and ensure safeguards are in place to collect and analyze customer feedback.
Once that foundation was in place, we could build the things that provide the most value, like high-quality, cross-source analysis. This foundation expanded our program from primarily managing feature requests to helping teams understand customer feedback at scale.
Key learning: We have built some genuinely useful things with automations and AI, but they are only useful because they sit on top of data that we know is reliable. The AI layer gets more attention, but the difficult data work underneath it is what makes the output trustworthy.
“Meeting people where they work” applies to the entire feedback program
Meeting users where they are is the number one principle behind our VoC program. For us, this means designing each part of the program around how that specific set of users actually work. And we have a lot of people to design for! Our internal users span product, engineering, support, and GTM, and externally, we have our open source users and Grafana Cloud users (of both our free and paid tiers).
We have found that meeting people where they are applies to nearly every part of our program:
- For feedback intake: We make it as easy as possible for anyone to share feedback. Our GTM teams can use a Slack emoji to skip our feedback submission form entirely. Customers have a self-service portal (shown below) where they can view, submit, and vote on feature requests. And sometimes the best intake experience requires no formal intake at all; AI also helps surface feedback from user conversations, including those on our community forums.
- For sharing what we learn: Different teams consume feedback differently. For some, we show up at their team offsite and present the themes we found in their data. Others have a tighter loop with regular slots on their weekly or monthly calls. For others, we provide a self-service way to explore the feedback in their own time.
- For getting things done: Product managers need customer signals, not a firehose of raw feedback. We curate the highest-priority items that need their attention and deliver those lists through the places where they already work.
Key learning: This principle applies to the entire feedback program, but meeting people where they are doesn’t mean maintaining separate workflows for every team. It means building a shared foundation that is flexible enough to support different ways of contributing feedback, accessing what matters, and acting on it. The underlying system stays consistent but how people interact with it can vary.
“AI-powered” means more coverage, not less human judgement
AI has not only automated many of our processes; it has completely expanded the reach of our program. We use it extensively while being intentional about where humans remain in the loop.
A few examples:
- For feature requests: We analyze huge volumes of user feedback without manually reviewing every ticket, call, or conversation. Feature requests are different though: they are published in the self-service portal accessible to anyone with a Grafana Cloud account. AI captures, summarizes, and structures each request, but someone on our team reviews it before publication. The check is quick, catches mistakes, and helps us keep track of what is coming in, while also allowing us to refine the automation to be even more effective.
- For analysis: Analysis is where AI creates the most value for our program and we have several ways of doing and sharing it. Quarterly analyses provide a comprehensive view of the themes emerging across each product area and are often presented in person to the broader product and engineer orgs. Trend analysis automatically monitors the areas teams are prioritizing, and notifies them when a signal begins moving meaningfully. Adhoc analysis lets us quickly create custom reports around specific questions. Every format follows the same model: automation does the broad first pass with claims supported by and linked to original feedback, and then we decide what to prioritize.
- For self-service research: We do not give people a blank chat box and hope for the best. Our team built workflows that define how the data is queried, how the output is structured, and how conclusions are supported.
Key learning: AI can do the first pass (and a much bigger first pass than we could ever do manually) but humans still decide what matters.
“High signal” means looking beyond raw volume
For feature requests, we define high-signal through a prioritization score based on factors such as customer impact, revenue context, and the number of distinct organizations asking for something.
Get Elizabeth Burkly’s stories in your inbox
Join Medium for free to get updates from this writer.
We aligned with our product org on those factors and built the score into our workflows. It now powers many of the notifications that tell product managers which requests are most important to review. The score considers several inputs, but breadth matters most: five votes from five different organizations generally tell us more than ten votes from one organization.
When we analyze broader sets of structured and unstructured feedback, we apply the same principle at a larger scale. A theme becomes more meaningful when it appears across multiple organizations and is corroborated across different sources like support tickets, customer calls, feature requests, and community discussions.
Key learning: Defining high-signal can get complicated quickly. We try to keep it simple: the more customers raising an issue, the higher the priority. And when we hear the same thing across different sources, we can be more confident it’s a meaningful trend.
“Closing the loop” is easier to say than to do
Our internal and external users need to understand what happens after they share their feedback. We try to make that connection visible in a few ways:
- Through our customer portal: Our customers use the portal to submit feedback, vote, and follow requests as they are reviewed, planned, built, and released. Status updates and comments help customers and internal teams see how the feedback is progressing.
- Through our roadmaps: Feature requests are connected to the roadmaps our product managers maintain in the same system and share out internally. That gives customer-facing teams a more direct view into how customer feedback shapes planned product work.
- Through our Customer Advisory Board: We connect feedback from our Customer Advisory Board (CAB) members to the resulting actions and outcomes, then bring that story back to the customers who helped shape it.
Key learning: We’ve made good progress, but have more work to do. Closing the loop is hard because it requires keeping feedback records up to date and making sure the people who shared that feedback hear about relevant updates.
“Making everyone use the program” means making it so useful you don’t have to mandate it
Grafana Labs is an engineering-led company with highly autonomous teams. Our culture does not operate through top-down mandates, so we knew that to encourage our product, engineering, and GTM teams to trust and use the VoC program, we had to earn it.
We started with a program where feedback could feel like it disappeared into a black hole. Requests came in, updates were inconsistent, and engagement from R&D was limited.
We built trust by removing those small sources of friction one by one.
- We standardized feature requests so every request had a clear, consistent summary.
- We created focused queues and notifications so product managers knew exactly what needed review.
- We set clearer expectations with customers about what would be reviewed and prioritized.
- We also asked product managers for feedback on our reports and tools, then changed them accordingly.
- We brought product-specific findings directly to engineering teams at their offsites.
Together, these small changes made the program easier to understand, participate in, and trust. We’ve still got more to do though!
Key learning: This one is a doozy. An enjoyable doozy for us, but one that depends heavily on company culture. “Change management” is a buzzy phrase with no shortage of frameworks attached to it, but we never really called it that. We had to do it the Grafana Labs way: earn trust team by team, build useful things, iterate, and let adoption grow from there.
What all of this has opened up, and what’s next
Our investment in VoC has opened up opportunities well beyond feedback collection. The shared data and processes we’ve built now support other programs across Grafana Labs, helping engineers engage directly with customers and bring what they learn back into the system, product managers incorporate customer feedback into roadmaps, and teams plan and communicate launches more consistently. They also provide a home for structured input on product direction through our customer advisory board.
Each of these programs has its own goals, but they all benefit from a common foundation of reliable customer feedback.
So where do we go from here?
We’ve put a lot of work into making our workflows accurate and reliable, but there’s still room to improve. Today, humans review and refine the results, but those corrections don’t consistently feed back into the system. We want to change that, using what people correct, question, or flag as missing to improve our workflows over time.
We are also exploring agents that can continuously work across our sources, identify meaningful signals, and translate unstructured conversations into structured feedback all in an automated and behind-the-scenes way.
And more broadly, we want to keep extending the reach of this foundation while allowing the programs built on it to remain distinct. The opportunity is to make reliable customer signal useful wherever teams engage customers, plan work, and decide what to build next.
