This page is for businesses that have decided AI is probably worth using but have not worked out where it fits. It covers what changed to make these projects affordable, what implementations look like in each part of a business, and how to choose a first project that gives you something useful to learn from.
Why the timing is different now
The main change is cost. Automating something like document review or lead triage used to require a development project with a budget, a specification, and a few months of work. For a lot of common tasks it is now a matter of configuring tools that already exist, which brings the effort down to a scale a small business can absorb.
This matters more for small companies than large ones, for a slightly indirect reason. A fifteen person business has no analytics function, no operations analyst, and nobody whose job is to notice that invoices are going out four days late. Work like that either gets absorbed by someone who is already busy or it does not happen. Larger companies solve this with headcount. Automation is one of the few ways a smaller company can cover the same ground.
The competitive effect is usually gradual rather than dramatic. Businesses that get this working tend to get quotes out the same day, follow up consistently, and close their books early in the month rather than halfway through it. Individually none of that is significant. Accumulated over a year it affects which company wins work.
It is worth being clear about the failure rate. A large proportion of AI pilots never make it into regular use. The usual reasons are that the underlying process was never properly defined, or that the data it depended on was inconsistent. Automating a process that does not work well tends to produce the same poor result faster and at greater volume. The businesses that get value out of this are generally not the ones that moved earliest. They are the ones that sorted out the process first.
What successful implementations have in common
Looking at small businesses that got past the pilot stage, a few things come up repeatedly.
The first projects tend to be in areas where the work is repetitive and a mistake is cheap to correct. Drafting, classifying, summarising, and routing all fit that description. Pricing decisions and anything that reaches a customer unreviewed generally do not.
Most keep a person reviewing the output at the start, and only remove that step once they know how often the system gets things wrong. This is slower than deploying directly, but it is usually what determines whether staff end up trusting the system or quietly going back to the old method.
They also tend to record one number before starting. Hours spent on the task, average response time, error rate, days to close the accounts. Without a figure from before the change there is no way to demonstrate whether the project worked, and projects without evidence behind them get dropped as soon as anyone questions the spend.
Finally, they deal with their data before their tooling. A lot of implementations that go wrong turn out to have a records problem underneath, where the same customer or the same order exists in three systems with different details. Spending a couple of days cleaning up a customer list is often more valuable than anything built on top of it.
What this looks like by department
The examples below are intended to show the shape of a typical first implementation rather than to be worked through in order. Most businesses should pick whichever one matches their worst current bottleneck.
Sales: lead classification and outreach
Enquiries usually arrive through more than one channel, such as a web form, a shared inbox, and occasionally the phone. Someone reads them when they get a chance, which means a good lead can sit for two days, and a poor one takes up the same amount of attention as a promising one.
A system for this parses incoming enquiries and scores them against criteria you set, typically some combination of company size, stated budget, urgency, and how well the request matches what you sell. Higher scoring enquiries trigger a notification and a drafted first response. Lower scoring ones receive an acknowledgement and a link to relevant information. Each classification is logged with its reasoning, so you can check why something was scored the way it was.
The result you are aiming for is a response time to qualified enquiries measured in an hour or two rather than days, with sales time concentrated on the enquiries worth spending it on.
The common problem is that scoring criteria reflect what you assume a good lead looks like rather than what your closed deals actually show. Reviewing the first hundred or so classifications manually is worth the time.
Operations: consolidated reporting
Most small businesses have their performance data spread across several systems. Assembling a picture of how the last month went takes someone the best part of a day, which means it gets done infrequently and late.
An implementation here pulls data from your sales, delivery, and finance systems on a schedule and produces a regular summary written in ordinary language. Alongside that, it flags anything that has moved unexpectedly, such as an average delivery time that has doubled or a regular customer whose order volume has dropped.
What you want out of this is finding out about problems in the week they occur rather than the quarter they occur.
The usual mistake is building a dashboard first. Dashboards are more work and tend to go unopened after the first fortnight. A written summary sent to one person is a better starting point, and you can expand it if they find it useful.
Finance: invoicing and payment chasing
Invoices go out inconsistently because raising them depends on someone remembering. Chasing late payment is uncomfortable, so it gets postponed. The result is a cash flow problem that has nothing to do with how well the business is selling.
A system for this generates invoices from completed work without relying on someone to initiate it, then runs a reminder sequence at intervals you set, escalating in tone on a defined schedule. You keep an exception list for the customers you would rather handle personally. Incoming payments are matched against invoices automatically, with anything that does not reconcile flagged for someone to look at.
The measurable outcome is a reduction in the time between invoicing and payment. The less measurable one is that the uncomfortable part of the process stops depending on anyone being willing to do it.
Tone is the thing to be careful about. An automated chasing sequence that reads as aggressive can cost you a customer relationship worth considerably more than the invoice. Write the sequence yourself and read it as though you were receiving it.
Customer support: triage and drafted replies
Support inboxes usually contain the same twenty or so questions repeating, with a small number of genuinely unusual cases mixed in.
An implementation categorises incoming messages and routes them. Routine questions receive a drafted answer assembled from your own documentation, which a person reviews and sends. Unusual cases are escalated straight away rather than waiting in the same queue as everything else.
You should end up with faster responses on routine questions and more attention available for the cases that need judgement.
The mistake to avoid is putting a customer-facing bot in place as the first step. Drafting for human review is the sensible starting point, and full automation of responses is a later decision, if you make it at all.
Marketing: research and drafting
Content production is usually the first thing dropped when the business gets busy, so it tends to happen in bursts and then stop for months.
What this looks like in practice is drafting from briefs and source material that you provide rather than generating from nothing, compiling and summarising research, and adapting a single piece of work across different formats without that being a separate job each time.
The aim is consistent output from the same amount of staff time, with that time going into direction and editing rather than first drafts.
Publishing unedited output is the failure mode here. It is fairly easy to recognise, and it undermines the credibility the content was meant to build.
Administration: document processing
Contracts, applications, expense claims, and compliance paperwork all involve someone reading a document in order to extract a small number of fields from it.
A system extracts structured information from these documents and writes it into wherever it needs to go, produces summaries of anything that requires review, and flags documents that are missing information or contain inconsistencies.
This typically returns a few hours a week and reduces the errors that come from manual copying.
Anything with legal consequence needs care. Extraction is a first pass that speeds up review rather than a replacement for it.
Choosing what to do first
Three questions are worth answering honestly before committing to anything.
Where does work actually build up? This is usually not the most interesting problem in the business. It is the one that generates the most internal complaints.
Is the process defined? If nobody can write down the steps a person currently follows, automating it will not go well. Writing it down is the first task, and occasionally it turns out to be the only one needed.
Can you measure it as things stand? If you cannot state the current figure, spend a week establishing it before changing anything.
A sensible first project runs for somewhere between two and six weeks, affects a single process, and has a number attached to it. A proposal that spans several departments and runs for six months is not a first project.
If you want a second opinion on which one to pick
Send us a short description of your situation and we will reply with which process we would look at first and why. It helps to include what the business does, which process is currently causing the most difficulty, and roughly how many people are involved in it.
There is no charge for this and we do not add you to a mailing list. Most replies go out within two working days.
Or copy the address yourself: info@isdifoundation.com
What to budget for
There are three costs, and the tooling is usually the smallest of them. The configuration and integration work is the middle one. The largest, and the one most often left out of estimates, is internal time: defining the process, cleaning up the data, and getting people to actually use the result.
It is reasonable to expect the first attempt to be partly wrong. The main value of a small first project is not the hours it saves but what it tells you about where your own data and processes are weaker than you assumed.
Problems that come up repeatedly
Choosing a tool before identifying the bottleneck. The useful question is which process is costing you, not which platform to buy.
Not recording a baseline, which leaves you unable to say afterwards whether anything improved.
Automating a process that was not working properly to begin with.
Nobody owning the implementation after it goes live. Systems that are everyone's responsibility tend to stop being maintained within a few months.
Taking on too much at once. One process implemented properly will teach you more than five that are half finished.
Getting in touch
There are two things we can help with at this stage.
The first is working out where to start. If you describe your situation we will tell you which process we would tackle first and what we would want to know before committing to it. This is free and it is the more useful of the two for most people reading this page.
The second is implementation. If you already know what you want to build, we can point you toward organisations working in this area. Tell us what you are trying to do and where you are based, and we will send you the options we are aware of.
Or copy the address yourself: info@isdifoundation.com
What happens next: someone reads it and replies, usually within two working days. We do not add you to a mailing list and we do not pass your details to anyone without asking you first.