.png)
How our Head of GTM Ops shipped a post-onboarding CSAT survey in about a minute and what it changed about how he spends his week.
Chaz Logue runs GTM operations at Appcues. Analytics, dashboards, enablement, systems, internal playbooks. His own summary is that it's easier to list the things he doesn't do, and that list is currently empty.
A couple of months in, the first thing he tackled with the team was onboarding. Specifically: once a customer finishes our new onboarding experience, how do we find out whether it actually worked for them?
The answer was a CSAT survey, delivered in-app, right at the moment onboarding wraps. How did it go? How did we do? Plus an open-text field for anything the score doesn't capture. What's interesting is how it got built, and what that revealed about where the work in "building an in-app experience" actually lives.
Want the template for yourself? Get it here!
Chaz aimed to solve two things at once.
The obvious one was the survey itself: a feedback channel for the onboarding rollout.
The less obvious one was the process. This was the first in-app engagement his team would ship, and he knew it wouldn't be the last. So rather than build a one-off, he wrote up a repeatable framework: a requirements doc in Notion that spelled out what the experience needed to do, who it targeted, and when it should fire. The idea was that every future in-app engagement would start from the same structure.
"I wanted to be able to gather this in a repeatable way," he told me, "so that as we build more in-product engagement, I'd spend less time building and more time aligning with my stakeholders."
Here's how the survey actually came together:
1. Chaz gathered the necessary info from stakeholders
2. He exported his Notion requirements doc as a PDF
3. Then, handed it to Appcues AI.
"It built probably 75% of what I needed. It was basically done in a minute."
That 75% included the structure, the steps, the targeting, the copy. This is all the scaffolding that normally eats an entireafternoon. What was left was the 25% that requires a human to have an opinion.
And that's where the real payoff showed up. Because the build was essentially instant, Chaz could walk into his stakeholder review with a working survey instead of a spec. The conversation shifted from "here's what we plan to build" to "here's what we agreed to, here's how it translated into the product, has anything changed?"
Things had changed, of course. They usually do. But the tweaks got made in the review, not in a second build cycle after the review.
"It made us able to make decisions a lot more quickly than having to do the build and then chase down decisions afterwards."
Chaz has worked in ops at companies bigger and smaller than Appcues, and he's blunt about the pattern: alignment and requirements-gathering are a mess everywhere. Every team has its own flavor of it, its own maturity level, and nobody has fully solved it.
What's different now isn't that alignment got easier. It's that building got so cheap that alignment is the only thing left worth spending time on.
"There's a shift in where you can be spending your time. Being able to import your requirements and have it build the majority of the experience for you improves the time it takes to actually release. Which gives you more time internally to coordinate with folks."
Put differently: when the build was the bottleneck, teams rushed alignment to get to building. When the build is a minute, you can afford to get the alignment right and you can do it with the real thing on screen instead of a mockup.
Chaz's next experiment is cutting out the PDF step entirely: connecting Notion to Claude and the Appcues MCP so the requirements doc feeds directly into the build.
If you're standing up your own repeatable process for in-app surveys, announcements, or guides, Chaz made the CSAT template available to use!
Have a question you'd want Appcues AI to take a swing at? Tell us in our LinkedIn DMs! We'd love to build it.
Lifecycle Marketing
How our Head of GTM Ops shipped a post-onboarding CSAT survey in about a minute and what it changed about how he spends his week.
Chaz Logue runs GTM operations at Appcues. Analytics, dashboards, enablement, systems, internal playbooks. His own summary is that it's easier to list the things he doesn't do, and that list is currently empty.
A couple of months in, the first thing he tackled with the team was onboarding. Specifically: once a customer finishes our new onboarding experience, how do we find out whether it actually worked for them?
The answer was a CSAT survey, delivered in-app, right at the moment onboarding wraps. How did it go? How did we do? Plus an open-text field for anything the score doesn't capture. What's interesting is how it got built, and what that revealed about where the work in "building an in-app experience" actually lives.
Want the template for yourself? Get it here!
Chaz aimed to solve two things at once.
The obvious one was the survey itself: a feedback channel for the onboarding rollout.
The less obvious one was the process. This was the first in-app engagement his team would ship, and he knew it wouldn't be the last. So rather than build a one-off, he wrote up a repeatable framework: a requirements doc in Notion that spelled out what the experience needed to do, who it targeted, and when it should fire. The idea was that every future in-app engagement would start from the same structure.
"I wanted to be able to gather this in a repeatable way," he told me, "so that as we build more in-product engagement, I'd spend less time building and more time aligning with my stakeholders."
Here's how the survey actually came together:
1. Chaz gathered the necessary info from stakeholders
2. He exported his Notion requirements doc as a PDF
3. Then, handed it to Appcues AI.
"It built probably 75% of what I needed. It was basically done in a minute."
That 75% included the structure, the steps, the targeting, the copy. This is all the scaffolding that normally eats an entireafternoon. What was left was the 25% that requires a human to have an opinion.
And that's where the real payoff showed up. Because the build was essentially instant, Chaz could walk into his stakeholder review with a working survey instead of a spec. The conversation shifted from "here's what we plan to build" to "here's what we agreed to, here's how it translated into the product, has anything changed?"
Things had changed, of course. They usually do. But the tweaks got made in the review, not in a second build cycle after the review.
"It made us able to make decisions a lot more quickly than having to do the build and then chase down decisions afterwards."
Chaz has worked in ops at companies bigger and smaller than Appcues, and he's blunt about the pattern: alignment and requirements-gathering are a mess everywhere. Every team has its own flavor of it, its own maturity level, and nobody has fully solved it.
What's different now isn't that alignment got easier. It's that building got so cheap that alignment is the only thing left worth spending time on.
"There's a shift in where you can be spending your time. Being able to import your requirements and have it build the majority of the experience for you improves the time it takes to actually release. Which gives you more time internally to coordinate with folks."
Put differently: when the build was the bottleneck, teams rushed alignment to get to building. When the build is a minute, you can afford to get the alignment right and you can do it with the real thing on screen instead of a mockup.
Chaz's next experiment is cutting out the PDF step entirely: connecting Notion to Claude and the Appcues MCP so the requirements doc feeds directly into the build.
If you're standing up your own repeatable process for in-app surveys, announcements, or guides, Chaz made the CSAT template available to use!
Have a question you'd want Appcues AI to take a swing at? Tell us in our LinkedIn DMs! We'd love to build it.
Sign up for Quickcues and get our monthly updates!
.svg)
