Your Field Guide Is Not a Shiny Object

You have a graveyard. Every MSP owner does.

The PSA that was going to streamline everything. You spent four months on the implementation, trained the whole team, paid for the onboarding package, and ended up using about 40 percent of what it promised because the other 60 percent required a level of process documentation you never had time to build.

The AI tool that was going to automate your helpdesk. It worked great in the demo. In your actual environment, with your actual ticket data and your actual escalation logic that nobody had ever written down, it routed things wrong and your best tech spent two weeks cleaning up after it before you quietly turned it off.

The accountability system your operations manager built on a Saturday. Color-coded. Beautifully designed. Used for eleven days.

You know this pattern. You've lived it. And you've gotten good at recognizing the feeling that comes with the next thing. The vendor who says this one is different. The peer who swears by it. The demo that makes it look effortless. The quiet voice in the back of your head that says: here we go again.

So when someone tells you to build a field guide, that voice gets louder.

Is this another one of those?

Here's the honest answer. And then here's why the question itself is pointing you in the wrong direction.

WHAT MAKES SOMETHING A SHINY OBJECT

Shiny objects share three characteristics and every one you've ever bought had all three.

They promise a result without requiring foundational work first. The PSA promised organized operations. The AI tool promised automated efficiency. Neither one told you upfront that the promise assumed you already had your processes documented, your categories defined, your logic written down somewhere a system could actually use. The result was real. The prerequisite was hidden.

They produce excitement at purchase and friction at implementation. The demo is always smooth because the demo runs on a clean environment with perfect data and a vendor who knows exactly which buttons to press. Your environment has twelve years of accumulated decisions, workarounds, and tribal knowledge that nobody ever documented. The friction isn't a product failure. It's the gap between what the tool assumed and what you actually had.

They depreciate. The PSA you bought three years ago is already being replaced by the next platform. The AI tool that was cutting edge last year has three competitors that do it better. Every shiny object has a sunset. You pay for it, you extract what value you can, and eventually you buy the next version.

The field guide fails all three of those tests.

It requires the foundational work. That's the point. The friction you feel at the start of building it is the same friction that every tool you've ever bought silently transferred onto you after purchase. The difference is you're doing the work that makes everything else work, instead of discovering too late that the tool needed it done first.

It gets harder before it gets easier, and then it compounds. The first system you document takes the longest. You're figuring out the format, finding the language, deciding what level of detail is enough. The tenth system takes half as long. The twentieth takes a quarter. Every system you build makes the next one faster because you've built the muscle and the standard.

It appreciates. Every system you document is a system you never have to personally run again. Every new hire who onboards against it learns faster and costs you less. Every AI tool you deploy on top of it works better because the context it needs actually exists. The field guide doesn't have a sunset. It has a foundation. And foundations don't go out of style.

EVERY TOOL YOU'VE EVER BOUGHT NEEDED THIS FIRST

Here's the thing about your graveyard that nobody said out loud when you were buying.

Every tool in it needed your operating foundation to work. Your PSA needed your ticket categories, your SLA definitions, your escalation logic, your client tiers, your billing structure documented clearly enough for a system to act on them. Your RMM needed your monitoring thresholds, your patch policies, your alert priorities, your response protocols. Your AI tool needed your workflows, your decision criteria, your client context, your communication standards.

Every single one of them came with a promise. And every single one underdelivered because the promise assumed something you didn't have. Not the budget. Not the team. The documented operating foundation that tells a tool how your business actually works.

Nobody told you that was the prerequisite. They wanted the sale.

The field guide is that prerequisite. Every tool you buy from here forward runs better on top of it. The PSA finally delivers what it promised because your processes are documented clearly enough for it to reflect them. The AI tool routes correctly because your escalation logic exists somewhere it can read. The new hire produces at a high level in 30 days instead of 90 because the standard they're working toward is written down.

The field guide is the thing that makes your tools work.

WORKING ON THE BUSINESS IS NOT ABSTRACT ANYMORE

Every owner has heard it. Work on the business, not just in it. Michael Gerber said it. Every business coach you've ever paid has said it. Your most successful peer says it at every conference.

And every Monday morning you go back to working in it. Because working in the business is urgent and working on it is vague. Because a client ticket needs a response right now and a documented dispatch system can wait. Because the next hire needs onboarding today and the onboarding checklist can get built next week.

Next week never comes. Because working on the business stays abstract until someone makes it concrete.

The field guide makes it concrete.

It's a specific, tangible output: a documented system for how your business runs. You don't work on "improving operations." You sit down on a Tuesday afternoon and document your escalation procedure. Outcome, steps, measurement, feedback loop. One system. One hour. Done.

Every hour you spend on it produces something that exists. Something your team can use tomorrow. Something that compounds next month when the new hire reads it on day one instead of learning the wrong way from whoever is sitting next to them.

That's not abstract. That's the most measurable return on time you'll ever find in your business.

THE COMPOUNDING MATH

Here's the frame that makes this click for most owners.

Shiny objects depreciate. You buy them, they work at some level, they get replaced. Every tool in your graveyard was worth less the day after you bought it than the day of the demo. That's not a complaint. That's how tools work. They have a lifecycle.

The field guide appreciates.

The first system you document makes the second one easier. The tenth makes you faster. The twentieth makes the whole thing coherent. By the time your field guide has 14 systems documented, it's not a document anymore. It's an operating system. And operating systems compound.

The new hire who onboards against it in 30 days instead of 90 frees up 60 days of senior tech time that was previously spent answering the same questions over and over. Multiply that across every hire you make this year. That's a number worth calculating.

