I was standing in front of twenty kids, and my equipment had just betrayed me.

It was a Z-Tag event—laser tag, the kind of high-energy event GameTruck coaches run every weekend. The taggers were supposed to connect to the system, each with a unique ID number. Simple enough. Except some of them had duplicated IDs, others had dropped out entirely, and now I had a crowd of increasingly impatient ten-year-olds staring at me while I fumbled through settings menus I barely understood.

I figured it out. Eventually. There’s a “re-enumerate” function buried in the settings that forces all the taggers to reconnect with unique IDs. Crisis averted. Party saved.

But here’s the thing: once I solved the problem, I knew I had to document it. And that’s when I faced a choice that changed how I think about SOPs forever.

The Documentation Trap

I could have taken the standard approach. You know the one. “The Settings Screen allows you to adjust system settings.” Thanks for nothing.

Most technical documentation describes what things are. It catalogs features. It labels buttons. It defines terms. And it sits in a binder somewhere, unread, while your team fumbles through the same problems you already solved.

I didn’t want that. I wanted my coaches to walk into high-pressure situations—twenty kids waiting, parents watching, equipment misbehaving—and know what to do.

So instead of documenting the system, I documented the success path.

Expectation Agreements, Not SOPs

Here’s the reframe: Stop thinking of these documents as “Standard Operating Procedures.” That phrase implies compliance. It suggests behavior control. It sounds like something HR makes you sign.

Instead, think of them as Expectation Agreements—documents that answer one question: How does someone know they’re contributing well?

To answer that, you need to address three things:

1. What is expected? Not “use the settings screen correctly.” The expectation is: The coach can fix common equipment problems fast, so the event keeps running smoothly.

2. What skills, tasks, or methods produce that outcome? Navigate to the settings menu. Find the re-enumerate function. Run it. Be patient while the system cycles through. Know that most problems can be solved from the command system without panicking.

3. What feedback loops show you’re on target? Watch the taggers reconnect. Check the event screen for unique IDs. Ultimately? The real feedback is the customer tip and the NPS score after the event.

When you frame documentation this way, it stops being about technical accuracy and starts being about setting people up to succeed.

Where AI Comes In

Here’s what I’ve discovered: AI is remarkably good at helping you build these expectation agreements.

You can take a messy process—something you do but haven’t documented, or an existing SOP that reads like a technical manual—and use AI to transform it into something useful.

The key is asking the right questions. And now that you know the three questions, you can prompt an AI to help you answer them.

Here’s a prompt you can copy and adapt:

I want to create (or improve) an Expectation Agreement for a process. An Expectation Agreement answers three questions:

1. What is expected? (The outcome or result someone should deliver)
2. What skills, tasks, or methods are necessary to achieve that outcome?
3. What feedback loops help the person know if they're on target?

Here's the process I want to document:
[Paste your existing SOP, or describe the process in plain language]

Please help me:
- Clarify the core expectation (what does success look like?)
- Identify the key skills and steps needed
- Suggest feedback mechanisms so the person knows they're succeeding

Frame everything from the perspective of someone doing the work, not someone auditing it.

You can use this to analyze an existing SOP that feels stale, or to create a new one from scratch. Either way, the AI will help you think through the three questions—and you’ll end up with something your team might actually use.

Why This Matters

Great documentation isn’t about covering your bases or creating a paper trail. It’s about helping people succeed before problems happen.

When I was standing in front of those twenty kids, I needed to already know what to do. Not figure it out live. Not call someone. Not dig through a manual that described what every button does without telling me when I’d need it.

Your team is in that position every day. Maybe not with laser tag equipment, but with processes, tools, and situations where they need clarity in the moment.

The question isn’t “Do we have an SOP for this?”

The question is: “Does our team know how to succeed?”

Your Homework

Pick one process in your business—something that matters, something that causes friction when it goes wrong.

Ask yourself the three questions:

1. What’s the real expectation? (Not the task, the outcome.)
2. What skills or methods does someone need to deliver that outcome?
3. How will they know they’re on track?

If you can’t answer those questions clearly, neither can your team. And that’s not a training problem—it’s a documentation problem.

Use the prompt above to get started. Let AI help you build something people will actually read.

---

Scott Novis is the founder of GameTruck and an accountability coach for the Entrepreneurs Organization (EO) Accelerator program, where he helps small business owners build systems that set their teams up for success.