Automate the Repeatable, Reserve Yourself for the Real Decisions
A guest emails at 11:40 on a Friday night asking if the fire pit can be lit before they arrive Saturday morning. The reply goes out in ninety seconds: yes, it will be ready, here is the check-in code, here is the number if anything is off. No one wrote that email. A workflow did, triggered by a keyword, pulling from a template built weeks earlier.
The same week, a wedding planner writes asking whether the property would consider hosting sixty guests instead of the usual thirty, for a rate the planner proposes herself. No workflow answers that one. It sits until Marco reads it, thinks about it, and answers it himself.
Two messages. Two different kinds of decision. The difference between them is the whole discipline.
The Convenient Lie Owners Tell Themselves
Most owners describe their use of automation in one of two ways, and both are a little dishonest.
The first version: "We automated the business." Said with pride, as if the system now runs itself. It doesn't. It runs the parts that were never actually judgment calls to begin with, and the owner is still making every decision that matters, just faster and with less visibility into how much they're still doing.
The second version: "We still do everything by hand, because our business is too relationship-driven to automate." Said with equal pride, as if manual effort were itself the mark of quality. Usually what's happening is the owner hasn't sorted out which parts of the relationship are actually the relationship, and which parts are just repeated administrative motion wearing a relationship costume.
Both versions skip the actual work: going through the business decision by decision and asking, honestly, does this one require me.
Most owners have never actually separated what requires them from what merely used to be done by them.
Where the Line Actually Sits
The useful test isn't complexity. Plenty of complicated tasks are entirely repeatable, and plenty of simple ones aren't.
The real test is whether the decision has a knowable rule behind it, one that doesn't change from case to case, versus whether it requires weighing something new every time: who this person is, what they're really asking for, what it costs you if you get it wrong.
At the ranch, guest marketing and CRM ran through GoHighLevel: booking confirmations, pre-arrival check-in instructions, review requests, follow-up sequences for past guests, nurture emails for people who inquired but didn't book. All of it followed a rule that didn't change. A guest who books gets sequence A. A guest who inquires and goes quiet gets sequence B. None of that needed Marco's judgment on a given Tuesday, because the judgment had already been made once, correctly, when the sequence was designed.
What never got handed to the system: who the property would work with at all. A retreat organizer wanting a discount in exchange for exposure to her list. A production company wanting to shoot commercial content on-site for two days. A near-duplicate of last year's bachelor party, this time with a group that didn't inquire the same way, didn't ask the same questions, didn't feel the same on paper. Positioning, pricing exceptions, and the read on who is a good fit for what the property actually is, none of that has a stable rule behind it. It changes with the specifics every time, which is exactly why it can't be delegated to something that only knows how to apply a rule.
The specialty valve business ran on the same split, just dressed differently. The quoting system enforced business rules automatically: pull historical pricing for a given SKU, generate an instant quote, send it before a competitor could finish waiting on the manufacturer to respond. Purchasers are lazy in a specific, predictable way. They'd rather issue the PO to whoever answered first than sit on their hands comparing three quotes that all arrive a week apart. Speed was the whole edge, and speed is exactly the kind of thing a system does better than a person, because a system doesn't hesitate.
Speed is a rule. Judgment is not, and the two should never be assigned to the same owner of the decision.
But the system never decided which manufacturer relationship was worth protecting at the cost of a faster quote, or when a customer's request fell outside the historical pattern and needed a human to actually look at it. Those decisions stayed put. The system handled the repeatable arithmetic of pricing. It never touched the judgment of who the business actually wanted to be doing business with.
The Cost of Getting the Split Wrong
Get the split wrong in one direction and the owner burns out doing arithmetic a machine could have done at 2 a.m. without complaint. Get it wrong in the other direction and the owner hands a system a decision it was never built to make, and finds out only when a guest who should have been turned away shows up, or a quote goes out to a customer the business never should have raced to win.
The MisterArt scanners are the cleanest version of this, because the stakes were purely operational. A paper pick list in the wrong order is a repeatable-decision problem wearing a crisis costume. The fix wasn't a judgment call made faster. It was recognizing the decision never required judgment at all, just a system that could route a picker and confirm each pick against the shelf and the UPC before the next spike hit.
A crisis that repeats the same way twice was never a judgment problem. It was a system nobody had built yet.
Where to Look First
Go through the business decision by decision, not function by function. A function like "guest communication" or "quoting" is never uniformly automatable or uniformly not. The individual decisions inside it are.
- Ask where the rule never changes. If the same inputs always produce the same right answer, that decision belongs to a system, not to you.
- Ask where the rule changes with the person. If the right answer depends on who's asking and what they actually want, it stays yours.
- Ask what happens if the system is wrong. A wrong autoresponder is an annoyance. A wrong pricing exception is a relationship. Match the tolerance for error to what you automate.
- Ask whether speed itself is the edge. If being first matters more than being deliberated, build for speed and let the system win that race for you.
- Ask whether you're still doing something because you always have. Not because it requires you now, but because no one has looked at it since it stopped being a judgment call.
The job was never to automate the business. It was to find the handful of decisions only you can make, and build everything else so it never reaches your desk.
Do that well and the business gets faster without getting less careful. Do it poorly and it just gets faster at being wrong.