XANDITE
Guide

How to stop being the bottleneck in your service business

A practical way to get the decisions out of your head: what to write down first, how to delegate the judgment calls, and how a private AI makes it queryable.

You stop being the bottleneck by moving the decisions out of your head and into a written form your team can use without you, then making that form answerable on demand. Spend one week logging every question people bring you; the tally almost always clusters into pricing, vendors and parts, scheduling and dispatch, and policy or judgment calls. For each cluster, write down the rule that generates the answer — the base case, the modifiers, and the judgment calls stated as "do X when Y" — not the one-off response, and keep it in a single place that one person owns and maintains. Once the rules exist, a private internal AI makes them queryable: staff ask in plain language and get your answer back with a citation to the source document, instead of calling you from the truck. The goal is not to remove your judgment from the business but to record it once so it scales past your phone.

Most owner-operators do not have a work problem. They have a concentration problem: too many decisions can only be made by one person. The quote that is outside the flat-rate book, the vendor to call when the usual one is out of stock, whether this customer gets the exception — every one of those routes through you, and the business slows to your response time.

You cannot fix this by working more hours. You fix it by moving the decisions out of your head and into a form other people can use without you. Here is how to do that in an order that actually works.

Step 1: Find out what people interrupt you for

For one week, keep a running list every time someone asks you something they could not answer themselves. Phone, text, in person — all of it. Do not try to fix anything yet; just capture it.

By Friday you will have a list of thirty to fifty items, and they will cluster. For most service businesses the clusters are:

  • Pricing — "what do we charge for X," "can I discount this," "does the after-hours rate apply."
  • Vendors and parts — "who has this," "what is our account price," "is this covered under warranty."
  • Scheduling and dispatch — "can this fit today," "who is qualified for this job," "does this count as an emergency."
  • Policy and judgment — "do we do this kind of work," "how do we handle this complaint," "what are this account's special terms."

The cluster with the most tally marks is where you start.

Step 2: Write down the rule, not the answer

The instinct is to answer the specific question. The leverage is in writing down the rule that generates the answer.

"Charge 450 for that" helps once. "Single-item removals price from the standalone list regardless of truck volume; add 75 for a carry over 50 feet; add 50 per flight of stairs; the phone quote holds unless access is materially different from what was described" — that answers the next hundred variations, and it can be handed to a new estimator.

Write rules the way you would explain them to a competent new hire who is standing next to you: the base case, the common modifiers, and the exceptions that trip people up. Include the judgment calls explicitly — "hold firm on the in-person estimate when," "honor the phone quote when" — because the judgment calls are exactly what people cannot guess.

Step 3: Put it where people already look

A rule nobody can find is a rule nobody follows. It does not matter much whether that is a shared doc, a binder in the truck, or a wiki — what matters is that it is one place, it is current, and people know to check it before calling you.

This is where most attempts stall. The document gets written, it goes stale, nobody trusts it, everyone goes back to calling. Keeping it current has to be somebody's explicit job, and updates have to be easy to make the moment a rule changes.

Step 4: Make it answer questions, not just store them

A twelve-page pricing document is still work to search mid-job. The next step up is making that knowledge queryable — so a crew lead can ask "what do we charge for a hot tub with a long backyard carry" in plain language and get your answer, pulled from the document you already wrote, with a pointer to the section it came from.

That is what a private business AI is for. Not a customer chatbot — an internal tool that holds your pricing logic, your vendor map, and your procedures, and answers the crew's questions from that material instead of from a general-purpose model's guesswork. Xandite is built for exactly this: an isolated workspace per business, your documents ingested once, answers grounded and cited, and in production nothing real sent to a public AI service.

The point is not to remove your judgment from the business. It is to record it once so it scales past your phone.

What to expect

The first month is mostly writing things down, and it feels slow. The payoff shows up when you are away for a day and the job does not stall — someone looked it up. Then you notice the interruptions dropping, and you get the clusters you have not documented yet done because you finally have the time.

Related guides

Questions about whether this fits your business go to the founder directly.

Frequently asked questions

How do I figure out what my team keeps interrupting me for?
Run a one-week log. Every time someone asks you something they could not answer on their own — by phone, text, or in person — write it down, and do not try to fix anything yet. By the end of the week most owner-operators have thirty to fifty entries, and they cluster into four groups: pricing questions, vendor and parts questions, scheduling and dispatch calls, and policy or judgment calls. Count the tally marks in each cluster; the group with the most marks is the one costing you the most time and the one to document first. The log also gives you the raw material for the documentation itself, because each entry is a real question phrased the way your staff actually ask it — which is exactly how it should read when you write the answer down as a rule.
Should I write down the answer or the rule behind it?
Write the rule. Answering the specific question — "charge 450 for that" — helps once. Writing the rule that generates the answer — how single-item removals price, what a long carry adds, what a flight of stairs adds, when a phone quote still holds — answers the next hundred variations and can be handed to a new estimator. Write each rule the way you would explain it to a competent new hire standing next to you: the base case, the common modifiers, and the exceptions that trip people up. State the judgment calls explicitly as "do X when Y", because the judgment calls are the part nobody can guess. The few extra minutes it takes to generalise a rule instead of answering once is the whole return on the exercise.
Where should this documentation live so people actually use it?
In one place, kept current, that people know to check before calling you. Whether that is a shared document, a wiki, or a binder in the truck matters far less than it being single, current, and findable. Most attempts stall here: the document gets written, it goes stale, nobody trusts it, and everyone goes back to calling. Two things prevent that. First, keeping it current has to be one named person's explicit job, not a shared intention. Second, edits have to be a thirty-second task, because if updating it is a chore it will not happen the day a rule changes. A private internal AI on top of that document raises the odds further, because staff can ask a plain-language question and get the answer with a citation instead of searching twelve pages mid-job.
How is a private AI different from just having the document?
The document stores the knowledge; a private internal AI makes it answerable. Instead of scrolling a twelve-page pricing file on a phone between stops, a crew lead asks "what do we charge for a hot tub with a long backyard carry" in plain language and gets your answer, pulled from the document you already wrote, with a pointer to the section it came from. It is an internal tool for the owner and crew, not a customer chatbot or a lead-capture widget. A genuinely private setup keeps each business's documents in an isolated workspace and, in production, does not send that material to a public AI service. The document is still the source of truth and still has to be maintained; the AI removes the friction of finding the right paragraph while a customer is standing in front of you.