The AI tool you deploy on top of a documented environment routes correctly from day one instead of requiring two weeks of cleanup. The time your best tech spent fixing after the last deployment gets redirected to client work. That's revenue.

The client who gets the same experience regardless of which tech is on the ticket stays longer and refers more. Consistency is a retention strategy. The field guide is what produces consistency at scale.

None of this requires a new budget line. None of it requires a vendor. The compounding return is built into the work itself.

THE HONEST COST OF NOT DOING IT

Here's what the graveyard actually costs you. Not the money you spent on the tools. The cost of not having the foundation before you bought them.

Every week your business runs without a field guide is a week it runs on tribal knowledge. The escalation logic that lives in your senior tech's head. The client preferences that live in your account manager's memory. The onboarding process that lives in whoever happened to train the last new hire. That knowledge is your operating system right now. It works until it doesn't.

Every new hire who onboards without it learns from the nearest person and adds their own variation. After three years of that, your dispatch process has seven versions running simultaneously and nobody knows which one is right because nobody ever wrote it down.

Every AI tool you deploy without it guesses at the decisions it makes. It guesses fast and consistently. The guesses just reflect the data you gave it instead of the business you built.

Every client interaction that runs without a documented standard is a coin flip on the experience. Some techs are great at it. Some are still learning. The client gets whoever picks up the ticket.

The cost of not building it is slow. It's the business that needs you more every year instead of less. It's the team that's capable but inconsistent. It's the growth that keeps hitting the same ceiling because the ceiling is you.

THE BARRIER IS LOWER THAN ANYTHING ELSE YOU'VE BOUGHT

Here's what's different about this decision compared to every tool in your graveyard.

No budget. The field guide costs you time. Not license fees. Not implementation packages. Not consulting retainers. Time. Specifically the time you spend writing down how your business actually works, starting with the system causing you the most pain right now.

No vendor. Nobody needs to onboard you. Nobody needs to configure an environment. Nobody needs to run a training session before you can use it. You open a document and you start.

No sunset. The PSA you bought three years ago already has a replacement that does it better. The field guide you build this year is the same field guide you're still building in year five. It gets better every time you touch it. It doesn't get replaced.

Built to Run exists specifically to give you the structure to start without facing a blank page. The format, the system categories, the outcome-measurement-feedback loop framework, the hiring system templates, the talk tracks. The skeleton is there. Your job is to fill it in with how your business actually works.

That's a different category of decision than every other operational investment you've made. It's a commitment to doing the work that makes everything else work.

You've already paid for enough things that promised to fix the business. You've bought the tools that assumed the foundation existed. You've lived the gap between the demo and the implementation. You've added to the graveyard and moved on.

The field guide is the foundation.

It's the thing that makes your PSA deliver what it promised. It's the thing that makes your AI route correctly on day one. It's the thing that makes your new hire productive in 30 days. It's the thing that makes your best client experience consistent instead of occasional.

It costs you time. It produces something that compounds. It gets more valuable every week you work on it instead of less.

You've spent the money. Now spend the time.

Start at builttorunmsp.com

FREQUENTLY ASKED QUESTIONS

What is a field guide in a managed services business?

A field guide is a documented operating system for your MSP. It captures how your business actually runs across every core system: dispatch, escalation, onboarding, hiring, client communication, QBRs, finance, and sales. Each system is documented with an outcome, the steps to achieve it, a measurement that tells you whether it's working, and a feedback loop that catches drift before clients feel it. The field guide is a living system your team works from daily, your new hires learn from on day one, and your AI tools run on top of when you deploy them.

How is a field guide different from standard operating procedures?

Standard operating procedures document the steps. A field guide documents the system. The difference is everything that surrounds the steps: the outcome the process is supposed to produce, the measurement that tells you whether it's producing it, and the feedback loop that surfaces drift. An SOP tells your team what to do. A field guide tells them what they're trying to produce, how to know if they got there, and what happens when results drift. SOPs get filed and forgotten. A field guide gets used because it's built to tell the team not just how to work but whether the work is producing the right result.

Why do MSP tools underperform without a documented operating foundation?

Every tool you deploy runs on the context you give it. Your PSA organizes the tickets you put in it according to the categories and logic you define. Your RMM monitors against the thresholds you set. Your AI tool makes decisions based on the workflows and criteria you document. When that context lives in people's heads instead of documented systems, the tool fills the gap with generic defaults or guesswork. The result is a tool that works technically and underperforms operationally. The field guide is the documented context layer that makes every tool perform closer to what the demo promised.

How long does it take to build a field guide?

The first system takes the longest. Plan for two to three hours for the first documented system as you figure out the format and level of detail. After that, subsequent systems get faster. Most owners can document one system per week working in focused blocks of one to two hours. A complete field guide covering 14 core systems takes three to four months at that pace. The better question is how quickly it starts returning value. The first system you complete starts paying back immediately. Every new hire who onboards against it, every AI tool deployed on top of it, and every consistent client interaction it produces is a return on the work done so far.

What should you document first in your field guide?

Start with the system causing you the most pain right now. If dispatch is inconsistent, start there. If new hire onboarding is expensive and slow, start there. If the QBR experience varies by account manager, start there. The first system you document should be the one where the cost of the current inconsistency is most visible and most painful. That gives you the fastest return on the investment of time and the clearest proof of value to share with your team. After the first system is done, work through the foundation section: mission, core values, and BHAG. That context layer is what every subsequent system and every AI tool you deploy will run against.