DEV Community: Archit Mittal

My AI Agent Lost a Client: A Post-Mortem on Automation Without Guardrails

Archit Mittal — Wed, 16 Sep 2026 02:45:05 +0000

An AI agent I built sent a series of chasing messages to a customer who had already paid. The customer was a long-standing account for my client, they had settled the invoice by NEFT, and the agent kept asking for money that was already in the bank. By the time anyone realised, the relationship had cooled to the point where the customer moved a chunk of their ordering elsewhere.

I built the thing. Nobody else is to blame for it. What follows is what actually happened, why the failure survived long enough to do damage, and the specific guardrail I now put into every system of this kind.

What the system was supposed to do

The client is a distributor. Orders come in through WhatsApp and email, invoices go out from Tally, and payments arrive by NEFT, cheque and occasionally UPI. Their real problem was not order taking. It was collections. Their accounts person spent a large part of every week manually working through an ageing report and sending polite reminders to buyers who had drifted past their credit period.

The brief was narrow and sensible: read the ageing report, decide who needs chasing, draft a message in the right tone for each buyer, and send it on WhatsApp. Escalate the tone the longer the invoice sits. Stop chasing when the invoice is paid.

That last clause is where everything went wrong.

What the agent actually did

The system pulled outstanding invoices from an export of the ageing report. It classified each one into a bucket by days overdue, picked a message template, personalised it with the buyer's name, invoice number and amount, and pushed it out. It logged every send. It handled replies by routing them to a human if the reply contained anything that looked like a dispute.

On paper, this is a well-behaved agent. It had a clear input, a bounded decision, and a human handoff for anything contested.

The failure was in the input. The ageing export was generated on a schedule and dropped into a folder the agent read from. When the export job failed, which it did quietly on a day the accounting machine was restarted, the agent read the previous file. Not a blank file, not an error. A perfectly valid, perfectly formatted, slightly stale file.

So the agent did exactly what it was told. It looked at invoices that were, as far as its data said, still unpaid. It escalated the tone according to the days-overdue figure, which kept climbing because the timestamps were being compared against the current date. And it sent a firm, then firmer, then quite cold message to a buyer who had paid on time and had a receipt to prove it.

The buyer replied once, saying they had paid, with the UTR number. That reply contained the words "already paid", which the dispute classifier did not treat as a dispute because it was looking for words like "wrong", "incorrect", "not ordered". So the reply was logged and not escalated. The agent sent the next scheduled message two days later.

Why nobody caught it

This is the part that matters more than the bug itself.

The system was working. That was the problem. It had been running for weeks, doing a job that everyone was relieved to stop doing manually. The dashboard showed messages sent, replies received, invoices marked closed. Nothing on that dashboard turned red, because from the system's point of view nothing had gone wrong. A stale file is not an error. A reply that does not match a keyword list is not an error. An escalating tone on an invoice that the data says is ninety days old is not an error, it is the designed behaviour.

The accounts person did not catch it because she had been moved off collections. That was the whole point of the project. She was not reading the outbound messages any more, and there was no reason for her to.

The owner did not catch it because owners look at outcomes, and the collections numbers looked fine. Money was still coming in. One buyer going quiet does not show up in a weekly figure.

The buyer did not escalate because Indian business relationships often do not work that way. They did not call and shout. They sent one message, got a machine-sounding reply, concluded that the relationship had changed, and started splitting their orders with a second distributor. Nobody found out until the sales person noticed the drop in reorder volume and asked why, at which point we went back through the WhatsApp log and read the whole exchange in a very quiet room.

The lesson: the automation did not fail loudly. It failed politely, on schedule, in perfect formatting, for days. That is the most dangerous failure mode there is, and it is specific to automation. A human making the same mistake would have felt something was off by the second message.

The guardrail that would have stopped it

One thing. Not an AI thing.

Freshness checks on every input the agent trusts. The agent should have refused to run if the ageing file was older than the run interval. Six lines of logic: read the file's modification timestamp, compare it against the expected schedule, and if it is stale, do nothing and alert a human. No messages sent. No clever fallback. Just stop.

This is unglamorous, and it is the thing that separates automation that survives contact with a real business from automation that demos well. Every agent has inputs it did not generate and cannot verify. The question you must answer for each one is: how would this system know if this input were wrong?

There were two secondary guardrails I should also have had, and now do:

A confirmation step on escalation. The moment a message's tone changes from reminder to demand, a human should see it before it goes. Not every message. Just the ones where the system is about to spend relationship capital. In this case that would have been perhaps a handful of messages a week landing in front of the accounts person, which is a trivial cost against what it protects.

Reply handling by intent, not keywords. "Already paid", "payment done", "I sent it last Tuesday", "check karo, transfer ho gaya hai" all mean the same thing and share no keywords. This is genuinely a job for a language model, and I had one available in the system and did not use it at that point because keyword matching was cheaper and I did not think that path mattered. It mattered.

The part where I tell you not to automate something

Collections should not be fully automated. I do not mean it needs better guardrails. I mean the send decision should stay with a person.

Here is the distinction that took me an expensive lesson to arrive at. Automate the work that produces the decision. Do not automate the decision itself when the cost of being wrong is borne by a relationship rather than by a process.

Filing GST returns is a process. If the automation makes a mistake, you find out from a mismatch report, you file a correction, and the counterparty is a system that does not hold a grudge. Automate that end to end, gladly.

Chasing a buyer for money is a relationship. If the automation makes a mistake, you find out months later from a sales figure, and you cannot file a correction against how someone now feels about doing business with you. The right build is: the agent reads the ageing report, drafts every message, ranks them by urgency, and presents them to a person who spends a few minutes a day pressing send or not. That still removes the great majority of the labour. It just keeps a human at the exact point where judgement is worth something.

The same rule applies to a few other things owners keep asking me to automate. Anything that says no to a customer. Anything that touches an employee's money or standing. Anything sent to a person who is already unhappy. The efficiency you gain is small and the failure cost is uncapped.

The uncomfortable truth is that the automation industry, myself included at times, is incentivised to tell you the opposite. Full automation is a better story and an easier thing to sell. A system where a person still presses a button sounds like a half-measure. It is not. It is the design.

What I would tell you to do this week

Take the automation you already have running, the one you have stopped watching because it works. Open its logs and read the last twenty things it actually sent or did. Not the summary, not the dashboard, the actual output.

Then, for each input that system depends on, write down one line: how would this system know if this input were wrong or stale? If you cannot answer for an input, that is your next piece of work, and it will take a fraction of the time the original build did.

If you only do one of those two, do the first. Read the output. Most bad automation failures are visible in the output long before they are visible in the numbers, and almost nobody looks, because looking feels like the thing you paid to stop doing.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

AI Automation in India: Complete Guide (2026)

Archit Mittal — Tue, 15 Sep 2026 12:45:06 +0000

Why I Wrote This Guide

Over the past year, I have helped Indian businesses automate over 40 workflows, cut operational costs by lakhs, and free up teams from repetitive work that was draining their productivity. The most common question I get from founders and CTOs across India is simple: "Where do I start with AI automation?"

This guide is my answer.

I am going to walk you through everything — what AI automation actually means, why the Indian market is uniquely positioned for it, which tools are worth your time, real cost savings with real numbers, and a step-by-step implementation plan you can follow this week.

No theory. No vague predictions. Just what works, what it costs, and how to do it.

What is AI Automation?

AI automation is the practice of using artificial intelligence to handle tasks that previously required human effort — data entry, customer responses, report generation, content creation, lead qualification, invoice processing, and dozens of other workflows that eat up hours every day.

But here is what most people get wrong: AI automation is not about replacing your team. It is about removing the work your team hates doing so they can focus on what actually moves the business forward.

Traditional automation (simple if-this-then-that rules) handles predictable, structured tasks. AI automation goes further — it handles tasks requiring judgment, language understanding, and decision-making. When a customer emails a complaint, traditional automation routes it to a folder. AI automation reads the email, classifies the issue, drafts an appropriate response, and escalates to a human only when genuinely complex.

The difference is not incremental. It is transformational.

The Three Layers of AI Automation

In my experience working with Indian businesses, AI automation typically operates at three levels:

Layer 1: Task Automation — Individual repetitive tasks. Generating product descriptions, summarizing meeting notes, extracting data from invoices. These are quick wins with immediate ROI.

Layer 2: Workflow Automation — End-to-end processes. A new lead comes in, gets qualified by AI, the CRM is updated, a personalized follow-up email is sent, and the sales team gets a Slack notification with a summary. Multiple steps, multiple tools, one automated flow.

Layer 3: Decision Automation — AI makes or recommends decisions based on data. Pricing optimization, inventory reordering, customer churn prediction. This is where the serious competitive advantages live.

Most Indian businesses I work with start at Layer 1, see results within the first week, and quickly move to Layer 2. Layer 3 requires more data infrastructure, but the businesses that get there see the biggest returns.

Why India is Ripe for AI Automation

I have worked with businesses across multiple markets, and India has a unique combination of factors that make AI automation not just useful but essential.

The Cost Advantage is Real

India's tech talent is world-class but not cheap anymore. A competent operations manager in a Tier 1 city costs ₹6-8 lakh per year. A small ops team of three people runs ₹18-24 lakh annually. When AI automation can handle 60-70% of their routine work, you are not eliminating jobs — you are making each person three times more productive. That ₹18 lakh team starts delivering ₹50 lakh worth of output.

I documented exactly this kind of cost reduction when I helped a client save ₹85K per month on their AI API costs. Their e-commerce operation was bleeding money on unoptimized API calls. After restructuring their AI pipeline — semantic caching, model switching, smart batching — the monthly bill dropped from ₹95,000 to ₹10,000. A 97.5% cost reduction.

The Infrastructure is Ready

Five years ago, you could not realistically run AI automation in India. API latency was a problem. Cloud hosting was expensive. Payment gateways for international SaaS tools were unreliable.

That has changed completely. Indian VPS providers offer solid hosting for ₹200-500 per month. UPI makes international payments painless. Internet speeds are more than adequate. The infrastructure bottleneck is gone.

The Talent Gap is an Opportunity

Here is the paradox: India has millions of software developers but very few AI automation specialists. Most businesses know they should be automating but have no idea how. The ones who figure it out first gain a massive competitive advantage in their market.

I see this constantly. A D2C brand that automates their customer support and product descriptions can outcompete bigger players because their team is focused on strategy instead of repetitive tasks. A SaaS startup that automates their lead qualification pipeline closes deals faster because no lead sits unattended for 48 hours.

The Regulatory Environment Favors It

India's Digital India initiative and the push for digital transformation across government and enterprise mean that automation is actively encouraged. Businesses that invest now are positioning themselves ahead of the curve.

Top AI Automation Tools for Indian Businesses

I have tested dozens of tools over the past two years. Here are the four that I recommend and actively use, along with an honest comparison.

n8n — The Open Source Powerhouse

n8n is my primary automation platform. Self-hosted, open source, unlimited workflows, zero per-task pricing. I run it on a VPS that costs ₹250 per month and it handles everything from lead capture to content generation to client reporting.

I wrote a detailed breakdown of why I switched from Zapier to n8n and saved ₹12K per year. The short version: n8n gives you unlimited tasks, full custom code support, version-controlled workflows, and complete data privacy — all for a fraction of what Zapier charges.

For Indian businesses specifically, the self-hosting advantage is massive. Your data stays on your servers, in your country. No compliance concerns about sensitive business data flowing through US-hosted platforms.

Make (formerly Integromat) — The Visual Middle Ground

Make is excellent for teams that want more power than Zapier but are not ready to self-host. The visual workflow builder is intuitive, the pricing is reasonable (significantly cheaper than Zapier for high-volume usage), and it handles complex branching logic well.

