The first saved hour is hiding in the boring work
I help small and mid-sized businesses around the Atlanta metro and North Georgia put AI to work. Manufacturers, skid builders, service shops, the kind of operation where the owner knows everyone's name. Different industries, same first question every time. Where do we even start.
The honest answer surprises people. You do not start with the impressive thing. You start with the boring thing you do forty times a week.
Here is the field-note version of how I think about it, written for an owner who is not technical and does not want to become technical.
Find the work you repeat, not the work that sounds smart
When an owner asks what to automate first, the instinct is to name the flashy project. A chatbot on the website. A tool that predicts demand. Something that sounds like the future.
Skip it. The first saved hour almost never comes from the smart project. It comes from the high-frequency grind nobody enjoys.
Look at where your team's hours actually go:
- Quoting. Someone reads an inbound request, pulls the right numbers, formats a quote, sends it. Ten times a day. The same shape every time.
- Document drafting. Proposals, work orders, spec sheets, follow-up letters. Mostly copy-paste with the details swapped.
- Data entry. Moving a number from an email into a spreadsheet into a system. A human acting as a courier between two screens.
- Follow-ups. The customer who got a quote and went quiet. The invoice that is two weeks late. The reminder that never goes out because everyone is busy.
None of that is exciting. All of it is frequent and rule-shaped, which is what makes it the right first target. A task you do forty times a week, even shaved by ten minutes each, gives you real hours back this month. A task you do twice a year was never worth the build.
The math is simple. Count how often the task happens, multiply by the minutes a tool would save, and start with whatever wins that multiplication. Novelty does not enter the equation.
Build one tool that ships, not a pilot that dies
This is the part most AI projects get wrong, and it is worth being blunt about it.
A lot of "AI initiatives" end as a slide deck and a demo that worked once in a meeting. Everybody nods. Nothing reaches the people doing the actual work. Three months later the demo is forgotten and the team is still copy-pasting quotes by hand. A pilot nobody touches on a Tuesday afternoon still cost you the money and the calendar time it ate.
So the bar I hold is plain. The first project has to ship to production. A real tool, used by a real person on real work, this week. Not a proof of concept. Not a roadmap. A thing that takes the quote request that just landed and turns it into a draft quote your estimator edits and sends.
That changes how you scope the first build. You do not try to automate all of quoting. You take the single most common quote type, the one that comes in over and over, and you build the tool that handles that one cleanly. It works on the first day. Your team feels the hour come back on the first day. Then you widen it.
A small thing that shipped earns the next build. A big thing that stayed theoretical earns nothing, because your team never felt it work.
Show the team a finished tool, not homework
There is a fork in the road here, and the wrong branch wastes everyone's money.
The wrong branch is handing your team a stack of prompts and saying "go run these in ChatGPT." That reads as homework. It hands the work back to the people who are already busy, and most of them will quietly stop after a week. I have watched it happen. A worksheet of clever prompts is just a to-do list with extra steps wearing a tool costume.
The right branch is building the actual tool and putting it in front of them finished. They open it, they use it, it does the job. The proof is the working thing in their hands, not a set of instructions for building it themselves later.
For an owner deciding how to spend a consulting dollar, that is the line to watch. Are you paying for advice you then have to execute, or are you paying for something that arrives built. The second one is the only one that moves your week.
The team has to be able to run it after I leave
This is the rule that separates a real engagement from a dependency trap, and it matters most for a small business that cannot keep a consultant on payroll.
Some setups are built so that only the consultant understands them. The moment that person walks out the door, the tool rots. Now you are paying a retainer forever just to keep the lights on. That is a bad deal dressed up as a relationship.
The way I work the opposite direction is to build alongside your team instead of disappearing and delivering. Your estimator drives. I coach. The tool comes out of sessions where your own people watch it get built and put their hands on it. By the time the engagement ends, the person who uses the tool every day understands how it works and can adjust it.
The test is simple. If I vanished tomorrow, could your team keep using and tweaking what we built. If the answer is no, the project was built wrong. The capability has to stay in your building, not in my head.
I saw this play out with an Alpharetta manufacturer. We built a tool together over a few days. By the end their senior engineer had taken it over, set it up on a shared machine, and had other people feeding work into it. That is the outcome you want. The consultant leaves and the capability stays.
A simple order of operations for an Atlanta-metro owner
If you run a small or mid-sized business in the Atlanta metro, North Georgia, or anywhere up the I-985 corridor, here is the order I would actually follow.
- Watch one week. Notice the task your team groans about and repeats daily. Quoting, drafting, data entry, follow-ups. The boring high-frequency one.
- Pick the single most common version of it. Not the whole category. The one specific shape that comes in over and over.
- Build one tool that handles that shape, end to end, in production. It has to work on a real request this week, used by a real person.
- Make sure your own people drive it. If only the outside expert can run it, you bought a dependency, not a capability.
- Measure the hour. Count the minutes it saved. That number tells you what to build second.
Everything fancy comes later, and it comes easier, because by then your team trusts the approach and you have real hours back to fund the next step.
Where to start
Forget the AI strategy for a minute. What moves your week is one boring, frequent task handled by one working tool your team can run without you.
If you want to figure out which task that is for your business, the Discovery engagement is built for exactly that. A few days of watching how your team actually works, then building the first tool together. The full approach lives on the AI consulting page. If you would rather see how I think about building durable systems first, the typed-wiki brain is the long read.