Step one: count the work, not the people

The common mistake is saying this needs three people. What matters for the decision isn’t headcount but how many hours go into it. If 3 people spend 1 hour a day on it over 22 working days, that’s 66 hours a month on that one process.

Step two: cost the current state

A simple formula: people × hours × working days. But don’t stop at time; human error, delay, lost sales opportunities, slow customer replies, rework and dependence on one person are costs too - and sometimes matter more than the labour cost itself.

Step three: build the after-state

Instead of AI will do this, be precise: e.g. AI does the first-pass processing and a human reviews and decides. Do not expect the entire current cost to vanish at once; find out how many hours actually come off.

Step four: cost the real solution

The initial build price is only one cost. Add infrastructure, maintenance, dependent third-party services, and training the team to use it. Real cost = build + infrastructure + maintenance + dependent services.

Find the break-even point

If the build costs 60 million toman and the system creates 10 million toman of value a month, break-even is roughly six months (60 ÷ 10). That number only means something if the 10 million is defensible; ROI should be estimated before building, not calculated after buying.

Freed time isn’t always cash saved

If a system frees 40 hours a month, that doesn’t automatically mean 40 fewer hours of pay; the same person might spend that time on sales or customers instead. Before calculating, decide the goal: lower cost, more capacity, more speed, fewer errors, or a mix.

Do not measure everything in money

24-hour response may not cut labour cost, but it saves a customer from waiting until tomorrow. Reducing dependence on one person lowers operational risk. Look at the result across categories: cost, time, capacity, error, risk, customer experience.

Watch for this trap

If AI can do it, we should is one of the most dangerous assumptions in AI projects. The process might not repeat enough, the build might cost too much, or a simpler fix might give the same result. In that case, the best decision may be not to build.

A simple example

If a salesperson reviews 30 similar requests a day at 5 minutes each, that’s 2.5 hours a day, about 55 hours a month. If a system can handle 80% of that without direct involvement, roughly 44 hours a month are freed. The real question: what is that time worth?

A decision worksheet

  • Process: what should get better?
  • Frequency: how often per day or month?
  • Time: how long each time, and how many people?
  • Cost: what is that time worth, and what does an error cost?
  • Solution: exactly which part does the system handle, and what does it cost?
  • Break-even: how long until the project pays for itself?

If you can’t fill this out, it’s probably too early to buy or build.

Conclusion

AI should not be measured by how many tools you’ve bought. A system is valuable when it solves a real problem at a reasonable cost and risk. So before asking which tool to buy, ask: what does this problem cost us right now? and then: when will the new solution pay that cost back?