The Operator Snapshot: How We Run the Check-in

If you have an AI Operators program running (which some companies call AI champions or AI ambassadors), you've already done the hardest part. You identified the people in each department who actually care about this, you put them in a recurring meeting, you started teaching them the tools and the framework, and you got them sharing work with each other. That's the engine of AI adoption inside most companies, and most companies don't have it.

A few months into one of these programs, we hit the same question every time. Where are these operators actually at? We can usually answer by feel. The loud voices, the demos, and the side conversations all give us a read. But the room is always bigger than the operators who speak up, and the ones who don't are the ones most likely to be quietly stuck on something foundational. If we plan the next session based on what the room sounds like, we end up teaching to the front row.

That gap gets harder to close when the meetings are remote, which most of them are now. When we're running these sessions as a consultant, we're not in the office with these operators day to day. We drop in for an hour, we're looking at a few dozen faces in tiles, and a lot is happening underneath that we can't see. Some operators want to speak up but aren't sure if they should. Some have built something they're proud of but aren't sure it's worth showing. Some are quietly worried about AI in ways that color how they engage with the program, and they're not going to bring that up at the top of the call. We can't answer those questions by feel in an hour on a screen. So we've built a habit into every program of occasionally stopping down and asking the room directly, in a structured way.

We've been running that habit across our operator programs for years, in one form or another. The release of AI Operator Snapshots inside Solutioner.ai is the impetus for this post, but the practice itself is something we've been refining for a long time. Here's how we run it, what we built around it, and how to run your own version even if you don't use Solutioner.

The motion

Every few months, in the programs we run, we stop teaching and we ask. We give every operator the same structured set of questions and let them answer privately. We score what they tell us. We share the aggregate result back with the room. We adjust the next few sessions based on what we find.

That sounds simple, and it is. It just has to be built in deliberately. It doesn't happen on its own.

At Gadoci, we build our operator curriculums session by session. We teach foundations, then skills, then agents, then context windows, then whatever the platform shipped last week. Each session feels right in the moment, and the cumulative arc reflects what we thought was next. That's a reasonable way to run a program like this. The risk is that without a deliberate mechanism, we never stop to ask the operators what they actually retained or what they actually want.

The check-in is the mechanism. It surfaces what operators don't know that we assumed they did. It surfaces what they want to learn next, which is almost always different from what we planned to teach. And it gives the group a shared read on where they are, which is the part that changes the energy of the meeting more than anything else we've tried.

What the check-in produces

When we run a structured check-in, two reports come out the other side. Each operator gets a personalized report based on their own answers. We get an aggregate report based on the whole group.

The personalized report is what makes the check-in feel worth taking. It tells the operator where their gaps are and what to do about them, with concrete next steps. The point is to give the operator a private nudge in the right direction, in a channel where they don't have to admit anything to anyone else. Most operators won't ask the leader of a program a question they're worried makes them look behind, and the personalized report sidesteps that entirely. In our implementation, the report links into the relevant features and documentation inside the platform when the gap can be closed there, and hands the operator a ready-made prompt to paste into their tool of choice when the gap is a broader AI fluency question to explore on their own.

The aggregate report does something different. It doesn't change how we run the program. It directs where we go next.

It tells us what percentage of operators are reaching for AI weekly versus monthly, where confidence in tool selection lands, whether the group can spot hallucinations, whether they can articulate what a context window is, whether the methodology we've been teaching has stuck. None of that is visible from the front of the room. All of it shows up in the data.

There's another piece of the aggregate that we've come to rely on. Because Solutioner is also where operators do their actual work, the platform already knows things about them that a survey can't show. How many briefs they've created. How many comments they've left. How many wins they've logged. That activity data gives us a second source of truth against the survey. If an operator scores themselves a five on logging wins but hasn't logged any, that's a different signal than a confident operator who has three. The survey tells us what they think. The platform tells us what they've done. Reading them together is more useful than either alone.

What happens when we share the aggregate back

This is the step that makes the whole motion work. It's also the easiest part to skip when we're busy, so we've made it non-negotiable.

