Stop doing the same task twice

Business process automation means the software does the repeated steps of a process, and people do the thinking. In most small and mid-size businesses, the work that eats the day is not hard. It is the same order details typed into three tools, the same report rebuilt every Monday, the same approval chased by phone.

An automated process waits for something to happen, such as an order being paid, a form being submitted or a date coming round, and then carries out the steps your team would have done: checking the data, updating each system, creating the document and sending the message. Where a decision is needed, it asks the right person and waits for the answer.

The aim is simple. Each piece of information is entered once, by the person who knows it, and every other place that needs it receives it automatically.

Start with the process your team repeats most and enjoys least. We find it by following real cases: an order from enquiry to payment, an employee from punch-in to payslip, a supplier bill from email to the accounts.

For each step we note who does it, in which tool, how long it takes and what goes wrong. Steps that copy data from one screen to another, rebuild the same document or wait for someone to remember are the clearest candidates. Steps that need judgement, negotiation or a conversation stay with people.

We then rank the candidates by the time they cost, the mistakes they cause and how clear their rules are. That ranking becomes the plan: one process first, then the next.

Most businesses find their first candidates in the same places:

• Sales: enquiries from the website, WhatsApp and marketplaces landing in one list, quotes built from the price list, follow-ups sent on schedule.
• Accounts: invoices raised from orders, payments matched to invoices, overdue reminders sent, entries posted to Tally or your accounting software.
• Operations: dispatch documents, e-invoices and e-way bills created from the packing list, and stock updated across shops and marketplaces.
• People: attendance matched to shifts, leave approvals, payslips by email, and joining and exit checklists.
• Management: daily and weekly reports built from live data and sent before the working day starts.

Each of these is ordinary work. Together they are often the difference between a team that is always behind and one that has time to think about the business.

Most automation needs no AI at all. If an order is paid, raise the invoice; if an invoice is 15 days overdue, send the reminder; if a request is above a limit, ask the owner. Clear rules are fast, cheap to run and easy to check, so we use them wherever they work.

AI earns its place where the input is messy: a supplier’s email that might be an order, a question or a bill; a scanned document whose fields have to be read; a summary or a reply that has to be written. There, AI reads, sorts or drafts, and the rules around it decide what happens next.

When AI output could cost money or upset a customer, a person checks it before it goes any further. As the checks show it is reliable for a kind of case, that check can be relaxed, one kind of case at a time.

Automation works through the software you already use: your accounting package, online store, CRM, HR system, spreadsheets, email and WhatsApp. We connect each one through its API where it has one, and build a small bridge where it doesn’t, such as reading a scheduled export or watching a shared folder.

In India, many processes end in a government system. Through authorised GST API providers, a workflow can generate e-invoices and e-way bills from your own records, so nobody types them into the portal by hand. Payment gateways confirm UPI and card payments, and bank statements can be matched against open invoices.

Each connection uses its own account with only the permissions it needs, so every change the automation makes is visible in that tool and can be traced back to the run that made it.

A good automation knows when to stop and ask. We write the exceptions down with you: a discount above the usual limit, a payment to a new supplier, a customer over their credit limit, a document with missing details.

When one occurs, the run pauses and the right person gets a clear request on their phone or by email, with the facts they need to decide. Once they approve or reject it, the run carries on or stops, and the decision is recorded with their name. Requests that wait too long move to a second person.

This is often where automation pays off first, because approvals that used to wait days in an inbox are answered while the person is between meetings.

Automating a process needs three things from your side: someone who knows the work, access to the tools and real examples. The person who does the task today is the most useful person in the project, because they know the exceptions no written procedure mentions.

Access means a test account or sandbox in each tool where one exists, so we can build without touching live data, and later an account for the automation itself, with limited permissions. Examples mean a few weeks of real cases: orders, invoices, emails and attendance files, including the awkward ones.

You also need an owner: one person who approves the rules, reads the monthly summary and decides what to automate next. They don’t need to write code, but they should feel the pain the process causes today.

Automation that fails quietly is worse than none. We build every workflow to fail loudly: if a step cannot finish, the run stops, the right person is told what went wrong, and the run is retried from that step once the cause is fixed.

Every run is logged with its inputs, each step’s result and the time it took. Before launch, the workflow runs on your past cases and its results are compared, line by line, with what your team actually did. The manual process stops only when they match.

We also plan for change. GST rates, price lists, approval limits and message templates live in settings your team can see and update, rather than buried in code.

Before we automate anything, we time the process as it runs today: how long each case takes, how often it goes wrong and how long it waits between steps. Those figures become the baseline.

After launch, the run log produces the same figures automatically: how many runs finished on their own, how many needed a person, how long approvals took and which steps failed. A monthly summary sets them beside the baseline, so you see what changed in your own terms rather than ours.

The log also points to what to automate next. The exceptions that come up most often are usually the next rules worth writing.

Processes change as the business grows. New products, a new branch, a new tax rule or a new approval limit all need the automation to change with them.

We look after the workflows with you: we review failed runs, update rules and connections when your tools or regulations change, and add the next process once the first has settled. Because each new process reuses connections that already exist, the second and third are usually quicker to build than the first.