Vineeth K Kolarath
Whenever people talk about machines and work, the same question comes up.
"Will a machine take my job?"
It is a fair question. If you depend on your work to support yourself and your family, you have every reason to ask it.
But I think there is a better place to begin.
A job is rarely one single thing. It is a collection of smaller tasks. Some happen in much the same way every day. Others need judgement, patience, experience or a relationship with another person.
A machine may be able to take over some of those tasks. It may help with others. And some are better left in human hands.
So instead of asking, "Can a machine do this job?", try asking a different question.
Which parts of this job would actually be better done by a machine?
That is where useful automation begins.
A job is a bundle of tasks
Think of a small provision shop near a bus stop. The kind you find in towns and villages across India.
Ask the shopkeeper what they do for a living, and the answer might be simple.
"I run a shop."
But spend a little time there, and you will see that the work involves many different things.
- Opening the shop and arranging the shelves.
- Checking which items are running low.
- Contacting suppliers and placing orders.
- Taking payments, in cash and through UPI.
- Recording credit given to regular customers.
- Following up on unpaid amounts.
- Helping customers choose what they need.
- Counting the day's money and checking the accounts.
All of that belongs to one job. But each item on the list is a different task.
Some tasks are predictable. A payment arrives, and the sale needs to be recorded. A stock count is completed, and the quantity needs to be updated.
Other tasks depend on the situation. A customer may ask for a cheaper alternative. Someone who usually buys on credit may need a little more time to pay. A supplier may be out of stock just when the shop needs something urgently.
The difference matters.
Before thinking about an app, a computer or a machine, learn to see the smaller tasks hidden inside a job.
That is the first habit I want you to build.
What is a process?
A process is simply a series of steps that takes us from a starting point to a result.
Let us return to the shopkeeper's stock check.
- Check how much of each item is left.
- Record the quantities.
- Compare the quantities with expected demand and the shop's replenishment rules, such as the minimum amount of each item to keep in stock.
- Identify the items that need replenishing.
- Prepare an order.
- Review the order and send it to the supplier.
The starting point is the stock available in the shop. The result is an order that has been prepared and sent.
Notice how much clearer the work becomes when we write down the steps.
We can ask which information is needed at each step. We can see where a mistake might occur. We can decide which steps a machine could handle and where someone should check the result.
But there is an important detail here.
A process does not have to be simple to be automated. Some complicated processes can be automated too. And a process written down neatly is not automatically a good candidate for automation.
We need to understand what the process does, how often it happens, what it costs us and what might go wrong.
Now consider a conversation with a customer.
You could certainly write down some steps for welcoming a customer, answering common questions or recording an order. Businesses already automate parts of these interactions.
But the conversation may take an unexpected turn. The customer may be worried, confused or asking for something unusual. A written procedure cannot anticipate every situation, and a machine may not recognise when it has reached the limits of what it can handle.
That does not mean the entire conversation must always remain manual. It means we need to decide carefully which parts can be automated and when a person should take over.
Four questions to ask
When you look at a task, ask four questions.
1. Does it repeat?
A task that happens every day may offer a good opportunity for automation. But frequency alone is not enough. Multiply the time a task takes by how often it happens. Then compare that with the time needed to build and look after a system. A few seconds, done hundreds of times a day, can add up to a lot. A few minutes, done once a month, may not.
2. Can I describe what needs to happen?
Can you explain the expected result, the information needed and the conditions that change what happens next?
If you cannot explain the task clearly, spend some time understanding it before building anything. Some tasks involve uncertainty that cannot be captured in a simple list of rules. They may still be candidates for automation, but they need a different approach.
3. What happens if it goes wrong?
A stock count that is slightly wrong may be caught during the next check. A payment sent to the wrong person may be much harder to recover. A mistake involving medicine or patient care can have serious consequences.
The more costly the mistake, the more carefully the system needs to be designed, tested and monitored. In some situations, a qualified person must make or approve the decision.
4. Does it need human judgement or trust?
Does the task depend on understanding a particular person's circumstances? Does it involve an unusual situation, a sensitive conversation or a decision that affects someone's life?
If so, think carefully about what should remain with a person. A machine may still help by gathering information, preparing options or handling routine steps.
These questions will not give you a perfect answer every time. They will help you ask better ones.
For the provision shop, recording payments, updating stock quantities and preparing routine reports may be good starting points. Deciding whether to extend credit to someone in difficult circumstances needs more care.
The goal is not to automate as much as possible.
The goal is to make the work better.
Write it down before you build anything
This is where I would ask you to slow down.
You have spotted a repetitive task. You can already imagine the app that will make it easier. Perhaps you are thinking about a spreadsheet, a small program or a circuit board.
Wait a moment.
First, write down how the task is actually done today.
Not how you think it should happen. Not how someone says it usually happens. How it really happens, including the exceptions.
Watch the work if you can. Ask the person doing it to walk you through the steps. Find out what information they need, where they get it and what they do when something unexpected happens.
You may discover that two people do the same task in different ways. A step that seems essential may exist only because of an old problem. Or the real delay may be somewhere you did not expect.
Writing the process down helps you see these things before you spend time building a solution.
It also gives you something to compare against later. Is the new system actually saving time? Are there fewer mistakes? Has the work become easier for the person doing it?
And here is a warning worth remembering.
Automating a bad process does not automatically make it a good one.
If the steps are confusing, fix what you can first. If the process contains unnecessary work, remove it where appropriate. Then consider which remaining steps are worth automating.
A machine can make a poor process run faster. That does not make the outcome better.
Start with one small step
Once you understand the process, resist the temptation to automate everything at once.
Choose one part of the work. Preferably something that takes time, gets forgotten or produces errors that are easy to detect and correct.
Automate that part first. Leave the rest alone until you understand how the change works in practice.
Return to the shopkeeper.
Perhaps the shop has a notebook recording credit given to regular customers. Every Saturday, the shopkeeper goes through the pages to see which payments are overdue.
Some weeks, the reminders go out. Other weeks, the shop gets busy, and the task is postponed.
You might build a simple system that keeps the records digitally and prepares a list of customers whose payments need follow-up.
The system could even draft a polite reminder for each customer.
But I would begin by letting it prepare the reminders, not send them automatically.
The shopkeeper reviews the list. Perhaps one customer has already paid. Perhaps someone has asked for more time. Perhaps a reminder would be inappropriate that week.
The machine does not necessarily know those things. The shopkeeper may.
This is a small example, but it shows the shape of a sensible first automation.
The machine handles the record-keeping and remembering. The person reviews the circumstances and decides what to do.
Once the process has been tested and the risks are understood, some parts may safely be automated further.
There is no need to begin with the most complicated version.
Keep a person involved where it matters
Engineers often use the phrase human in the loop. In simple terms, it means that a person participates in or reviews a system's work at important points.
But putting a person in the process does not guarantee that everything will be safe.
Imagine a person who receives fifty automated recommendations every hour. If they are expected to approve each one in a few seconds, they may begin clicking through without really checking. They may trust the system because it has usually been right before.
Researchers call one form of this problem automation bias: people can place too much trust in an automated system, even when its recommendation is wrong.
So the question is not simply whether a person is present.
It is whether that person has enough information, time and authority to notice a problem and intervene.
For a routine shop report, an occasional review may be enough. For a payment, you may want confirmation before money moves. For a high-stakes decision, you may need stronger safeguards, qualified oversight and a clear way to stop or reverse an action where possible.
Consider a small clinic.
A system might send patients appointment reminders the day before their visit. Staff can check that the right patient, date and time are attached to each message. The system can save repetitive work, while the clinic retains responsibility for handling exceptions and correcting errors.
Two more details matter here. First, the message should carry as little as possible. The date and time are enough. The reason for the visit does not belong in a text message that someone else might read. Second, the clinic needs to keep phone numbers up to date, so each reminder reaches the right person and not a family member's old number.
That is different from automating a clinical decision. Treatment depends on a patient's circumstances, medical evidence and professional judgement. Software may support a clinician, but the appropriate level of oversight depends on what the software actually does and the risks involved.
As you gain experience, you may decide that some tasks can run without approval every time. That is reasonable when the process is well understood and the consequences of an error are manageable.
But do not give a machine more responsibility merely because it has worked well for a few days.
Test it. Observe its mistakes. Understand what happens when information is missing or something unusual occurs.
Trust should grow from evidence, not excitement.
Where this sits on the ladder
In my previous essay, What Is a Thinking Machine?, I described a simple ladder with four rungs.
A plain machine follows. An automatic machine reacts. A deciding machine chooses. A learning machine improves.
We can use the same idea to think about process automation.
A reminder prepared according to a schedule follows a rule. A system that flags an item when its stock falls below a set level reacts to a condition. A system that compares suppliers and recommends an order makes a choice.
But choosing the cheapest supplier is not necessarily the same as choosing the best one. Delivery time, product quality, reliability and other costs may matter just as much as the listed price.
Learning comes later.
Suppose the shopkeeper records sales, stock levels, delivery delays and seasonal demand. Over time, those records may help a suitable learning system estimate which products are likely to sell more quickly during a festival.
The quality of that estimate will depend on the data available, how relevant it is and how well the system is designed and tested. A year of records may be useful, but it is not a magic threshold. Some patterns require several seasons of information, while other tasks may need much less.
And the system should not simply place every predicted order without considering stock on hand, supplier availability and the cost of getting the prediction wrong.
You do not need to begin with learning. You do not even need artificial intelligence for many useful forms of automation.
A spreadsheet that calculates totals correctly can save time. A reminder that prevents a missed deadline can be valuable. A simple sensor that alerts someone when a water tank is nearly empty can solve a real problem.
Start where the problem is clear and the solution can be tested.
What should stay human?
I want to spend a little more time here because this is where the purpose of automation becomes important.
Some tasks depend on relationships.
A customer who has been visiting the same shop for twenty years is more than a name in a database. The shopkeeper may know the customer's preferences, understand their circumstances and recognise when something is not quite right.
A computer can help remember purchases or keep accurate records. That does not mean the relationship itself needs to be automated.
Some tasks involve judgement under uncertainty. A machine may compare options, identify patterns or suggest a course of action. But when the circumstances are unusual, the available information is incomplete or the consequences are serious, people need to think carefully about what to do.
And some tasks are simply not worth automating.
If a job takes two minutes a week, and building and maintaining a system takes several hours, the system may create more work than it removes. Sometimes a checklist or a better notebook is all that is needed.
Finally, there are decisions that carry responsibility.
A system can help organise information, calculate options or flag a possible problem. But if a decision affects someone's health, livelihood, money or future, we must be clear about who is responsible for the outcome and what safeguards are needed.
Automation is not a competition to see how many human actions we can eliminate.
It is a way to make useful improvements to how work gets done.
Sometimes that means letting a machine take over a repetitive task. Sometimes it means giving a person better information. Sometimes it means deciding not to automate at all.
Why this matters to a student
You may be reading this as a student and thinking that automation is a subject for engineers or business owners.
It is not.
Look around your school or college. Think about your family's farm or shop, the local panchayat office or a nearby clinic.
There are records to maintain, things to count, appointments to remember, supplies to check and information to pass from one person to another.
Some of that work may be unnecessarily repetitive. Some may be done manually because nobody has had the time to look for a better way. Some may need to stay exactly as it is.
You do not need to arrive with a clever machine or an advanced program.
Start by noticing how the work is done. Ask the person doing it what takes the most time, what gets forgotten and what causes the most trouble.
Listen to the answer before proposing a solution.
That last part matters. A process that looks inefficient from the outside may exist for a good reason. The person doing the work often knows things that are not written in any procedure.
If you can understand the work, describe it clearly and identify where a practical improvement might help, you already have the beginning of a valuable skill.
The tools will change many times during your life.
The habit of observing carefully will remain useful.
Try this
Here is a small exercise. Give yourself about half an hour.
Choose someone you know who does a task repeatedly. It might be a parent, a teacher, a shopkeeper or a friend who runs a small business.
Ask them to describe one task they do every week.
Do not begin by asking how they would automate it. Ask them to show you how they do it now.
Write down the steps, in order, in plain words.
Then look at each step and ask:
- Does this step repeat in much the same way?
- What information does it need?
- What happens when something unusual occurs?
- How costly would a mistake be?
- Would a machine help, or would a simpler change be enough?
Mark the steps that seem suitable for automation. Circle the ones that need judgement or closer attention.
Choose just one possible improvement. Before building anything, think about how you would know whether it had actually helped.
Did it save time? Did it reduce mistakes? Did it make the work easier for the person doing it?
That is how you turn an idea into a useful experiment.
In my first essay, I asked you to bring a rough idea.
This is another one.
It does not need to be clever. It does not need to involve artificial intelligence. It only needs to begin with an honest understanding of how the work is done today.
Bring it. We can improve it one step at a time.