I recommend Make for non-technical teams that need sophisticated automations. The learning curve is gentler than n8n, and the managed hosting means zero DevOps overhead. The free tier gives you 1,000 operations per month — enough to test whether automation works for your use case before committing money.

Zapier — The Safe Default

Zapier is the most well-known automation tool and has the largest integration library. If you need to connect two popular SaaS tools with a simple trigger-action workflow, Zapier will have the integration ready to go.

But the pricing model is its weakness for Indian businesses. Per-task pricing gets expensive fast, especially at scale. The ₹15,000 per year I was paying for Zapier's Professional plan did not give me the flexibility I needed. For simple, low-volume automations, it is fine. For anything serious, the costs spiral quickly.

Claude Code — The Developer's AI Automation Engine

Claude Code is not a traditional automation platform — it is something different and, in many ways, more powerful. It is an AI coding tool from Anthropic that operates directly in your terminal, reads your entire codebase, and can build, modify, and debug automation systems for you.

I use Claude Code to build the automations themselves. When I need a new n8n workflow, a custom API integration, or a data processing pipeline, Claude Code helps me build it in a fraction of the time. My honest developer review of Claude Code covers this in detail — it fundamentally changed how I work.

Where Claude Code really shines is building custom automation that no off-the-shelf tool can handle. Need to connect an obscure Indian payment gateway to your CRM with custom data transformation? Claude Code writes the integration code, tests it, and helps you deploy it.

And with the MCP Protocol — which I think of as the USB port for AI agents — Claude Code can connect to databases, APIs, file systems, and third-party services through a standardized interface. This makes it incredibly powerful for building automation that spans multiple systems.

Tool Comparison Table

Feature	n8n	Make	Zapier	Claude Code
Monthly Cost	₹250 (self-hosted VPS)	₹0-1,500	₹1,250+	₹1,500-4,000 (API usage)
Annual Cost	₹3,000	₹0-18,000	₹15,000+	₹18,000-48,000
Task Limits	Unlimited	1,000-10,000/mo	750-2,000/mo	Unlimited
Self-Hosting	Yes	No	No	Yes (CLI tool)
Custom Code	Full Node.js/Python	Limited	Very limited	Full (any language)
Learning Curve	Medium	Low-Medium	Low	Medium-High
Best For	Technical teams, high volume	Non-technical teams	Simple integrations	Custom/complex builds
Data Privacy	Full control	Their servers	Their servers	Full control
Indian VPS Compatible	Yes	N/A	N/A	Yes
Integration Count	400+	1,500+	6,000+	Unlimited (code-based)

My Recommendation

For most Indian businesses, I recommend this stack:

n8n for your core automation workflows (self-hosted for cost and privacy)
Claude Code for building and maintaining those workflows (and any custom integrations)
Make as a secondary tool for non-technical team members who need to build simple automations
Zapier only if you need a specific integration that does not exist elsewhere

This combination gives you unlimited automation capacity for under ₹5,000 per month. Compare that to hiring even one additional operations person.

Real Cost Savings: The Numbers

I do not believe in vague promises about ROI. Here are the actual numbers from my work with Indian businesses over the past year.

Case Study 1: E-Commerce AI API Optimization

Client: Mid-sized D2C e-commerce brand, Bangalore

Problem: Spending ₹95,000/month on OpenAI API calls for product descriptions, customer support chatbot, and review summaries.

Solution: Implemented semantic caching (Redis + vector embeddings), smart model switching (GPT-4 only for complex tasks, GPT-3.5-turbo for everything else), and request batching.

Result: Monthly API cost dropped to ₹10,000. That is ₹85,000 saved per month, or over ₹10 lakh per year. I covered this entire project in detail in my post on saving a client ₹85K/month on AI API costs.

Case Study 2: Lead Qualification Pipeline

Client: B2B SaaS startup, Delhi NCR

Problem: Sales team manually qualifying leads from website forms, LinkedIn, and email. Average response time: 36 hours. Losing deals to faster competitors.

Solution: Built an n8n workflow that captures leads from all sources, uses AI to score and qualify them, enriches data with LinkedIn and company info, updates the CRM, and sends personalized responses within 5 minutes.

Result: Response time dropped from 36 hours to under 5 minutes. Lead-to-demo conversion rate increased by 34%. The sales team now spends their time on qualified calls instead of sorting through spreadsheets. Estimated value: ₹2.5 lakh per month in recovered revenue.

Case Study 3: Content Operations

Client: Digital marketing agency, Mumbai

Problem: Team of 4 writers spending 60% of their time on repetitive content tasks — social media captions, email subject lines, meta descriptions, content briefs. High-value work like strategy and long-form content was constantly deprioritized.

Solution: Automated the repetitive content tasks using AI workflows. Writers review and approve AI-generated drafts instead of creating from scratch. Built using n8n + Claude API with custom prompts trained on the agency's style guide.

Result: Content output increased by 3x with the same team. The 4 writers now produce what previously required 10-12 people. Monthly savings on what would have been hiring costs: approximately ₹3 lakh.

The Aggregate Numbers

Across all my automation projects in the past 12 months:

40+ workflows built and deployed
₹85,000/month saved on a single client's AI API costs (the highest single savings)
97.5% cost reduction achieved on optimized AI pipelines
Average ROI timeline: 2-4 weeks to break even on implementation costs
Average monthly savings per client: ₹45,000-₹1,50,000 depending on scale

These numbers are not projections. They are from production systems running right now.

How to Get Started: Step-by-Step

If you are an Indian business looking to implement AI automation, here is the exact path I recommend. This is the same process I follow with every client.

Step 1: Audit Your Repetitive Tasks (Week 1)

Before you touch any tool, spend one week documenting every repetitive task in your business. Ask every team member: "What do you do every day that feels like a waste of your time?"

Create a spreadsheet with these columns:

Task name
Who does it
How often (daily, weekly, monthly)
Time spent per occurrence
Current tools used
Complexity (simple, medium, complex)

You will be surprised at what surfaces. I have seen teams discover they spend 15+ hours per week on tasks that can be fully automated.

Step 2: Prioritize by Impact and Feasibility (Week 1)

Score each task on two dimensions:

Impact: How much time or money does automating this save? (1-10 scale)

Feasibility: How easy is it to automate with current tools? (1-10 scale)

Start with tasks that score high on both. These are your quick wins. They will generate immediate ROI and build internal confidence in automation.

Common high-impact, high-feasibility tasks for Indian businesses:

Invoice data extraction and entry
Customer inquiry classification and routing
Social media content scheduling
Lead data enrichment
Report generation from multiple data sources
Email response drafts for common queries

Step 3: Set Up Your Automation Stack (Week 2)

Based on my tool comparison above, here is the minimum viable automation stack:

Get a VPS — DigitalOcean, Hetzner, or an Indian provider like HostGator India. A ₹500/month instance with 2GB RAM is enough to start.
Install n8n — Self-hosted on your VPS. The installation takes 30 minutes with Docker.
Set up Claude Code — Install it locally for building custom integrations. Follow the setup guide on Anthropic's site.
Connect your existing tools — CRM, email, Slack, Google Sheets, whatever your team already uses. n8n has integrations for most popular tools.

Step 4: Build Your First Workflow (Week 2-3)

Pick the highest-priority task from your audit and build the automation. Here is a simple framework:

Define the trigger — What event starts this workflow? A new form submission? A new email? A scheduled time?
Map the steps — What happens after the trigger? List every action in order.
Identify the AI components — Which steps require intelligence (language understanding, classification, generation) vs. simple data movement?
Build in n8n — Start with the trigger, add each step as a node, test with real data.
Add error handling — What happens when the API is down? When the data is malformed? Build fallback paths.
Test with real scenarios — Run 20-30 real examples through the workflow before going live.

Step 5: Measure and Optimize (Week 3-4)

After your first workflow is live, measure everything:

Time saved per week
Error rate compared to manual process
Cost of running the automation vs. the manual alternative
Team satisfaction (this matters more than you think)

Use these numbers to build the business case for expanding automation to the next tasks on your priority list.

Step 6: Scale to Full Workflow Automation (Month 2+)

Once you have 3-5 individual task automations running successfully, start connecting them into end-to-end workflows. This is where the real transformation happens.

Instead of isolated automations, you build systems. A new customer signs up and everything happens automatically — welcome email, CRM entry, onboarding sequence, internal notification, task assignment. No human intervention for the first 48 hours unless specifically requested.

This is Layer 2 automation, and it is where Indian businesses see the biggest productivity gains.

Common Mistakes to Avoid

I have seen Indian businesses make these mistakes repeatedly. Learn from their experience:

Automating before understanding. Do not automate a broken process. If your current workflow has problems, automating it just creates faster problems. Fix the process first, then automate it.

Starting too complex. Your first automation should take less than a day to build. If it requires a multi-week project, you have picked the wrong starting point.

Ignoring error handling. Every automation will fail eventually. APIs go down. Data arrives in unexpected formats. Build fallback paths and notifications for failures from day one.

Not measuring ROI. If you cannot put a number on the time or money saved, you will lose executive buy-in when it is time to scale. Measure everything.

Choosing tools based on popularity instead of fit. Zapier is the most well-known tool, but rarely the best choice for cost-conscious Indian businesses running high-volume workflows. Choose based on your needs and budget.

Frequently Asked Questions

How much does AI automation cost for a small Indian business?

You can start with under ₹3,000 per month. That covers a basic VPS for n8n (₹250-500), AI API costs for moderate usage (₹1,000-2,000), and no per-task fees. As you scale, costs grow linearly but savings grow exponentially. Most of my small business clients see positive ROI within the first month.

Do I need a developer to set up AI automation?

For basic workflows using n8n or Make's visual builders, no. A technically-inclined operations person can build simple automations after watching a few tutorials. For custom AI integrations or complex workflows — yes, you need development experience. That said, tools like Claude Code are closing this gap. I use Claude Code to build automations significantly faster than writing everything from scratch.

Is AI automation reliable enough for production use?

Yes, with proper error handling. I have workflows running in production for months without manual intervention. The key is robust fallback paths — when an API call fails, the workflow retries, falls back to a simpler model, or alerts a human. The 40+ workflows I have deployed process thousands of tasks weekly with error rates under 0.5%.

What about data privacy? Can I keep my data in India?

Absolutely. Self-hosting n8n on an Indian VPS means your workflows, business data, and customer information never leave Indian servers. For AI API calls, you can minimize data exposure using semantic caching (serve repeated queries from local cache) and by processing sensitive data locally before sending only non-sensitive components to the AI. I covered caching strategies in my post on reducing AI API costs.

How does MCP Protocol fit into AI automation?

MCP (Model Context Protocol) is becoming the standard way AI agents connect to external tools and services. Think of it as a universal connector for AI — instead of building custom integrations for every AI tool and every service, MCP provides one standardized protocol. For Indian businesses, this means your AI automation stack becomes more interoperable and future-proof. Build an MCP server for your internal tools once, and any MCP-compatible AI agent can use them. As the ecosystem matures, this will dramatically reduce the cost and complexity of building AI-powered automations.

Can AI automation work for non-English content?

Yes, and this is particularly relevant for Indian businesses operating in Hindi, Tamil, Bengali, Marathi, and other regional languages. Modern LLMs handle Indian languages with increasing fluency. I have built workflows that process customer queries in Hindi, generate content in multiple Indian languages, and translate between regional languages as part of automated pipelines. For business use cases like customer support, content generation, and data extraction, it is production-ready.

What is the ROI timeline for AI automation?

