I’ve worked with over 70 service businesses on their operations. Most CEOs invest heavily in technology and AI to optimize delivery.
But in many cases, the return on investment is unclear at best. Often, it doesn’t show at all.
Here’s my approach to getting real ROI from AI and automation in service delivery.
Why use technology in service delivery
Service doesn’t scale. Traditionally, more revenue meant more staff. The ratio was fixed.
On top of that, human delivery capped the ability to process large amounts of data.
Service CEOs push on technology and AI for one of three reasons:
Increased Output Quality
Most service businesses operate in competitive markets. Better outputs mean a competitive edge. AI lets you analyze data that was previously opaque and deliver stronger results.
Profitability
Technology in delivery promises higher efficiency. That translates into better gross margins. An automated workflow is cheaper than a human doing the same task — if done well. We’ll get to that. Done right, this moves your financial mechanics closer to a SaaS business.
Scalability
Efficiency also means scalability. AI and technology let you service more clients with the same team.
Why your AI and tech rollout doesn’t produce ROI
In my experience, AI and tech fail to produce ROI for one or more of these reasons.
No clear strategy
Technology adoption doesn’t follow a clear strategy. You end up with fragmented initiatives scattered across your delivery process. They’re hard to manage and have little impact.
Without a clear goal, you can’t optimize for anything. Worse, you might be adding technology to the wrong parts of the process entirely.
Broken processes
If you apply technology to a broken process, you just speed up the chaos.
No baseline
Without a clear baseline of the metrics you’re trying to improve, you won’t know if you’ve succeeded.
Your business changes over time. Technology doesn’t get implemented in a lab. Other moving parts will skew your view of its impact.
Incomplete or poor builds
Many AI and tech implementations I’ve seen were never finished. Or the team gave up on iterating before the tool reached a point where it actually works.
No roll-out management
I often see tools launched without training or feedback loops. Adoption then becomes a coincidence, not a predictable result.
Impact of AI in service delivery on your P&L
Your P&L in a service business looks like this:
Revenue – Cost of Goods Sold = Gross Margin
Gross Margin – Operating Expenses = Operating Income
Delivery cost lives in Cost of Goods Sold. Lower delivery cost means higher Gross Margin.
Technology cost lives in Operating Expenses. So investments in AI and tech will push that line item up.
Ultimately, Operating Income tells you whether revenue or margin gains offset your tech investments.
If gross margins go up but OPEX goes up more, that’s a problem. You can tolerate that briefly. But don’t fall into the trap of writing off OPEX increases as “investments in the future.”
You need to retain strong margins while you build the tech.
There’s another problem. Operating Income is too high-level and too lagging to tell you where tech is working and where it isn’t. That’s why you need the process I describe next.
How to make ROI of AI and tech real
Here are the steps I follow with clients to make AI and tech investments pay off.
Step 1: Decide on your goals
Get crystal clear on your goal. Is it enhanced outputs and client experience? Profitability? Scalability?
These are strategic questions, driven by your positioning. What do you want to be great at? What’s secondary?
Below, I’m focusing on efficiency-related goals. Outcome-related goals vary too much by industry and strategy to describe a standard process.
Step 2: Select the KPIs you’re optimizing for
Find the KPIs that represent your goals.
For outcomes and client experience, the options are tricky. Most are qualitative (client feedback), lagging (client satisfaction), or indirect (conversion rates from an enhanced offer).
For efficiency, two KPIs matter most.
Cycle time
Cycle time is the time it takes to complete a task or process step from start to finish. It tells you how long a specific piece of work takes.
Throughput
Throughput is the number of tasks your team completes in a given time period.
Step 3: Map your process and baseline
Map your entire delivery flow. Go granular enough so each step has one owner. A spreadsheet works fine.
Then write down the cycle time for each step. Add them up to get your total process cycle time.
If the total is lower than the real elapsed time, there’s waiting time hiding in the process. Eliminating that should be a priority too — but it doesn’t always require technology.
Also measure throughput per step. This is harder and you may need to measure it per person. But it’s how you find bottlenecks.
Example: if one step has a throughput of 5 but the next step only has a bandwidth (available capacity) of 4, then your total throughput is capped at 4.
A note on time tracking
Your input for cycle time is time-tracking data. In every service business I’ve worked with, time tracking is inconsistent. It’s always a problem.
Ideally, you track time at the same granularity as your process map. In practice, that’s often too complex. Compromise at a level that still lets you draw conclusions about your sub-steps.
If you don’t have tracking data yet, start with estimates from your team. Begin tracking now and replace estimates with real data as you go.
Step 4: Select the tasks to use technology for
Two types of tasks are the obvious candidates:
- Tasks with the highest cycle time
- Tasks with the lowest throughput
These will have the highest impact. Rank them from highest to lowest cycle time or biggest to smallest bottleneck.
Next, assess feasibility. How hard is it to automate each one? A rough estimate — high, mid, or low effort — is enough. Add that as a column.
Now you have impact and effort mapped. By default, pick high-impact, low-to-mid effort tasks first. But sometimes a high-effort item is worth it.
One rule: don’t start with low-impact tasks just because they’re easy.
Step 5: Execute like a product team
With scope selected, move into execution. Treat your tech implementation like a product.
Collect all items in a backlog. A Kanban-style board works best.
You need at least two roles.
A Product Manager who defines what to build and to what specifications. This should be someone from your delivery team who knows the process step best.
An Engineer who builds it. This can be an internal team member or an external AI & automation agency.
The Product Manager writes or updates the SOP for the task. This serves as the requirements doc. It needs to be enhanced with strict decision-making and human-in-the-loop rules.
Define a sprint length — a fixed interval of one or two weeks. In each sprint, the Engineer builds against the defined requirements.
The flow is:
- The PM writes the requirements (SOP etc.) and adds them to the Kanban ticket.
- The Engineer reviews, clarifies questions, and estimates the workload.
- Together, they define the sprint backlog: what gets built in the upcoming cycle. This happens before the sprint starts. Tickets may need to be broken into smaller pieces.
- The Engineer builds against the defined requirements.
- At the end of the sprint, the PM reviews. This can double as the next sprint’s planning meeting. They also use it to address collaboration issues.
- The new tech goes into testing. Results feed back into the backlog.
A few notes from experience:
- You’ll likely have multiple items in progress at once. Sprint planning is crucial — it decides what gets built next.
- Reserve 20% of each sprint for bug fixes. Small issues need to get resolved quickly.
- It takes time for PMs and Engineers to align. Writing specs that are clear enough and sized right for a sprint is a skill that develops over a few cycles.
Step 6: Roll out, track progress, improve
This is the most important step. This is where the ROI becomes real.
Schedule a weekly meeting with your delivery team covering three things.
Roll-out
Share progress and new features with your team regularly. Match the cadence to your sprint cycle. Include training as needed.
Track progress
Update your process map with fresh cycle times and throughput data every week. This is non-negotiable.
After rolling out new tech, cycle times should drop. If they don’t, troubleshoot. Is the tech not working? Are people now doing things they used to skip because they had no time?
Tracking impact over time is how you prove ROI.
Improve
Include your full delivery team in this meeting — or the relevant sub-group. PMs for specific features will naturally be part of it.
Capture user feedback from your delivery team and funnel it back into the backlog. Small fixes go into that 20% sprint buffer. Bigger enhancements get a new ticket.
As a rule: focus on as few features as possible at a time. Iterate, finish, then move on.
If you follow these steps — and don’t skip this last one — you should see real results from your AI and tech investments.