In the session after the check-in, we walk the group through the aggregate results. We point out where they're strong. We name the gaps plainly. We tell them what we're going to do about it in the next few sessions, and we ask if we got the read right.

Three things happen in that conversation.

The operators see themselves in the data. They recognize the gaps because they can feel them. Hearing it confirmed in aggregate gives them language for something they couldn't quite name.

They get permission to admit out loud that something they assumed everyone else understood is actually confusing them too. That kind of permission is hard to manufacture any other way. Once one operator says it, others follow.

The room shifts from passive to participatory. They know we're listening to them, not lecturing at them, and the next session reflects what they said. That's the loop an operators program runs on once it gets going.

We learned over time that collecting the data, looking at it ourselves, and quietly adjusting the next session without sharing the aggregate back gets us about a quarter of the value. The operators fill something out and get nothing visible in return. Closing the loop is the move that makes the rest of it work.

What we built

We've been running this motion across our programs for years, well before we had a feature for it. We drafted questions, picked a survey platform, sent the link, chased people down, scored the answers, built an aggregate view, wrote up the narrative, and shared it back. It worked. But the friction of doing all of that by hand meant we'd run a check-in once or twice in a program and then push it to the back of the queue, running the next session on intuition until enough time passed that we forced ourselves to do another.

So we built AI Operator Snapshots into Solutioner.ai to make the motion cheap enough to run on the cadence it deserves. An admin opens a snapshot, picks questions from a library, sets the window, and pushes it live. The library is the part of the feature we care most about. Our team at Gadoci Consulting writes and maintains every question in it, drawn from what we actually ask operators in real engagements. The people authoring those questions are the same people running the meetings, so an admin building a snapshot isn't pulling from a generic survey template. They're working off a vetted set of questions that have already been tested with real operators across active programs.

Operators get a notification, take the survey in two or three minutes, and get the personalized report described above. The admin gets the aggregate dashboard, including a team health score, per-question rollups, and a generated narrative that summarizes where the operators stand, where to focus next, and the cross-question patterns that only surface when you read the answers together.

The questions in our library sit in three buckets that together give us a real read on a Gadoci-run operators program. The first is tool usage, which tells us whether operators are actually reaching for the tools and which features are landing. The second is general AI fluency, which tells us how operators feel about AI in general and whether the foundational concepts have stuck. The third is methodology, which tells us whether operators understand and are buying into the framework we bring to engagements. Other programs might land on different buckets. These are the three we've landed on for the kind of work we do.

Because the snapshots live in the same place as the briefs, the plans, and the wins, they become a longitudinal record. We can take one every few months and watch whether the gaps we said we'd address actually got closed.

You don't need Solutioner to do this

The motion is the thing. The tool is secondary.

If you don't use Solutioner, run a version of this yourself. Build a Google Form. Use SurveyMonkey. Use a Notion database, a Microsoft Form, a spreadsheet with a script. Whatever your team will actually engage with. Write fifteen or twenty questions across the categories that matter for your program. Run it. Score the answers. Share the aggregate back with the group. Adjust the next session.

What you'll lose without a platform is the parts that tie the survey to the rest of the program: automatic personalized reports with links into the work, activity data alongside the self-assessment, longitudinal trending across snapshots without manual reconciliation. You'll do more work to produce the aggregate write-up. But the core motion still works, and most of the value lives there. We know because we did it that way for a long time.

We built Solutioner the way we did because we run a specific framework with specific clients, and the snapshot is one piece of that framework. If our tool helps, use it. If it doesn't, run the motion anyway. We'd rather see more leaders running structured check-ins than see more leaders using our product.

Keep listening

Do the check-in. Even without a tool to make it easy.

We've watched operators who built real momentum quietly check out when the sessions stop being for them. The check-in is how we catch that before it happens. We run it. We share the aggregate back. We adjust the next session. We repeat in a few months.

That's the loop that's kept our operator programs growing past the point where the novelty would otherwise wear off. It's a simple motion, but it's the one we've found makes the difference. We ask. We listen. We adjust. We keep going.