Based on my experience across 40+ implementations: Week 1-2 is setup and first automation. Week 3-4 you see measurable time savings. Month 2 you hit break-even on implementation costs. Month 3 onward is pure positive ROI. The fastest ROI I have seen was 4 days — a client whose support team spent 3 hours daily on repetitive email responses. After automating draft generation, that dropped to 20 minutes of review time per day.

What Comes Next

AI automation in India is not a future trend. It is happening right now, and the businesses that implement it this quarter will have a compounding advantage over those that wait.

The tools are affordable. The infrastructure is ready. The cost savings are proven. The only variable is execution.

If you have read this far, you already understand the opportunity. The next step is action. Start with the audit I described in Step 1. Pick one workflow. Build it. Measure the results. Then scale.

If you want help implementing AI automation for your business — whether it is optimizing your AI API costs, building n8n workflows, or setting up a complete automation stack — get in touch. I work with Indian businesses of all sizes and can typically show ROI within the first two weeks.

The best time to automate was six months ago. The second best time is today.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

AI Interviews Will Lose You the Good Candidates

Archit Mittal — Tue, 15 Sep 2026 02:45:05 +0000

The candidates you most want to hire are the ones most likely to abandon an AI interview halfway through. That is the whole problem, and it is worth stating before anyone sells you an "end-to-end AI hiring platform".

Automating the top of your hiring funnel is one of the highest-return automations a business can do. Automating the conversation itself is one of the worst. The line between the two is not fuzzy, and I want to draw it precisely, because the tools on the market deliberately blur it.

The asymmetry nobody mentions in the demo

Think about who actually completes a thirty-minute interview with a bot.

A candidate with no other offers will sit through anything. They will answer scripted questions to a camera, wait for the AI avatar to finish its pause, repeat themselves when the speech recognition mishears them. They have no alternative, so they comply.

A candidate with three interviews lined up this week behaves differently. The moment they realise no human being from your company has looked at them, they make a quiet calculation: this company does not rate this role highly enough to put a person on it. They close the tab. You will never know, because they do not write to tell you. They simply appear in your dashboard as "incomplete", and the platform's report politely calls it drop-off.

So the AI interview does filter your pipeline. It filters it backwards. It keeps the people with no options and removes the people with options. You end up interviewing a pool that has been pre-selected for desperation, and then you wonder why the shortlist feels weak.

If you run a business anywhere between a small trading firm and a mid-sized manufacturer, you already know this dynamic from the other side. When a customer's first three touchpoints with you are all bots, the serious buyers go elsewhere and the tyre-kickers stay. Hiring works the same way. The interview is a sales conversation in both directions, and you cannot delegate your side of it to a script.

What is genuinely safe to automate

Everything before the conversation. This part I will defend without hesitation, because I have built these systems and they work.

Job post distribution. One posting, syndicated to every portal and your WhatsApp groups, with a single tracked application link.
Application intake. A form that captures notice period, current city, salary expectation and the two or three hard requirements of the role, instead of asking someone to email a CV that nobody opens.
Knockout screening. If the role needs someone in Pune and the applicant is in Guwahati with no intention of relocating, no human needs to discover that in a phone call. Rules can reject politely and instantly.
Scheduling. The ugliest part of hiring is the four-message back-and-forth to fix a time. A booking link with your real availability removes it entirely.
Reminders and follow-ups. Automated nudges the day before the interview cut no-shows, and a candidate who receives a confirmation, a reminder and a map link thinks better of your company, not worse.
Post-interview status updates. "We have moved you to round two" sent automatically beats the silence most Indian companies default to.

Notice what all of these have in common. None of them pretends to be a person. None of them makes a judgement about the candidate as a human being. They move information and remove waiting. That is what software is for.

A worked example: the attrition spiral

Here is the situation where owners most often reach for interview automation, and where it does the most damage.

A distributor-side business with field sales staff runs at high attrition, which is normal for the category. Every month, two or three sales positions fall vacant. The owner is filing GST returns, chasing collections, managing the bank, and now also supposed to interview a stream of candidates for roles that will be vacant again within the year. It is exhausting, and when a vendor offers to "put the entire interview on AI", it sounds like relief.

So the AI interview goes in. Applications keep coming, because the top of the funnel was never the problem. Completion of the AI round is poor, but there are still enough finishers to shortlist from. The owner interviews the finishers, hires, and six months later notices the new batch is churning even faster than the old one and hitting lower numbers.

What happened is exactly the asymmetry above. Field sales is a job where the good performers always have options, because every competitor in the territory wants them. Those are precisely the people who would not sit through a bot interview for a mid-range salary. The AI round did not save the owner time on interviewing good candidates. It removed the good candidates before the owner ever saw them, and the attrition problem got worse, because the pipeline now selected for people with nowhere else to go.

The honest fix was boring: automate intake, knockout and scheduling so the owner interviews only pre-qualified people at fixed slots twice a week, and keep the fifteen-minute human conversation. The time saved is real. The judgement stays human.

Where the handover must sit

The rule I use when building hiring pipelines is simple to state.

Automation owns everything up to the moment a qualified candidate is confirmed for a slot. A human owns everything from "hello" onwards.

Concretely, the handover sits at the calendar invite. Before that point, no candidate should need a human: applying, answering knockout questions, picking a time, receiving reminders. After that point, no candidate should face a machine: the interview is a person, the follow-up questions are a person, the offer discussion is a person, and ideally the rejection message, even if templated, is signed by a person with a name.

Two clarifications, because vendors will probe at the edges of this rule.

First, a one-way "record your answers on video" round is an interview, not screening, and it belongs on the human side of the line. It has the same drop-out asymmetry as a live AI interviewer, arguably worse, because talking to a camera with no listener is more alienating than talking to a bot that at least responds.

Second, AI assisting the human interviewer is fine and useful. A summary of the candidate's application before the call, a suggested question list based on the role, a transcript afterwards so you can compare candidates a week later. The test is always the same: is the candidate experiencing a human or a machine? What happens behind the human is your business.

The part where I tell you not to buy something

Do not automate the interview itself. Not for sales roles, not for operations roles, not even for the junior positions where it feels harmless. If your interviewing load is genuinely unmanageable, that is a signal that your screening is too loose, not that the conversation should be mechanised. Tighten the knockout rules, batch interviews into fixed weekly slots, delegate first rounds to your best manager. All of those preserve the thing the AI interview destroys, which is the candidate's belief that your company saw them as worth a person's time.

I say this as someone who builds automation for a living, and who would earn more by telling you the opposite. Every platform selling AI interviews is selling the claim that the conversation is the inefficiency. It is not. The waiting, the coordination and the unqualified applicants are the inefficiency. The conversation is the product.

What to do this week

Take your most recent vacancy and count the hours it consumed, but split the count into two buckets: hours spent coordinating (posting, sorting CVs, fixing times, rescheduling, reminding) and hours spent actually talking to candidates. In every pipeline I have examined, the coordination bucket is far larger, and it is entirely automatable with a form, a rules-based filter and a scheduling link. Automate that bucket first. If, after that, the talking bucket still feels too heavy, the answer is better screening rules, not a machine that talks for you.

The companies that win the next few years of hiring in India will be the ones where a candidate applies at midnight, gets a slot by morning, and then meets a real human who has read their application. Fully automated on logistics, stubbornly human at the conversation. Build that, and the candidates with options will start choosing you.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Your bot fails at Hinglish, and your customers will not switch

Archit Mittal — Mon, 14 Sep 2026 12:45:05 +0000

Your customers do not type the way your bot was tested. They type "bhaiya order kab tak aayega", they type "pmt ho gya h check karo", they send a forty-second voice note in Marathi with the fan running, and they switch script mid-sentence because their keyboard autocorrected "kitna" to English and they could not be bothered to fix it. The demo you approved was tested with "What is the status of my order?" Those are not the same product. The first one is the job. The second one is a stage trick.

I have built WhatsApp agents for Indian businesses, and the pattern repeats every time: the bot performs beautifully in the pilot, then support tickets climb within the first week of real traffic. Not because the model is bad. Because nobody tested it against what customers actually send.

What real Indian customer messages look like

Pull up the last hundred inbound messages on any Indian business's WhatsApp. You will find, roughly in order of frequency:

Romanised Hindi. "Ye wala size available hai kya" — Hindi words, Latin script, no punctuation. This is the default register of Indian commerce, and there is no standard spelling. "Kya", "kia", "kyaa" and "kua" all mean the same thing, typed by the same customer on different days.
Mid-sentence script switching. "Order placed कर दिया but payment page pe error आ रहा है." Devanagari and Latin in one line, because Gboard flipped languages halfway through.
Heavy abbreviation. "Pmt", "dlvry", "tmrw", "h" for "hai", "nhi" for "nahin". A customer typing with one thumb while doing three other things does not write for your NLU pipeline.
Voice notes. For a large share of customers, especially older ones and anyone typing in a second script, voice is not a fallback. It is the primary channel. And it arrives with traffic noise, code-switching, and regional accent.
Photos instead of words. A screenshot of a failed UPI payment. A photo of a damaged carton. A photo of a handwritten parts list from a distributor.

Now look at the test plan your vendor showed you. Every test message is a complete English sentence with a question mark at the end. That test plan validates a customer who does not exist.

Why the failure is worse than a wrong answer

When a bot mishandles clean English, it usually fails visibly: "Sorry, I didn't understand that." Annoying, but honest. When a bot mishandles Hinglish, it often fails confidently. "Pmt ho gya, order confirm karo" gets parsed as a new order enquiry, and the bot cheerfully sends the product catalogue to a customer who has already paid and is now furious. The customer does not think "the language model struggled with romanised Hindi". The customer thinks "this company is ignoring me", and calls. Now you are paying for the bot and the phone call, and the customer trusts you slightly less than before you automated anything.

Here is the part most owners get wrong: the customer will not adapt. A polite English prompt saying "Please type your query in English" is read as "we built this for our convenience, not yours". People do not change how they text for a vendor. They change vendors, or they bypass the bot entirely and flood the owner's personal number, which is usually the exact problem the bot was bought to solve.

A worked example: the distributor order that became a complaint

A building-materials trader I worked with takes distributor orders on WhatsApp. Typical inbound message: "Bhai 50 bag opc 43 aur 20 bag ppc bhejna site pe, wahi wala rate, gadi kal subah". One sentence carrying product, grade, quantity, delivery location, an implied price agreement and a delivery deadline, in romanised Hindi with zero punctuation.

The first version of the intake agent, tested on tidy English orders, did the following with that message: it extracted "50" and "20" correctly, mapped "opc 43" to the right SKU, missed "ppc" entirely because the training examples spelt it "PPC cement", and treated "wahi wala rate" as a pricing enquiry, so it replied with the standard rate card. The distributor read that as the trader quietly revising an agreed price. That is not a chatbot bug. That is a commercial relationship taking damage.

The fix was not a better model. The fix was rebuilding the test set from six months of real order messages, exported straight from WhatsApp, and refusing to ship until the agent handled the top patterns in that corpus: every observed spelling of every product, "wahi wala" and "purana rate" as references to an existing agreement rather than a price question, and a hard rule that any message containing a rate reference goes to a human before any reply is sent.

Voice notes deserve their own paragraph of pessimism

Speech-to-text for Indian languages has improved a great deal, and on clean audio it is genuinely usable. But customer voice notes are not clean audio. They are recorded on a two-wheeler, in a shop with a grinder running, by someone switching between Hindi and their mother tongue inside one sentence. Transcription errors on names, amounts and product codes are exactly the errors that cause commercial damage, because a plausible-but-wrong transcript fails silently.

