Playbook
Modernize your operations: how to update how your business runs without breaking what works
Modernizing operations is not about technology. It's about replacing invisible, person-dependent processes with visible, system-dependent ones — then adding the right technology at the right time.
1. What history teaches us
Walmart did not modernize by adopting retail technology. It modernized by first understanding its operations at the level of individual stores, individual routes, and individual products — and then building or buying the technology that served those specifics.
UPS did not improve its routing by deploying an algorithm. It improved by first spending decades mapping the actual paths its drivers took, measuring the time each step required, and building a dataset of route performance that the ORION algorithm could optimize. The technology worked because the data existed. The data existed because the measurement habit came first.
FedEx did not build its hub-and-spoke network because it had the capital. It built it because Fred Smith understood the specific problem — overnight delivery reliability — and worked backwards to the infrastructure required. The technology served the concept, not the reverse.
In each case, modernization followed the same sequence: understand the current state in detail, identify the specific gap, build or adopt the tool that closes the gap, and measure whether it worked.
2. Business examples
The car dealership that documented first: A regional auto group with four locations was losing customers between the first inquiry and the first test drive. The operators assumed the problem was the sales team. An audit of the inquiry-to-appointment process revealed that 40% of web inquiries received no response within 24 hours because no one had clear ownership of online leads. The fix was not technology — it was a documented process assigning ownership. Response time dropped from an average of 28 hours to 3 hours. Appointment rate increased by 31%.
The restaurant group that measured before automating: A restaurant group with eight locations wanted to reduce food waste. Before buying an inventory management system, they spent six weeks manually tracking waste by category at two test locations. The data revealed that 60% of waste came from three ingredients. They adjusted ordering quantities manually first, reducing waste by 40%. They then bought the inventory software — and had real baseline data to configure it correctly.
The HVAC company that sequenced properly: A residential HVAC company with 12 technicians was considering a field service management platform. Before committing, the owner documented every step of the scheduling, dispatch, and invoice process on paper. The documentation revealed three handoff points where information was lost — places where a verbal instruction was given that was not recorded. They fixed the handoffs first, with simple shared documents. Six months later, when they adopted the software, implementation took three days instead of the three weeks their software vendor had predicted.
3. The common SMB problem
Most small business modernization efforts fail for the same reason: they adopt the technology before documenting the process. The result is a digital version of an undocumented, person-dependent process — which is worse than the original because it is now also vendor-dependent and more expensive.
A CRM that no one uses because the sales process was never documented. A scheduling system that creates confusion because the handoff rules were never agreed upon. An accounting platform that produces inaccurate reports because the chart of accounts was set up by a software vendor who did not understand the business model.
The technology is not the problem. The sequence is.
4. Practical steps
Step 1: The operations audit. Spend two weeks asking every person on your team: "What do you do that only works because you specifically are doing it?" The answers are your invisible process inventory. Write them down.
Step 2: Prioritize. Rank each invisible process by two dimensions: frequency (how often does it happen?) and risk (what happens if it breaks?). The high-frequency, high-risk processes are your immediate priorities. The low-frequency, low-risk ones can wait.
Step 3: Document before you modernize. For each priority process, write the standard as it should work, not as it currently works. This is the spec you're trying to achieve. Include the input, the steps, the output, the owner, and the metric.
Step 4: Fix the process before buying the tool. Test your documented process manually for four weeks. If it works, you've already improved the operation. If it doesn't, you now know what's wrong — and you can specify what a technology solution would need to do.
Step 5: Buy the tool that solves the documented problem. The RFP for any technology purchase should include your documented process and your current manual metric. The vendor should show you how their tool improves that specific metric. If they cannot, their tool is not the right fit.
5. Tools and technology categories
Documentation: Notion, Google Docs, Confluence. The format matters less than the discipline. A shared Google Doc that is actually used beats a Notion workspace that is beautifully organized and never opened.
Communication and handoffs: Slack, Teams, or any platform that creates a searchable record of decisions. The goal is to replace "I told you verbally" with "I sent it in writing, you confirmed." This alone eliminates a large fraction of operational errors.
Task and project tracking: ClickUp, Asana, Monday.com, or Linear. Best for processes with multiple steps and handoffs across more than one person. Not necessary for single-person tasks.
Field service: ServiceTitan, Jobber, Housecall Pro (for home services and trades). These are mature platforms that have solved the scheduling/dispatch/invoice loop for their specific verticals.
Inventory: Lightspeed, Square for Retail, or industry-specific tools. Configure after you have documented your ordering and reorder processes manually.
6. Questions to ask before scaling
- Is the process you are trying to modernize documented well enough that a new hire could learn it from the documentation alone?
- Have you measured the current state? Do you have baseline metrics to compare against after the change?
- Have you run the process manually, according to the new standard, long enough to know it works?
- Does the technology you are considering solve a specific, documented problem — or does it solve a general problem you have not yet documented?
- Who will maintain the documentation and the technology after implementation? Is that person identified and trained?
Modernization that passes these five tests tends to succeed. Modernization that does not tends to create new forms of the old problem.
The Owl Brief
One story. One growth lesson. One practical idea — every Sunday.
No spam. Unsubscribe any time.


