The process is the product

A lot of automation work for small Indian businesses starts the same way: the client describes a clean process, and then you watch the actual process for a week and it looks nothing like the description.

The real one runs on WhatsApp threads, a couple of spreadsheets, and one person who remembers how things are actually done. Steps are conditional on context nobody wrote down. The "system of record" is whichever chat the founder last checked. This isn't dysfunction; it's how a small team moves fast without process overhead. But it means you can't automate the described process, because it doesn't exist.

So the first deliverable on these engagements isn't code. It's a written account of how the business actually operates, fed back to the client until they agree it's right. That document is where the value is. Half the time, writing it down surfaces a bottleneck the client can fix without any software at all.

What I've learned to do differently:

• Start by shadowing, not scoping. The scoping call describes the ideal. The week of watching describes the real thing.
• Automate the stable core, leave the edges to people. The 20% of cases that don't fit are where a bad automation destroys trust fastest.
• Make the rules a config the client owns. Anything that encodes "how we qualify a lead" or "when we escalate" will change within weeks. If it's in the code, you're back every month.

The technical work is real, but it's downstream. The hard, valuable part is understanding a messy process well enough to know which parts should never be automated.