If voice notes are a meaningful share of your inbound traffic, the honest architecture is transcribe, then classify, then route the risky ones to a person. The agent handles "delivery kab hogi" end to end. Anything the transcriber flags as low-confidence, and anything containing an amount, goes to a human with the transcript attached as a head start. That is still a large saving in handling time. It is just not the "zero-touch support" story you were sold.

Where the answer is: do not automate this

Some categories should not have an agent answering at all, in any language:

Complaints and anger. A customer who is already upset, decoding a slightly-off Hinglish reply from a bot, becomes an ex-customer. Detect the sentiment, route to a person, have the bot say only "aapka message mil gaya, thodi der mein call aayega" and nothing else.
Anything touching money. Refunds, rate disputes, payment confirmations. A misread "pmt ho gya" is not a support failure, it is an accounting failure.
Regulated or high-stakes replies. If the answer could be quoted back at you in a dispute — GST invoice corrections, warranty commitments — a human writes it.

Every vendor pitch says the opposite: full automation, all languages, day one. The businesses whose automation survives contact with real customers are the ones that drew this line before launch, not after the first blown-up complaint.

How to test properly before you switch anything on

The method is unglamorous and it works:

Export real history. Take the last few hundred inbound messages from your actual WhatsApp Business account. Not samples the vendor provides. Yours.
Build the test set from them, verbatim. Spelling mistakes, half-Devanagari lines, voice notes and all. Strip customer names, keep everything else exactly as typed.
Run every one through the agent before launch. Score three things per message: did it understand the intent, was the reply correct, and — most important — when it failed, did it fail loudly (escalate to a human) or quietly (confident nonsense)? Quiet failures are the ones that cost customers.
Set an escalation floor, not a ceiling. Early on, the agent should be handing off more than feels efficient. You tighten the rules as the transcript log proves which patterns it genuinely handles.
Re-test monthly from fresh messages. Your customers' typing shifts with seasons — ITR season brings different vocabulary than Diwali order rush — and an agent tested once in March degrades quietly by August.

The one thing to do this week

Export the last two hundred inbound messages from your business WhatsApp and read fifty of them in one sitting. Count how many are clean English sentences. That single number tells you whether any bot demo you have seen — or any bot you are already running — was tested against your customers or against a fiction. If you are already live, paste twenty of those real messages into your bot today and watch what comes back. What you find will either be reassuring or extremely useful. Both are worth an hour.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

AI Won't Fix a Broken Process. Map It First, Then Automate

Archit Mittal — Mon, 14 Sep 2026 02:45:06 +0000

Automation copies your process. If the process is confused, you now have confusion running at speed, and nobody to blame in the room because the software did it. That is the failure mode I see most often in businesses between fifty lakh and fifty crore: not bad tools, not bad vendors, just a process that was never written down being handed to a machine that requires it to be.

The fix is boring and it takes twenty minutes. Before you buy anything, before you book a demo, you map the process. Not a flowchart with swimlanes. A single sheet of paper and four questions.

Why the tool always looks like the answer

The tool is easy to evaluate. It has a price, a website, a demo, a comparison table. Your process has none of those things. It lives in the heads of two people, one of whom is on leave, and it changes depending on which customer is asking.

So when something hurts, the search that follows is "best software for X". That is the wrong search. The right question is why the pain exists, and the honest answer is usually one of three: nobody owns the step, the input arrives in an unusable form, or the step exists to compensate for an earlier step that was done badly. Software fixes none of those. It just makes the compensating step faster.

I have built systems that got ripped out within a quarter, and every single one failed for the same reason. The process I automated was not the process the business ran. It was the process someone described to me in a meeting.

The twenty-minute audit

Take one process. Not the business. One process, the one that is genuinely annoying you this month. Sit with the person who actually does it, not the person who manages the person who does it. That distinction matters more than anything else in this article.

Then work through four questions, writing as you go.

One: what triggers this, and what ends it? Be brutal about the boundaries. "Handling enquiries" is not a process. "A WhatsApp message arrives from an unknown number, and it ends when the enquiry is either quoted or dismissed" is a process. If you cannot state the trigger and the end state in one sentence each, you are looking at several processes stacked on top of each other, and you must split them before you go further.

Two: what are the steps, in order, with a name attached to each? Every step gets a human name. Not a department, not "the team". A name. Where you cannot write a name, you have found something important: that step is either shared, which means it gets dropped, or unowned, which means it gets dropped less predictably.

Three: where does the work wait? Mark every point where the work sits still. Waiting for approval. Waiting for someone to check their inbox. Waiting for the accountant to send the file. In most processes the waiting is the majority of the elapsed time, and the actual work is a small fraction of it. This is the question that changes people's minds most often, because owners tend to believe their process is slow due to effort when it is actually slow due to queueing.

Four: what breaks it? Ask the person doing the work what the last five exceptions were. Not hypothetical exceptions. Actual ones from the last month. Write them down. Then ask what fraction of the volume those exceptions represent. If exceptions are rare, automate the main path and route exceptions to a human. If exceptions are the majority, you do not have a process yet, you have a series of judgement calls, and automating it will produce garbage at scale.

That is the audit. Twenty minutes, one sheet, four questions.

A worked example: distributor orders on WhatsApp

Here is one I have mapped several times, in different businesses, with almost identical results.

A distribution business takes orders from retailers on WhatsApp. The owner wants a bot. The bot will read the messages, understand the order, push it into Tally, and confirm to the retailer. Vendors will happily quote for this.

Run the audit. Trigger: a retailer sends a message. End state: the order is entered and a confirmation goes back. Steps: someone reads the message, works out which SKU is meant, checks whether the retailer has outstanding dues, checks stock, enters it, replies.

Now question three, the waiting. The orders come in through the day. One person enters them in a batch in the evening. So an order placed at eleven in the morning waits until the evening, not because entry is slow but because entry happens once a day.

And question four, the breakages. Retailers do not write SKU codes. They write "wo wala 5 peti bhej do". The person entering the order knows what that retailer usually means. That knowledge is not written anywhere. Half the messages need it.

So what should this business automate? Not the understanding. That is the part that looks impressive in a demo and fails quietly in production, and when it fails it ships the wrong goods to a retailer who then stops ordering. What should be automated is the queueing: an acknowledgement the moment a message arrives, orders surfaced in a single list instead of a chat thread, a dues and stock flag next to each one so the person entering it is not switching between three screens. The human still reads the message and decides the SKU. The system removes the waiting and the screen-switching around that decision.

That business got most of the benefit without touching the risky part. And the SKU understanding becomes automatable later, once there is a clean record of what each retailer's phrasing actually mapped to, because the new system is now recording exactly that.

Where the answer is: don't automate this

Nobody in my line of work wants to say this, so I will say it plainly. Some things should stay manual, and knowing which is more valuable than any tool.

Low volume, high variance. If a task happens a handful of times a month and looks different each time, automation costs more to build and maintain than it saves. Your GST filing is a good example of the opposite: it is monthly, structured, and identical in shape, which is exactly why reconciliation between your sales register and the portal data is worth automating. But your response to a supplier dispute is not.

Anything where being wrong is expensive and being slow is cheap. Payment releases. Credit limits for a new retailer. Anything with a legal deadline where a silent failure is discovered late. Automate the preparation, keep the decision human, and make sure the system fails loudly rather than quietly.

A process you are about to change. If you are hiring, restructuring, or moving to new accounting software this year, automating the current process is building on ground you are about to dig up.

Something you have not written down. If the audit produces four questions you cannot answer, the answer this month is not a tool. It is running the process deliberately for a few weeks, writing down what actually happens, and then deciding.

Refusing to automate is a legitimate outcome of the audit. It is, in fact, the outcome that saves the most money.

What the audit actually gives you

You end up with a sheet showing where the work waits, who owns each step, and how often things break. From that, the priority order writes itself. Automate the longest wait with the lowest variance first. That is nearly always the highest return, because you are removing queueing rather than trying to replace judgement, and queueing is the cheapest thing in the world to remove.

You also get a specification. When you do talk to a vendor, you are no longer asking what their product does. You are telling them what your process is and asking whether their product fits it. Those two conversations end in very different places, and the second one is much harder to oversell to.

The other thing you get is the ability to tell whether it worked. If you measured the wait before, you can measure it after. Most automation projects fail this test not because they did nothing but because nobody wrote down the before.

Do this week

Pick the one process that annoyed you most in the last fortnight. Book thirty minutes with the person who does it, not the person who manages it. Ask the four questions and write the answers on one sheet: trigger and end state, steps with names, where the work waits, and the last five exceptions.

Then put the sheet away for a day and read it again. In my experience you will find at least one step that exists only because of a decision nobody has revisited in years, and removing that step will cost you nothing at all.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Ten prompts I actually use to run sales and operations

Archit Mittal — Sun, 13 Sep 2026 12:45:03 +0000

Most prompt lists are written by people who do not run a business. They give you "act as a world-class sales expert" and leave you to discover, on your own customers, that the model will happily invent a delivery date.

These are the ones I actually keep. Each is written to be pasted as-is, each names the input it needs, and each ends with the line that matters most: where it stops and a person takes over. That last part is not caution for its own sake. It is the difference between a system that saves you an hour and one that costs you a client.

1. The three-message follow-up

The second follow-up is where most people quit, because they have run out of things to say. So they send "just checking in", which the customer reads as "I want something from you" and ignores. This prompt refuses to write that message.

You are drafting follow-up messages for a B2B sale in India. Here are my notes from the last conversation: [PASTE NOTES OR TRANSCRIPT].

Write three separate WhatsApp messages, each under 60 words, in plain English a busy owner would actually read.

Message 1 must contain one piece of genuinely new information — a price change, a similar client's outcome, a deadline, a constraint they did not know. If my notes contain nothing new, say "NO NEW INFORMATION — do not send" instead of writing message 1.
Message 2 must give a real reason to decide now. Do not invent urgency. If there is no real deadline, use the honest one: my capacity, their season, a price that changes.
Message 3 must close the loop gracefully: offer to close their file and stop following up, with no guilt and no final pitch.

Do not use the phrases "just checking in", "circling back", "touching base", or "following up on my last message". Do not open with "Hope you're doing well".

The refusal is the important instruction. A model told to write three follow-ups will always write three follow-ups, even when the honest answer is that you have nothing to say and should wait.

Where it stops: you supply what changed. The model cannot know that the client's competitor just signed, or that your price moves next month. It writes the message; you bring the fact.

2. The quote draft

You lose deals to whoever quoted first, not to whoever quoted best. Most owners take a day to send a quote because the quote lives in their head and the head is busy.

Draft a quotation from these details: [PASTE THE ENQUIRY]. My rate card is: [PASTE RATES].

Structure it as: what I understood they need, what is included, what is explicitly not included, price, and validity period.

Rules. Use only prices from my rate card. If the enquiry does not contain enough detail to price it, do not guess — list exactly which questions I still need answered, and stop. Flag anything in the enquiry that suggests scope beyond my rate card. Keep it short enough to read on a phone without scrolling twice.

Where it stops: the price. Never let a model calculate or negotiate a number that leaves your system as a commitment. It assembles the quote; you approve the figure.

3. The dead-CRM triage

Every CRM I have opened has a large tail of leads nobody has touched in months. They are not worthless. They are unsorted.

Here is a CSV export of old leads: [PASTE]. Columns are [LIST COLUMNS].

Sort every row into exactly one of: REVIVE, PARK, DELETE.
REVIVE — there is a specific reason to contact them now.
PARK — real but not now; say what event would change that.
DELETE — wrong fit, wrong geography, bounced, or a competitor.

Give a one-line reason for each. Do not invent details that are not in the data. If a row is too sparse to judge, mark it UNKNOWN rather than guessing.

