Case study
How AI Turns Work Requests Sitting in an Inbox into Jobs on the Board.
M Squared · Landscape & groundworks
For a contractor working across a lot of sites, most incoming work arrives as email. A client asks for a repair. A framework customer sends an order for extra works. Something needs recharging back. Each one is a job that has to reach the people who will do it, with the right detail, on the right site, against the right budget.
What normally happens is that somebody in the office reads every one, works out what it is, and copies it into whatever system the business runs on. It is a full-time job in all but name, and it is fragile: when that person is off, the work still arrives and nothing moves.
Purchase orders make it worse. The client's order sits in one system and the record of the work sits in another, and reconciling them is a monthly exercise that nobody enjoys and everybody postpones. The gap between the two is where invoices get missed and where work gets done that was never covered by an order.
We built M Squared a set of automations that take the work out of the mailbox and put it where the business actually operates, without anyone retyping it.
Incoming work emails are read as they arrive. AI works out what each one is asking for, pulls the detail out, including anything sitting in an attachment rather than the message, and creates the job with that detail attached. Ad-hoc works and recharge works are separated, because they are billed differently and confusing them costs money.
Alongside it, purchase orders are reconciled on a schedule rather than at month end. The system compares what has been ordered against what has been recorded, and reports the difference to the team. A mismatch surfaces while it is still a question, rather than becoming a write-off.
Route planning is connected too, so what is scheduled in the field and what the office sees stay the same thing.
It understands what is being asked. Work requests do not arrive in a standard format. They arrive as somebody typing what they need, sometimes in the message, sometimes in a document attached to it. The system reads both, so a job described in an attachment is not missed.
It knows what is not work. A mailbox is full of replies, acknowledgements, out of office notices and threads the business is only copied into. Everything is filtered before anything is created, because an intake system that creates a job from a thank-you email gets switched off in a fortnight.
It handles volume without falling over. Emails are worked through in batches rather than all at once. That is what keeps it steady when a client sends forty orders on a Monday morning.
It tells the team what it did. Purchase order checks report into the channel the team already uses, so the reconciliation is something people see rather than something they have to remember to run.
It fails loudly. When something breaks, an alert is raised rather than the inbox quietly filling up. That is the difference between automation you can rely on and automation you have to check.
Copying an email into a system takes two minutes. That is not where the money goes.
The money goes elsewhere. On the request that sat unread for three days while a client waited. On the recharge nobody spotted was rechargeable. On work carried out against an order that did not cover it. Every one of those is invisible on the day and obvious at the end of the month.
Taking intake off a person does not just save their time. It means the work starts the day it arrives, and the record of it is the same record the client is working from.
See the operating system this feeds into →, or the recruitment pipeline built the same way.
The part people picture, AI reading an email and understanding it, is a small share of what makes this work in a real business.
The rest is judgement about the mailbox. Which senders matter and which are noise. What to do with a thread that has been going for a fortnight. How to tell an order from a query about an order. Whether an attachment is the job or a signature image. Getting those wrong does not produce an error, it produces a board full of rubbish, and a board full of rubbish is abandoned within a month.
Then there is volume. A client who sends four emails a day for three weeks, then forty on a Monday, breaks anything built for the average. So it works in batches and keeps its place if something fails halfway.
None of that is visible when it is working properly. That is rather the point.
Tell us where your team loses the most time. We will tell you honestly whether AI pays there, what it takes to build, and what we have already delivered for businesses like yours.
We use cookies to measure how the site is used and, if you allow it, for advertising. Nothing is set until you choose. Privacy policy.