A ten-person team doesn't need an automation programme. It needs one less place for work to disappear.
New requests often arrive through a mixture of email, forms, messages and phone calls. Someone reads each one, works out what it means, decides who should handle it, then copies the details into another system. The work starts with a small delay and a fair amount of guesswork.
A sensible first automation is the front door to that work. It collects new requests, records the important details, routes each one to the right person and asks for a human check when the rule isn't clear.
#1. Start where every job enters the team
Look for the first hand-off, not the most expensive task. In a ten-person business, that might be a new service request, a supplier query, a booking enquiry or an internal job raised by a colleague.
The exact subject matters less than the shape of the work. Each request arrives with some information. Someone decides what it is. Someone takes ownership. The request then moves into a system, a queue or a person's list.
This is a good starting point because the boundary is easy to describe. The automation doesn't need to run the whole job. It only needs to help the team answer four questions:
- What has arrived?
- What does it relate to?
- Who owns the next step?
- What is still missing?
That keeps the first piece of work contained. It also gives the team a clear way to spot mistakes before they spread into delivery, billing or customer communication.
The first automation should make the next owner obvious.
#2. Define the route before choosing the tool
Small teams often begin with a software question. They ask which AI product can read the messages, or which connector can update the CRM. Start with the route instead.
Write down the paths a request can take today. Keep them short. For example:
- A request arrives in the shared inbox.
- The key details are captured in one record.
- The request is matched to a service or job type.
- An owner is assigned.
- A person checks anything incomplete or unclear.
Then list the exceptions. A request might mention two services. It might arrive without a date. It might come from someone who already has an open job. Those cases shouldn't be forced through the normal route. They should go to a named person with the reason made visible.
This is where many first attempts go wrong. The team automates the happy path and leaves the awkward cases to an unnamed queue. The result is a new place to check, not a shorter route through the work.
#3. Keep the first version narrow
The first version should handle one kind of request from one starting point. If the team receives work through five channels, choose one channel first. A shared inbox is often easier to observe than a collection of private messages, because the starting material is in one place.
Capture only the fields the next person needs. That could include the sender, request type, customer or supplier, deadline, location and a short summary. Don't create a large form because the system can store more information. Extra fields create more missing answers and more checking.
The automation can then apply a small set of rules:
- Send service requests to the service queue.
- Send finance queries to the finance owner.
- Mark a request for review when the type is unclear.
- Ask for missing information before assigning work.
- Keep the original message with the new record.
The last rule matters. A summary is useful only when a person can return to the source. The team should be able to see what the automation read, what it decided and what it changed.
#4. Put the person at the point of uncertainty
An automation doesn't need to make every decision. It needs to know when it shouldn't make one.
Set a clear review route for uncertain cases. The reviewer should see the original request, the extracted details, the suggested route and the reason for the flag. They shouldn't have to search through several systems to reconstruct what happened.
The review step also gives the team something to learn from. If the same type of request is flagged repeatedly, the rule may need changing. If a field is almost always missing, the intake form may need a better prompt. If two owners keep receiving the same work, the routing boundary isn't clear enough.
This is more than a safety check. It stops the team from treating an uncertain guess as a finished action. A person remains responsible for the cases where context matters.
#What to measure after it starts
Don't begin with a promised percentage. Watch the shape of the work instead.
For the first few weeks, record:
- How many requests arrive through the chosen channel.
- How many contain the details needed for the next step.
- How often the suggested route needs changing.
- How long requests wait before someone owns them.
- Which exceptions keep returning.
These observations tell you whether the first route is worth extending. They also show where the team still has to make a decision. That may be the next place to improve, or it may be a boundary that should stay with a person.
The aim isn't to remove every task around intake. It's to stop people reading the same request twice, copying it into several places and asking who is dealing with it.
Start with one channel, one request type and one owner for the review queue. Run it on real work. Keep the original information attached. Then change the rules only when the team can point to a repeated case that needs a better route.
Recognise any of this in your own business? Tell us about it and we’ll say whether it’s worth automating.
Talk through your process