Then, for the REVIVE pile only, ask for the reactivation message:

For each REVIVE lead, write one WhatsApp message under 50 words that acknowledges the gap honestly, references what they originally wanted, and asks one question. Do not pretend we spoke recently.

Where it stops: DELETE is a suggestion, not an instruction. Read the list before anything is removed.

4. Qualifying before the call

A discovery call that discovers the person cannot afford you is a wasted hour, and you will have two of them a week for as long as you allow it.

Send four questions in chat before you book anything: what they want to happen, what they have tried, when they need it done, and what range they had in mind. Then:

Here are a prospect's replies to my four qualifying questions: [PASTE].

Return one of: BOOK, NURTURE, DECLINE, with a one-sentence reason.
BOOK — the need, the timing and the range all fit.
NURTURE — real need, wrong timing. Say what to wait for.
DECLINE — say plainly what does not fit.

Then write the message I should send in that case. For DECLINE, be warm, be brief, and recommend what they should do instead, even if it is not me.

Where it stops: DECLINE. Read those before they send. Turning someone away badly costs more than the meeting would have.

5. The lost-deal record

Everyone tracks why they won. Almost nobody records why they lost, which is why the same objection keeps landing.

I lost this deal. Here is what happened: [PASTE].

Extract: the stated reason for losing, the likely real reason if it differs, the stage where it actually turned, and what I would have needed to know earlier.

Do not be reassuring. If the notes suggest I was too slow, too expensive for the value shown, or talking to the wrong person, say so plainly.

Run this for a month and read the results together, not one at a time. One lost deal is an anecdote. Ten of them tell you whether you have a pricing problem, a speed problem or a targeting problem, and those need completely different fixes.

Where it stops: nowhere, actually. This one is safe to automate fully. It never touches a customer.

6. The agent guardrail

The single most useful line you can put above any retrieval agent. Without it, a model asked something outside its documents will answer anyway, fluently, and your customer cannot tell the difference.

Answer only from the documents provided. If the answer is not in them, reply exactly: "I don't have that — let me check and come back." Never infer, estimate, or fill a gap from general knowledge. Quote the line you used.

Where it stops: it does not stop hallucination entirely. It converts most of it into a visible "I don't know", which is the difference between a bot that is wrong and a bot that is honest.

7. The do-not-automate audit

Run this before you build anything, not after.

Here is a list of decisions my team makes: [PASTE].

For each, tell me: can it be undone within a day at no cost, is it reversible but expensive, or is it irreversible? Then say which bucket it belongs in — automate, automate with a human approving, or never automate.

Treat anything touching money leaving the business, a filing, or a message sent under my name as never automate unless I have said otherwise. Explain each call in one line.

8. The report cull

Most recurring reports are read by nobody. Delete before you automate.

Here is every recurring report we produce: [PASTE, with who receives each].

For each, ask: what decision changes because of this report? If you cannot name one, mark it DELETE. If the decision could be answered by a single number instead, mark it REPLACE and say what the number is. Otherwise KEEP.

Where it stops: ask the recipients before deleting. A report nobody discusses may still be the thing someone checks silently.

9. The customer-data cleanup

Your data is not ready. It never is. This finds out how bad it is in one pass.

Here is an export of my customer list: [PASTE].

List every distinct spelling, abbreviation and formatting variant of the same customer name. Do the same for phone numbers and city names. Return the groups you believe are one customer, with a confidence for each, and a separate list of rows you cannot judge.

Do not merge anything. Only report.

10. The decision log

AI meeting notes without decisions are a transcript with extra steps.

Here is a meeting transcript: [PASTE].

List only decisions that were actually made. For each: what was decided, who owns it, by when, and what was explicitly left open. Ignore discussion that did not resolve. If no decision was made, say so plainly rather than summarising the conversation.

The rule underneath all of them

Every one of these prompts drafts, reports or sorts. None of them send.

That is not timidity. The failure mode with sales automation is never the model writing something insane, which you would catch instantly. It is the model writing something reasonable and slightly wrong — a date shifted by a week, a discount you did not offer, a confidence you have not earned — going out under your name, at three in the morning, to a client who believes it. You find out from them, and you spend far more time repairing it than the automation ever saved.

Draft with AI. Send as yourself.

Do this one thing this week

Take prompt 1 and run it against your three oldest open deals. For at least one of them, the honest output will be "NO NEW INFORMATION — do not send".

That is the prompt working. Those are the deals where you have been sending "just checking in" for a month, and the reason there has been no reply is that there has been no message.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

The CFO's AI Playbook: 5 Finance Automations Every Indian Business Should Run in 2026

Archit Mittal — Sun, 13 Sep 2026 02:45:07 +0000

Over 60% of APAC finance leaders say AI-led automation is their top priority for 2026. For Indian businesses, that stat hides a quieter truth: most SMBs have no idea which automation to start with. They hear "AI for finance" and picture an enterprise suite with a six-figure licence fee. Wrong picture.

I've built finance automations for CA firms, D2C brands, trading desks, family-run manufacturers, and a few fintech startups. The pattern is always the same. Five finance processes eat the most hours, hide the most errors, and respond best to a simple Python layer on top of whatever ledger you already use.

This is the playbook. No enterprise suite. No subscriptions you don't need. Each automation is something I've shipped for real clients using Python, free APIs, and a ledger that's usually Tally or Zoho Books.

1. Bank Reconciliation — The Single Biggest Time Sink in Indian Finance

Every finance team I meet has the same nightmare. Statements from three or four banks. Tally or Zoho on the other side. An Excel sheet in the middle. Eight hours a month — sometimes more — matching rows.

A CA friend was losing two sleepless nights before every GST deadline on exactly this. We replaced it with a Python script that pulls statements from email attachments, categorizes transactions using keyword rules, cross-references entries with Tally, and flags only the mismatches in a clean Excel file. Eight hours dropped to fifteen minutes of review.

"Tu 2 saal pehle kyu nahi mila?" (Why didn't I meet you two years ago?)

If your team is still opening each bank statement manually, start here. It's the highest-ROI automation in Indian finance. I've written the full workflow in how a weekend Python script saved a CA firm 209 hours during ITR season.

2. Cash Application — Matching Payments to Invoices at Indian Speeds

Globally, AI-driven cash application handles up to 90% of invoice matching without human touch. In India, it's harder — money arrives in more shapes than most tools expect: UPI, NEFT, RTGS, IMPS, cheques, partial payments, grouped settlements where one transfer covers four invoices. Manual matching is why so many Indian SMBs run receivables that are perpetually a week out of date.

I build a three-layer pipeline. Layer one parses payment references — UTR numbers, invoice IDs, sometimes just a customer name in the remarks. Layer two tries deterministic matches: exact amount, reference, customer. Layer three hands the ambiguous ones to a lightweight AI model that reasons about partial amounts, nicknames, and grouped payments, then suggests matches with a confidence score.

Above 95% confidence gets auto-applied. Below that goes to human review. A D2C brand I rolled this out for went from a seven-day receivables gap to same-day application. Their working capital position shifted by roughly ₹14 lakhs without a single new customer.

3. Real-Time P&L Reporting — Know Your Numbers Before the CA Calls You

Most Indian SMB founders see their P&L twenty days after the month ends, when their accountant sends a formatted Excel. By then, the decisions that would have mattered — cut this spend, double that campaign, pause that hire — are a month old.

Real-time P&L automation closes that gap. A scheduled Python script pulls trial balance data overnight, categorizes new entries into your chart of accounts, and renders a dashboard with revenue, gross margin, operating expenses and EBITDA as of yesterday. Usually in Google Sheets or a lightweight HTML dashboard.

What this actually changes: You stop making capital decisions on twenty-day-old data. For a business doing ₹30L/month, a single well-timed cut or push based on real-time numbers can move EBITDA by 2-3 percentage points over a quarter.

This pairs beautifully with the ₹0 automation stack I've written about — cron, Python, Google Sheets, and free accounting exports give you an enterprise-grade finance dashboard without a rupee of subscription spend.

4. GST Filing Prep — Eliminate the Three Nights Before Every Return

GSTR-1, GSTR-3B, and the quarterly reconciliations are the other reason finance teams lose sleep. The filing itself is data entry. The real work is pulling sales data, reconciling with purchase registers, checking vendor filing mismatches, and formatting it all for the GSTN portal.

Every one of those steps is automatable. I build GST prep bots that run on the 28th of every month. They pull sales and purchase data, compute GSTR-1 and GSTR-3B figures, pull vendor GSTR-2A data via the GSTN API, flag reconciliation mismatches, and produce a filing-ready summary.

A small manufacturing client went from three anxious days a month to a two-hour review window. Their CA still does the actual submission — that's judgment work, stays human. The 80% that's data plumbing? Gone.

5. Expense Categorization — Stop Miscategorizing Half Your Costs

This one sounds boring. It isn't. Miscategorized expenses are a silent killer in Indian SMB P&Ls. A ₹2L advertising spend mis-booked as "professional fees" wrecks every board metric that flows from it.

Expense categorization automation uses an AI model trained on your own chart of accounts and historical entries. Each new entry gets a suggested category with confidence. High-confidence ones auto-categorize. The ambiguous 10-15% goes to a review queue. Your reviews feed back in and the model sharpens.

For a client with ~800 expense entries a month, this shifted their finance lead's time from 6 hours of categorization to 45 minutes of review. Accuracy went from ~82% to 97%. Their board deck finally told the truth about where money was going.

The Five Automations at a Glance

Automation	Time Saved / Month	Typical Rollout
Bank reconciliation	6-10 hours	2-4 weekends
Cash application	15-25 hours	3-6 weeks
Real-time P&L	8-12 hours + faster decisions	1-2 weeks
GST filing prep	12-20 hours	3-5 weeks
Expense categorization	4-8 hours	1-2 weeks

Stack all five and you're recovering 45-75 hours of skilled finance time every month. For an SMB with a single accountant, that's effectively a second person at zero incremental cost. For a firm with a CFO, it's the difference between reactive month-end rituals and proactive capital decisions.

Where to Start (And Where Not To)

Do not try to build all five at once. That's how automation projects become automation graveyards. Start with bank reconciliation — bounded, high-ROI, and an immediate win. Once it's running reliably for two months, pick the next one where your team still feels stuck.

Also, don't automate what doesn't need to be automated. I've written a whole piece on when not to automate — it applies especially hard in finance, where reviewing edge cases is often the most valuable part of the job. The goal isn't a human-free finance function. It's one where humans spend hours on judgment, not typing.

"Jo kaam AI se ho sakta hai, AI kare. Jo judgment se hota hai, woh humans ke paas rahe." (Let AI do what AI can do. Let judgment stay with humans.)

That's the whole playbook. Five automations. Zero enterprise suites. A real finance function that tells you the truth, faster, with less pain.

Which of these five is eating the most hours in your finance team right now?

FAQ

Which finance automation gives the fastest ROI for an Indian small business?

Bank reconciliation is almost always the fastest ROI. Most finance teams spend 6-10 hours a month on it, and a Python script with keyword-based matching and Tally cross-reference can reduce that to 15-30 minutes with a one-time build effort of 2-4 weekends.

Do I need a CFO or a full finance team to automate finance work?

No. These five automations are designed for Indian businesses with one accountant or even a founder-as-finance-lead. The framing as a CFO playbook is about priorities, not team size.

Can these automations replace Tally or Zoho Books entirely?

No, and they shouldn't. Tally and Zoho Books stay as the system of record. These automations are a layer that feeds cleaner data into those systems and pulls faster insights out of them.

What is cash application automation and why does it matter for Indian SMBs?

Cash application is the process of matching incoming payments to the invoices they settle. Automating it with AI-based invoice matching shortens the gap between money landing and books being updated from 7-10 days to 24 hours.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Claude Code Changed How I Work — An Honest Developer Review

Archit Mittal — Sat, 12 Sep 2026 12:45:02 +0000

TL;DR: Claude Code is a CLI tool that reads your entire codebase and makes coordinated multi-file changes. It cut my feature development time from 4-6 hours to 1-2 hours. Not perfect for large codebases or visual design, but transformative for real development work.

My Background With AI Coding Tools

I have tried everything. GitHub Copilot for a year. Cursor for six months. ChatGPT for code generation since the GPT-4 launch. Amazon CodeWhisperer. Codeium. Tabnine. I have a strong opinion on what works and what is marketing hype.

Claude Code is different from all of them. Not because it writes better code — although it does — but because it fundamentally changes what "using an AI coding tool" means. This is not autocomplete on steroids. This is a developer sitting next to you who can read your entire codebase, understand your architecture, and make meaningful changes across multiple files.

Let me explain.

What Claude Code Actually Is

Claude Code is a CLI tool from Anthropic. You run it in your terminal, inside your project directory. It can read your files, understand your project structure, run commands, and make edits. The key difference from other tools: it operates on your real codebase, not a chat window where you copy-paste code back and forth.

When I say "fix the authentication bug in the user service," Claude Code will:

Read the relevant files
Understand the codebase context
Find the bug
Edit the files to fix it
Run the tests to verify

All in one go. No copy-pasting. No explaining your file structure. No "here is the fix, now go apply it manually."

What Works Incredibly Well

Multi-File Edits

This is Claude Code's killer feature. Most AI coding tools work within a single file. Claude Code works across your entire project. When I ask it to "add a new API endpoint with validation, database model, and tests," it creates the route file, the model, the validation schema, the tests, and updates the barrel exports — all coordinated and consistent.

I recently used it to add a complete lead capture system to a website. Contact form, API route, JSON storage, Telegram notifications, form validation — across 8 files, all in one session. Would have taken me half a day. Claude Code did it in 15 minutes.

Understanding Existing Code

Claude Code reads your codebase before making changes. It does not guess at your patterns or conventions — it looks at your existing code and follows them. If your project uses a specific error handling pattern, Claude Code will use the same pattern. If you have a constants file, it will add new constants there instead of hardcoding values.

This sounds simple, but it is a massive quality improvement over tools that generate code in isolation. The output feels like it belongs in your project because Claude Code actually read your project before writing.

Explaining and Debugging

Sometimes I do not want code written. I want to understand why something is broken. Claude Code is exceptional at reading a stack trace, finding the root cause across multiple files, and explaining the issue clearly.

Last week, a production deploy failed with a cryptic webpack error. I pasted the error into Claude Code and asked it to debug. It traced the issue to a circular dependency between two modules, explained exactly why it caused the build failure, and fixed it. What would have been an hour of git bisect and console logging was solved in two minutes.

Terminal Integration

Because Claude Code runs in the terminal, it can run your actual commands. npm test, git status, database migrations — it can execute and read the output. When I say "run the tests and fix any failures," it runs the test suite, reads the output, identifies the failing tests, fixes the code, and re-runs the tests.

This feedback loop is incredibly productive. Write code → run tests → fix failures → verify — all without leaving the AI conversation.

What Does Not Work (Yet)

Large Codebase Navigation

On very large projects (50K+ lines), Claude Code sometimes struggles to find the right files. It can read any file you point it to, but discovering which files are relevant in a massive codebase requires some guidance. I have learned to be specific: "look at the auth middleware in src/middleware/auth.ts" rather than "fix the auth bug."

Complex Refactoring

For straightforward refactoring — rename a variable, extract a function, move a file — Claude Code is excellent. For complex architectural refactoring — changing a monolith to microservices, rewriting a state management approach — it needs more hand-holding. The AI works best when the changes are well-scoped.

Frontend Visual Design

Claude Code writes functional frontend code, but it does not "see" the result. If I say "make the button look better," it will change CSS properties, but it cannot evaluate whether the result actually looks better. For visual work, I still use the browser and make adjustments manually.

Rate Limits

During heavy usage sessions, you hit rate limits. This is the reality of API-based tools — there is a cost per token, and extended sessions with large codebases burn through context quickly. I have learned to break my work into focused sessions rather than trying to do everything in one conversation.

How It Changed My Workflow

Before Claude Code

My typical day looked like:

Read the requirement
Plan the implementation in my head
Write code file by file
Copy-paste between files to maintain consistency
Write tests
Debug failures
Iterate

Total for a medium feature: 4-6 hours.

After Claude Code

Read the requirement
Tell Claude Code what I want, with context on constraints and patterns
Review the changes it makes
Run tests, have Claude Code fix any issues
Make manual adjustments for edge cases

Total for a medium feature: 1-2 hours.

The time savings are real, but the bigger change is cognitive. I spend less mental energy on boilerplate and mechanical coding, and more on architecture, design decisions, and code review. I am a better developer because I can focus on the hard problems.

Claude Code vs The Competition

vs GitHub Copilot

Copilot is autocomplete. Claude Code is a collaborator. Copilot suggests the next line. Claude Code understands the task and builds the solution. They are not competing products — they solve different problems. I use both: Copilot for inline suggestions while typing, Claude Code for feature-level work.

vs Cursor

Cursor is closer to Claude Code in ambition. It understands project context and can make multi-file edits. The main differences: Claude Code runs in the terminal (I prefer this — no IDE lock-in), and Claude's model is significantly better at understanding complex codebases and Indian English instructions.

Cursor has better visual integration since it is a full IDE. Claude Code has better reasoning and more reliable code generation. If you live in VS Code, Cursor is convenient. If you live in the terminal, Claude Code is superior.

vs ChatGPT

ChatGPT for coding is a chat window. You paste code in, get code out. There is no project awareness, no file editing, no command execution. For quick questions and isolated code snippets, ChatGPT is fine. For real development work, it is not in the same category as Claude Code.

Tips for Getting the Most Out of Claude Code

Be specific about context. Tell it which files matter, which patterns to follow, which constraints exist. The more context, the better the output.
Work in focused sessions. Instead of one massive conversation, break work into feature-sized sessions. This keeps context sharp and avoids rate limits.
Review everything. Claude Code is good, but it is not infallible. Read the diffs. Understand the changes. Do not blindly accept.
Use it for exploration. When you are unsure how to approach a problem, ask Claude Code to analyze the codebase and suggest approaches. Even if you do not use its code, the analysis is valuable.
Set up your CLAUDE.md. The CLAUDE.md file in your project root tells Claude Code about your conventions, patterns, and preferences. A well-written CLAUDE.md dramatically improves output quality.

Claude Code uses MCP Protocol under the hood for tool connections. I've used it to build systems that saved clients ₹85K/month on AI costs and to create n8n automation workflows in a fraction of the usual time.

The Bottom Line

Claude Code is not a replacement for developers. It is a force multiplier. It handles the mechanical, repetitive, cross-file work that eats up development time, freeing me to focus on the problems that actually require human judgment.

Is it perfect? No. Large codebase navigation needs improvement, rate limits are frustrating during intensive sessions, and it cannot evaluate visual design. But the core capability — understanding a codebase and making coordinated, multi-file changes based on natural language instructions — is genuinely transformative.

I build faster, ship more, and spend more time on the interesting problems. For a developer who values productivity and is comfortable reviewing AI-generated code, Claude Code is the most impactful tool I have adopted in years.

If you want to see how Claude Code can accelerate your development workflow, book a session and I will walk you through a live demo.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Claude Code vs Cursor vs Copilot: An Honest Review After 40 Production Automations

Archit Mittal — Sat, 12 Sep 2026 02:45:04 +0000

₹40,000 to ₹70,000 — that's the extra monthly capacity my consulting practice has picked up since switching my primary dev loop to Claude Code six months ago. Forty production automations shipped in that window: bank reconciliation pipelines, stock screeners, ITR-prep bots, expense categorizers, GST filing helpers, a couple of trading systems I still babysit.

This post is the scorecard. What Claude Code gets right, where it still breaks, and how I decide when to reach for it versus Cursor versus plain GitHub Copilot. No sponsored angle, no affiliate link. I pay for all three out of pocket. What follows is what I'd tell a friend over chai.

The Context — Who This Review Is For

I'm not a web app engineer. I build finance and trading automations in Python, glue them to broker APIs and Google Sheets, and ship scripts that run on cron jobs or Railway containers. If you build similar back-end, script-first work, this review will transfer cleanly. If you're writing React all day, your mileage will differ.

The bar I measure against is brutal. A client automation has to work on day one against real production data, handle every edge case a CA firm can dream up, and be debuggable by me at 11 PM when a trade doesn't fire. No tolerance for "it worked on my machine."

What Claude Code Gets Right — The Four Wins That Actually Matter

1. Multi-file reasoning at a level nothing else touches

Most AI coding assistants play well inside a single file. Claude Code holds an entire repo in its head. I asked it to refactor a bank-reconciliation project that spans eleven modules and 2,300 lines — it traced every call site, flagged one circular import I'd never noticed, and proposed a clean split in a single turn. Cursor starts to struggle past six or seven files. Copilot gives up around two.

2. It asks the right questions before writing code

This surprised me. When I told Claude Code to "add retry logic to the Zerodha order function," it didn't just write it. It asked whether the retry should respect the broker's rate limits, what to do on partial fills, and whether idempotency keys were available. Those are the questions a senior engineer would ask. The answers shape whether the automation is safe for real money or a ticking time bomb.

3. Long-running tasks stay coherent

I regularly hand Claude Code a task that takes 20-40 minutes — "refactor the GST prep pipeline, add test coverage, run the suite, fix any regressions." It plans, executes, self-corrects, and comes back with a diff that's ready to review. The agentic loop is tight. No hallucinated file paths. No code that assumes packages that don't exist.

4. It respects the code that's already there

Copilot rewrites style aggressively. Claude Code reads the file, matches existing conventions, and produces diffs that don't feel foreign two weeks later. For a consulting practice where I hand off code to clients' in-house teams, that matters more than it sounds.

Where Claude Code Still Breaks

Honest time. Three real failure modes I've hit.

1. Indian fintech APIs are still weak ground

Ask Claude Code about the Zerodha Kite Connect SDK and it gets 80% right. The last 20% — ticker formats for F&O, post-2024 margin changes, specific error codes — is where it hallucinates plausibly. I always double-check anything broker-specific against the official docs. For one client I caught it confidently using a parameter name that was deprecated nine months ago. The test suite caught it before production did. Barely.

2. Long debug sessions can loop

If the first three fixes don't resolve an issue, it sometimes cycles — tries approach A, moves to B, comes back to A wrapped in a helper. I've learned to stop the loop manually, paste the stack trace into a fresh context, and state the constraint explicitly ("do not change the signature of X"). The second attempt almost always lands.

3. Cost at scale needs discipline

Unconstrained, a single long agentic task can burn through tokens fast. For a big refactor I'll sometimes spend the equivalent of a cheap dinner in one session. That's still trivial against the time saved, but only if you're measuring. The techniques in how I cut a client's AI API bill from ₹85K to ₹12K/month apply here too — set bounded budgets, use smaller models for simple sub-tasks, and don't let agentic loops run without a ceiling.

Claude Code vs Cursor vs Copilot — When I Use Each

Simple rule of thumb, from six months of real use:

Task Type	My Pick	Why
New automation from scratch	Claude Code	Plans across files, asks clarifying questions
Single-file editing at speed	Cursor	Faster inline completions, tight editor loop
Boilerplate-heavy typing	Copilot	Cheapest, good at the obvious stuff
Large refactor across 10+ files	Claude Code	Nothing else holds this much context
Working in a legacy repo I don't know	Claude Code	Reads and understands before writing
Pair-programming over screen-share	Cursor	Inline suggestions are less disruptive

All three stay installed. Picking the right one is like picking the right screwdriver — the mistake is treating one tool as the answer to every problem.

The Rupee Impact — What 40 Automations Looks Like in Numbers

A summary from my consulting log since switching:

Build time: 38% lower than my pre-Claude baseline on average.
Client revisions: Down by roughly half — better first drafts mean fewer "can you also..." cycles.
Debugging time: Up slightly, because I now take on projects I wouldn't have before.
Capacity: ₹40,000-₹70,000 of extra billable capacity per month. Over six months, a real second income line without hiring anyone.

The same tooling shift that helped me ship a weekend Python script that saved a CA firm 209 hours during ITR season is now the default for every new project — from the stock screener that replaced a ₹47K/month advisory to the full CFO playbook of five finance automations I rolled out to two SMBs this quarter.

The Non-Obvious Tip Most Teams Miss

The setting that changed my workflow most: a CLAUDE.md file at the root of every project. Claude Code reads it automatically. I put project context, naming conventions, the specific broker API version we're using, and our testing rules. It's the difference between getting a generic Python suggestion and getting a suggestion that knows we use Pandas 2.2, pytest, and a specific way of mocking Kite Connect.

If you skip this step, you're using maybe 60% of the tool. I've seen teams adopt Claude Code, get indifferent results, and blame the model. Nine times out of ten, the CLAUDE.md was missing or empty.

Should You Switch?

If you're already on Cursor and happy, don't rip it out. Layer Claude Code on top for planning and large refactors and see how the split feels for a month. If you're still on Copilot-only and doing anything more complex than boilerplate, the jump to Claude Code is the single highest-ROI tooling change I've made as an automation consultant this year.

"Jo tool sahi kaam karta hai, wohi chuno." (Pick the tool that does the actual job.)

Not everything should be automated, and not every process should be shipped with an AI pair programmer either. For production automations where quality and context matter more than keystroke speed, Claude Code is the best tool I've used. The ceiling is high. The floor is higher than any other assistant I've tried.

Which AI coding tool are you reaching for most right now — and for what kind of work?

FAQ

Is Claude Code better than Cursor for most developers?

It depends on the task. For multi-file refactors, planning a new automation from scratch, and working in legacy code you don't know, Claude Code is stronger. For rapid single-file edits and inline completions during active typing, Cursor feels faster. Most serious developers benefit from keeping both and picking by task.

How much does Claude Code cost in real production use?

For a consulting workload of two to three hours of agentic coding per day, typical spend lands between ₹2,000 and ₹6,000 a month. A single large refactor session can consume ₹200-500 in tokens. Still tiny versus engineering hours saved, but it requires bounded budgets.

Does Claude Code work well with Indian fintech APIs like Zerodha Kite Connect?

About 80% of the time. For common Kite Connect patterns it's accurate. For edge cases like F&O ticker formats or post-2024 margin changes, it can hallucinate plausible but wrong parameters. Always validate broker-specific code against the official docs before shipping real trades.

What is the single most important setup step for getting value from Claude Code?

Write a CLAUDE.md file at the root of every project. It tells the model your conventions, library versions, test rules, and domain context. Skip it and you get generic suggestions. Write it well and the same tool produces project-specific code from the first prompt.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Automate Collections Before Marketing: Chase Money You Already Earned

Archit Mittal — Fri, 11 Sep 2026 12:45:05 +0000

The first automation you build should chase money you have already earned. Not leads. Not content. Not a chatbot that answers enquiries at two in the morning. A payment follow-up sequence, running against your own ageing report, on your own invoices, to your own customers.

The reason is unglamorous: you already know what it is worth. Open your receivables ledger and the number is sitting there, named, dated and attributable to a specific person who has already agreed to pay you. Nobody has to model anything. If the sequence pulls forward a chunk of that money, you can point at the invoices and say which ones moved.

Now open a proposal for a lead-generation bot. Every figure in it is a guess multiplied by another guess. Leads captured, times a conversion rate you have assumed, times an average order value that is really a range, times a close rate that depends on a salesperson who may not be here next quarter. Four assumptions stacked on top of each other, and the output is a number with a decimal point in it, which is how you know it is fiction.

Both projects cost roughly the same to build. Only one of them lets you check afterwards whether you were right.

The ledger is the only honest brief you will get

Most automation projects start with someone describing a problem. Collections starts with a spreadsheet that describes it for you.

Pull your ageing report. Sort by days outstanding. Almost every business I have looked at finds the same shape: a long tail of invoices sitting well past terms, most of them belonging to customers who are neither disputing the amount nor in any distress. They simply have not been asked recently, and nobody in your office wants to be the one to ask.

That last part is the actual problem. It is not a process problem. Your accounts person knows the invoice is overdue. They can see it on the same screen you can. What they do not have is a comfortable way to raise it for the fifth time with a distributor whose owner your father knows, or a client whose next order is worth more than this bill.

Automation solves that specific discomfort well, because a scheduled system does not feel awkward. It sends on day seven whether or not anyone is in the mood. And when the customer rings up annoyed, the answer is structural rather than personal: the system flags everything past terms, it is not aimed at you. That sentence has repaired more relationships than any softening of the wording ever did.

What the sequence actually looks like

Keep it duller than you want to.

A trigger on invoice due date. A polite reminder a few days before it falls due, which is the single highest-yield message in the whole sequence and the one most businesses skip entirely, because it feels like nagging someone who has not yet done anything wrong. It is not nagging. It is the message that catches the invoice that never reached the right person, that went to a mailbox nobody reads, that arrived without a purchase order number and got parked.

Then a message on the due date. Then a short escalation ladder afterwards, each step slightly firmer, each one carrying the invoice number, the amount and a payment link or UPI QR in the message itself. Not "please find attached". Attached is where money goes to die. The customer is reading on a phone, standing in a warehouse, and if paying you requires opening a laptop, they will do it later and later means never.

Every step logs to one place so you can see, per customer, exactly what has gone out and when. And there is a hard stop: the moment a human replies, the sequence pauses and a person takes over. A reminder that keeps firing at somebody who has already said "cheque is ready, courier tomorrow" does more damage than the delay ever did.

That is the whole system. Six or seven messages, one condition, one kill switch. You can build it on WhatsApp Business with your accounting software's export, and if your Tally or Zoho or Busy data has to be pulled by hand into a sheet every Monday morning, that is fine. A manual export feeding an automated sequence still works. Do not let the integration become the project.

The distributor example

Take a manufacturer selling through distributors on thirty-day credit. Orders come in on WhatsApp, invoices go out on email, and payments arrive whenever the distributor's own collections happen to land. The owner knows which parties are slow. Everyone knows.

What actually happens in that business: the sales person who owns the distributor relationship is also the person expected to chase payment. Those two jobs are in direct conflict. He is asking for the next order and last month's money in the same conversation, so he asks for the order and lets the money slide, because his incentive is measured on the order.

The reminder sequence removes the collections job from him entirely. He keeps the relationship. The system keeps the calendar. When something genuinely needs a conversation — a disputed quantity, a damaged consignment, a real cash crunch at the distributor's end — the reply arrives, the sequence stops, and now he is having a useful conversation about one specific problem rather than an uncomfortable one about a general pattern.

The same shape applies if you are a services firm invoicing monthly retainers, a clinic with insurance claims, or an agency waiting on milestone payments. Wherever the person who owns the relationship is also the person expected to chase the money, the chasing loses.

Where this does not work, and you should not build it

I would rather tell you this now than after you have paid for something.

Your invoices are wrong or late. If bills go out days after delivery, if amounts get disputed regularly, if GST details are frequently incorrect and invoices come back for revision, do not automate reminders. You will be automating an argument. Every reminder will trigger a correction cycle, your accounts person will end up with more work than before, and your customers will learn that your messages are noise. Fix invoice accuracy and timing first. That is a process job, not a software job, and it is usually one person and one checklist.

You have very few customers. If your entire receivables ledger fits on one screen and your top handful of accounts make up most of the money, you do not need a system. You need one person to make a few phone calls on the first working day of the month. Automation earns its keep on volume and repetition. Below a certain count, the setup and maintenance cost more than the calls.

The money is stuck for structural reasons. Government contracts held up in sanction, insurance claims stuck in adjudication, an enterprise client whose vendor portal is the real bottleneck — none of these are affected by a reminder. The delay is not attention. It is process, somewhere you cannot reach. Sending five WhatsApp messages into that will change nothing except how your contact feels about you.

One relationship dominates. If a single customer's goodwill decides whether your year works, do not point an automated ladder at them. Handle it personally. Automate the rest.

There is also a fifth case worth naming: if your business genuinely gets paid up front, in full, before delivery, then you have no collections problem and this entire argument does not apply to you. Go build the lead-gen bot. You are the exception.

Why marketing automation keeps jumping the queue

Because it is more fun to build and easier to sell.

Marketing automation has a story. Collections automation has a spreadsheet. When you build a lead capture system, you get dashboards, funnel diagrams and a sense of momentum. When you build a reminder sequence, you get a WhatsApp thread and some slightly awkward customers. Nobody puts a payment reminder ladder in a case study.

It is also unfalsifiable, which is a feature if you are the one selling it. Leads went up? The bot worked. Leads went nowhere? The market was soft, the creative was wrong, we need more top-of-funnel. There is no state of the world in which a lead-gen automation is clearly shown to have failed. Collections does not offer that cover. The receivables number either moved or it did not, and it is visible in the ledger by the end of the month.

I have built both. The marketing systems were more interesting to build. The collections systems were the ones owners still had running a year later, because the value never became ambiguous. A thing you can measure is a thing you keep paying for.

And there is a sequencing argument beyond measurement. More leads with unchanged collections gives you more revenue you have not been paid for yet — more working capital tied up in the same slow customers, at a scale you now have to fund. Sorting out the money side first means every additional sale that follows converts to cash faster. Do the demand generation second, on top of a collections process that works. Do it first, and you are pouring water into a bucket you have not checked for holes.

Do this week

Export your receivables ageing report and sort it by days past due. Take the invoices that are past terms and belong to customers who are not disputing anything and are not in trouble — the ones that are simply old because nobody asked. Add up the total.

That number is the budget and the business case for your first automation, and it took you twenty minutes to find. Anything a lead-gen proposal quotes at you will take a quarter to prove and will still be arguable.

If the number is meaningful, write out the seven messages by hand this week and have someone send them manually to the ten oldest invoices. Do not build anything yet. Watch what comes back — the disputes you did not know about, the invoices that never arrived, the ones that pay within a day of being asked. That fortnight of manual sending is what tells you whether to automate at all, and it costs nothing but a person's afternoon.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

Don't Hire a Prompt Engineer. Hire Someone Who Owns the Process

Archit Mittal — Fri, 11 Sep 2026 02:45:05 +0000

If you run a business and you are thinking about hiring a prompt engineer, stop. The skill you are trying to buy is not writing clever instructions to a chatbot. The skill you need is someone who can take one messy process in your business, own it end to end, and be answerable when it breaks. Prompting is about two weeks of that person's learning curve. The other eleven and a half months is process.

I say this as someone who builds automation systems for a living. It would be convenient for me to tell you the opposite. But I have watched enough of these systems fail in real businesses to know exactly where they fail, and it is almost never in the prompt.

Where the job title came from, and why it does not fit you

The prompt engineer role made sense inside large AI companies, where a full-time person squeezing a few per cent more accuracy out of a model was worth it because that model served millions of requests. That logic does not transfer to a business doing fifty lakh to fifty crore a year. You do not have millions of requests. You have a few hundred WhatsApp enquiries a month, a GST cycle, some distributor orders, and a founder doing three jobs.

At your scale, the prompt is rarely the bottleneck. The bottleneck is that nobody in the business can write down, on one page, what actually happens between "customer sends a message" and "money arrives in the account". Until someone can, no prompt will save you.

A worked example: WhatsApp enquiries

Take the most common request I get: "automate our WhatsApp enquiries with AI."

A prompt engineer approaches this as a writing problem. They craft a beautiful system prompt: tone of voice, product knowledge, escalation phrases. In a demo, it is genuinely impressive. You approve it, it goes live, and within a month it is quietly making things worse. Here is why.

A customer asks whether the product can be delivered to Indore before Tuesday. The model does not know your courier's actual cut-off times, so it guesses, politely and confidently. Another customer asks for a discount; the bot has no idea what your margins allow, so it either refuses good customers or agrees to things you never authorised. A third sends a photo of a damaged shipment; the flow has no path for complaints, so the bot cheerfully asks if they would like to see the catalogue. None of these are prompt failures. They are process failures: nobody decided what the courier cut-offs are, who can approve discounts, or where complaints go.

Now watch what a process owner does with the same brief. Before touching any AI tool, they sit with whoever currently answers the phone and list every type of message received in the last month. They discover that a large share of enquiries are the same four questions: price, delivery time, stock, and payment terms. Those four get precise, owner-approved answers, and the AI's only job is to recognise which of the four is being asked and reply with the approved text. Everything else, including anything involving anger, money, or a photograph, gets routed to a human within minutes, with the bot saying honestly that a person will respond.

That system is less impressive in a demo. It is enormously more valuable in production, because it fails safely. When it does not know, it hands over instead of improvising. The prompt inside it is almost embarrassingly simple. The process around it is where all the work went.

What each hire actually delivers in a month

Strip away the titles and compare what lands in your business after thirty days.

The prompt engineer's month. Week one: exploring your use cases, playing with tools. Weeks two and three: building prompts and demos, most of which look great on screen. Week four: the demos meet reality, and the gaps appear, because the gaps were never in the prompts. What you own at the end: a set of clever instructions that depend entirely on this person staying, some impressive screen recordings, and no change to how the business actually runs. The prompts themselves are also a depreciating asset. Models change every few months; what worked on this quarter's model needs rework on the next. You have bought a consumable and paid for it like an asset.

The process owner's month. Week one: they map one process, on paper, by talking to the people who do it. This alone usually surfaces problems no software can see: the accountant re-enters the same data three times, two people both think the other one confirms distributor orders, half the delayed GST filings trace back to invoices sitting in one salesperson's phone gallery. Week two: they fix the parts that need no technology at all: a decision about who approves what, a shared folder instead of a phone gallery, a rule for when an order counts as confirmed. Week three: they automate the two or three steps that are genuinely mechanical, using AI where it helps and a plain spreadsheet rule where it does not. Week four: they write down how it works, so it survives them leaving, and they watch it run, because week-one automations always break in week four.

What you own at the end: one process that runs measurably better, documentation, and a person who now understands your business one level deeper and can repeat the exercise on the next process. That compounds. The prompt engineer's output does not.

The market has noticed, incidentally. Standalone prompt-engineering roles are already being folded into ordinary operations and engineering jobs, because prompting turned out to be a skill any capable person picks up in weeks, not a profession. Do not build a hire around a title the market is already dissolving.

The part nobody selling AI will tell you

Some things in your business should not be automated, and a good process owner will tell you so. This is the clearest test of whether you have hired the right person: do they ever say no?

Do not automate GST filing decisions. Software can prepare, reconcile, and flag; the decision to file, and the judgement calls on classification and input credit, belong with your accountant or CA, because they carry the consequences. An AI that confidently mis-classifies a transaction does not get the notice from the department. You do.

Do not automate anything where the message is the relationship. If a distributor who has been with you for ten years sends a complaint, an instant, fluent, obviously automated reply is worse than a slow human one. He is not writing to get information. He is writing to be heard.

Do not automate a process you have never run manually. Automation freezes a process in its current shape. If the process is broken, you now have a machine producing the broken outcome faster and with more confidence. Run it by hand, fix it, then automate the fixed version.

And do not automate your way around a people problem. If staff keep leaving a role, the tempting move is to replace the role with AI. But attrition is usually a symptom, of pay, of a bad manager, of a job designed badly, and the AI replacement inherits the badly designed job. Fix the design first. Sometimes the fixed job is worth automating; often it stops being a problem at all.

A prompt engineer has no standing to raise any of this. It is outside the job description. A process owner cannot avoid it, because they own the outcome, not the tool.

Who this person actually is

You may not need to hire anyone new. In most businesses of this size, the right person already works for you: the operations manager who everyone goes to when something is stuck, the accounts person who built the spreadsheet the whole company secretly runs on. They already understand the processes. Teaching them to use AI tools is a matter of weeks. Teaching an outside prompt specialist your business is a matter of years, if it happens at all.

If you do hire from outside, interview for process, not prompts. Ask them to describe a system they built that failed, and what broke. If every answer is about model behaviour and none is about people, handoffs, or exceptions, they have only ever worked in demos.

What to do this week

Pick the one process that irritates you most, most likely your enquiry handling, your collections follow-up, or your order confirmation, and ask one person in your business to write down every step of it as it actually happens today, including the informal steps that live in someone's head. One page, plain language, real steps.

Read that page. You will find at least one step that exists for no reason and at least one where nobody is sure who is responsible. Fix those two things by decision, not by software.

Only then ask what AI can do for the rest. You will find the question has become much smaller, much cheaper, and finally answerable. That page, and the person who wrote it, are worth more than any prompt you will ever buy.

I write about automation and the systems I actually run at architmittal.com. Originally published there.

How I Saved a Client ₹85K/Month on AI API Costs

Archit Mittal — Thu, 10 Sep 2026 16:59:10 +0000

TL;DR: I reduced a client's AI API bill from ₹95K/month to ₹10K/month (97.5% reduction) using semantic caching, model switching, batch processing, and prompt optimization. Caching alone cut costs by more than half.

The ₹95K Wake-Up Call

A few months ago, a mid-sized e-commerce client came to me with a problem that made my jaw drop. They were spending ₹95,000 per month on OpenAI API calls — and climbing. Their product description generator, customer support chatbot, and review summarizer were all making raw API calls with zero optimization. Every single user interaction was a fresh, expensive hit to GPT-4.

By the time I was done restructuring their AI pipeline, that bill was down to ₹10,000 per month. A 97.5% reduction. No loss in quality. No degraded user experience.

Here is exactly how I did it — and how you can apply the same strategies to your own AI-powered applications.

Step 1: Audit Every Single API Call

Before touching any code, I spent two days doing something most developers skip — actually understanding what the API was being used for. I instrumented their codebase with logging to capture every call: the prompt, the model, the token count, and the response time.

What I found was staggering:

68% of calls were near-duplicates. Slight variations of the same product description prompt were being sent hundreds of times per day.
22% of calls used GPT-4 for tasks GPT-3.5-turbo handled identically. Things like formatting text, extracting keywords, and generating meta tags.
The remaining 10% were legitimately complex tasks that genuinely needed a powerful model.

This breakdown gave me a clear roadmap. If you are spending more than ₹20K per month on LLM APIs without having done this audit, you are almost certainly overpaying.

The Audit Approach

I built a lightweight wrapper that captured call metadata — the prompt hash, model used, input/output tokens, estimated cost, and calling endpoint. After running this for a week, I had a full picture of where money was going and which calls were redundant.

The key insight: most teams have no idea what their AI is actually doing. They built it, shipped it, and stopped looking at the bills until the finance team complained.

Step 2: Implement Semantic Caching

This single change cut costs by more than half. The idea is simple: if someone asks a question that is semantically similar to a question you have already answered, serve the cached response instead of making a new API call.

I used Redis with vector embeddings for similarity matching. The threshold was critical — 0.95 similarity. Too low and you serve irrelevant cached answers. Too high and the cache never hits. I arrived at 0.95 after testing with 500 real prompt pairs.

Cache Hit Rates by Use Case

After a month of production data:

Use Case	Cache Hit Rate	Monthly Savings
Product descriptions	78%	₹31,000
Support chatbot	45%	₹18,000
Review summaries	82%	₹9,000

The product description and review summary caches performed exceptionally well because the inputs were structured and repetitive. The chatbot was lower because conversations are inherently more variable, but 45% is still significant.

Step 3: Smart Model Switching

Not every task needs GPT-4. This sounds obvious, but I see teams defaulting to the most expensive model for everything because "it works." That is like taking a helicopter to the grocery store.

I built a simple router that classified incoming requests and assigned them to the cheapest model that could handle the task:

Keyword extraction, formatting, meta tags → GPT-3.5-turbo (cheapest)
Product descriptions, support responses → GPT-4o-mini (mid-range)
Complex analysis, strategy content → GPT-4o (premium, used sparingly)

The trick is validating that the cheaper model actually produces acceptable output. I ran A/B tests for two weeks, comparing outputs on every task type. For keyword extraction and formatting, the outputs were indistinguishable. For product descriptions, GPT-4o-mini was 95% as good at 1/10th the cost.

This model routing alone saved another ₹22,000 per month.

Step 4: Batch Processing for Non-Real-Time Tasks

The review summarizer was running in real-time — every time a new review came in, it triggered an API call. But nobody needed instant summaries. The summaries were displayed on product pages that updated once a day.

I moved review summarization to a nightly batch job that processed all new reviews at once, grouped by product. Instead of 200+ individual calls per day, we made 20-30 batched calls per night.

Batching also enabled better prompt engineering — sending multiple reviews in a single prompt produces better summaries than processing them one at a time, because the model can identify common themes and contradictions.

Step 5: Prompt Engineering for Token Efficiency

The final optimization was unglamorous but effective — rewriting prompts to use fewer tokens while producing the same output.

Their original product description prompt was 380 tokens of meandering instructions. I rewrote it to 95 tokens with clearer, structured requirements. The responses were actually better because the model had less ambiguity to deal with.

That 75% reduction in prompt tokens compounded across thousands of daily calls. Small on a per-call basis, but it adds up to ₹1,500 per month.

The Final Numbers

Strategy	Monthly Savings
Semantic caching	₹58,000
Model switching	₹22,000
Batch processing	₹3,500
Prompt optimization	₹1,500
Total	₹85,000

The new monthly bill: approximately ₹10,000. The client was thrilled, and the system actually performed better because we had reduced latency through caching and right-sized the models for each task.

If you're evaluating automation tools, check out my n8n vs Zapier comparison. For AI agent infrastructure, read about MCP Protocol — the USB port for AI. And if you want to see the tool I use daily for building these optimizations, here's my honest Claude Code review.

Key Takeaways

Audit first. You cannot optimize what you have not measured. Spend time understanding your usage patterns before making changes.
Cache aggressively. Semantic caching is the single highest-impact optimization for most applications.
Match the model to the task. Use the cheapest model that produces acceptable output. Test this rigorously.
Batch when real-time is not required. Not every AI feature needs sub-second responses.
Optimize prompts. Shorter, clearer prompts save tokens and often produce better results.

If you are running AI features in production and your monthly API bill makes you uncomfortable, start with step one. The audit alone will reveal opportunities you did not know existed.

I help businesses optimize their AI infrastructure every week. If you want a personalized audit of your AI API costs, get in touch.

I write about automation and the systems I actually run at architmittal.com. Originally published there.