Implementing AI in a small business is a sequencing problem, not a technology problem: pick one repetitive, high-volume process that a person currently does by hand, measure how long it takes and how often it goes wrong today, then run a four-to-six week pilot on that single process with a named owner and a kill date. Buy before you build, keep the first project inside one department so you can undo it cheaply, and write down your data rules before anything touches customer information. If the pilot beats your baseline on time, error rate or cost, scale it to the next-most-similar process; if it does not, stop and take the next item on your list.
What follows is the detail an owner or operations lead needs to actually do that: how to choose the first process, what to measure, how to test a vendor’s accuracy claim on your own documents, what the Personal Data Protection Act requires of you, what the Singapore support ecosystem offers, and what a realistic first year looks like for a company with 15 to 500 staff.
Why most SME AI projects stall
The failure pattern is consistent and it is rarely about the model. Projects stall because the business started with a tool instead of a task, because nobody could say what “better” would look like in numbers, because the person who understood the process was never in the room, or because the pilot was scoped so broadly that it needed clean data from four systems that have never spoken to each other.
A second pattern: the pilot works, everyone is pleased, and then nothing happens. There is no owner, no budget line, no decision about who stops doing the manual version, and within two months the team has quietly reverted. Adoption is a management job, not a software job.
If you take one structural idea from this article, take this one: your first AI project is not an attempt to transform the company. It is an attempt to learn how your company runs an AI project. Choose accordingly — something small, visible, and owned by someone who will still be there in six months.
Step 1: Choose one process, not a technology
Start from the work, not from the vendor list. Walk the floor for a week and write down every task where a competent person is doing something repetitive with text, numbers, images or voice. Quotations retyped from emails. Delivery orders keyed into an accounting system. Customer enquiries answered with near-identical replies. Invoices matched against purchase orders. CVs screened. Site photographs checked against a compliance list. Meeting notes turned into follow-ups. Weekly reports assembled by copying figures between spreadsheets.
Then score each candidate. The scoring table below is deliberately crude; the point is to force a comparison rather than to produce a precise number.
| Criterion | 1 point | 2 points | 3 points |
|---|---|---|---|
| Volume | A few times a week | Daily | Many times a day |
| Rules clarity | Judgement-heavy, tacit | Mostly consistent | Written rules exist |
| Data availability | Paper or scattered | In one system, messy | In one system, tidy |
| Cost of a mistake | Safety, legal or regulatory | Customer annoyance | Internal rework only |
| Owner available | Nobody obvious | Someone part-time | Named owner with time |
| Measurable today | No baseline possible | Rough estimate | Timed and logged |
Add the scores. Anything below 12 is not your first project. Pay particular attention to the “cost of a mistake” row: for a first project you want that row to score high, meaning the downside of a wrong answer is internal rework, not a regulatory breach or an injured worker. Save the high-stakes processes for after you have learned how to supervise a model.
Good first candidates for most SMEs
- Document extraction: pulling fields from invoices, delivery orders, packing lists, bills of lading or insurance forms into a structured format a human then approves.
- Drafting: first-draft replies to routine enquiries, quotation cover notes, standard operating procedure updates, tender response boilerplate.
- Classification and routing: sorting an inbox, tagging support tickets, triaging job applications against stated criteria.
- Summarisation: turning long email threads, service reports or call transcripts into a short structured record.
- Search over your own documents: letting staff ask questions of your own contracts, manuals and price lists instead of hunting through shared drives.
Poor first candidates
- Anything that produces a legally binding output with no human in the loop.
- Demand forecasting when your sales history lives in three spreadsheets and one person’s head.
- Full customer-facing autonomous chat before you have tested the same content internally with your own staff as the users.
- Anything requiring integration with a system your vendor no longer supports.
- Anything where the decision affects someone’s employment, credit or care without a documented review step.
When the process lives in WhatsApp, on paper, or in one person’s head
This is the normal case in Singapore SMEs, not the exception. Three options, in order of preference. First, move the intake before you automate it: ask the eight customers who send orders by chat message to send them to a shared mailbox instead, which is a one-email change that makes every later step possible. Second, digitise the input only, with no AI at all, for a month — a simple form, a scanning routine, a naming convention — and then reassess. Third, if the knowledge sits with one long-serving person, spend two sessions writing down what they actually check and in what order. That document is more valuable than any tool, and you will need it to judge whether the tool is right.
Step 2: Baseline before you build
You cannot claim an improvement you cannot measure, and finance will not release budget for a feeling. Spend one week measuring the current state of your chosen process before you look at a single tool.
Baseline checklist:
- How many times does this task happen per week? Count, do not estimate.
- How many minutes does one instance take, measured with a stopwatch on at least ten instances?
- Who does it, at what fully loaded hourly cost, including CPF and overheads?
- What is the current error rate, and how do you detect errors today?
- What does an error cost to fix, in time and in customer goodwill?
- What is the turnaround time the customer or the next department experiences?
- What happens to this task when the person who does it is on leave?
- Where does the input data live, in what format, and who owns access to it?
- Which three fields or outputs matter most, so that you can check those specifically later?
Write the answers on one page and get the department head to sign it. That page is your control group. In twelve weeks you will run the same measurements again, and the comparison is your business case for everything that follows.
One caution on measuring time saved: minutes saved are only money saved if the freed capacity is redeployed to something that generates revenue or absorbs growth without new headcount. Decide in advance which it will be. “We saved nine hours a week” is not a result; “we absorbed the new account without hiring a second coordinator” is.
Step 3: Buy the cheapest thing that could possibly work
Most SME AI needs are met by software someone else has already built. Custom development is appropriate when the process is genuinely specific to your business and is a source of competitive advantage, and rarely before.
| Option | When it fits | Typical effort | Main risk |
|---|---|---|---|
| Feature inside software you already own | Your accounting, CRM or helpdesk vendor has shipped AI features | Days; often just enabling a setting | Feature is shallow; you still pay for the suite |
| Off-the-shelf SaaS point solution | A common process such as document extraction or call summarisation | Two to six weeks including data migration | Lock-in, per-seat pricing, data residency questions |
| Assistant plus your own documents | Internal Q&A over manuals, policies, price lists | Two to eight weeks | Answer quality depends entirely on document hygiene |
| Workflow automation with an AI step | You need to connect two systems and add judgement in the middle | Four to ten weeks | Brittle integrations; needs an internal owner |
| Custom build | Genuinely proprietary process, defensible advantage | Three months and upwards | Cost, maintenance burden, key-person dependency |
Questions to put to any vendor, in writing, before you sign:
- Where is our data stored and processed, and in which jurisdictions?
- Is our data used to train your models or anyone else’s? If so, can we opt out, and is the opt-out contractual rather than a toggle in a settings page?
- Which sub-processors do you use, and will you notify us when that list changes?
- What is your deletion process and how long does it take?
- What happens to our data and our configuration if we leave? Can we export it in a usable format?
- What accuracy do you claim, measured on what kind of documents, and can we test it on twenty of ours before committing?
- Who is liable if the system produces a wrong output that we act on?
- What is the price at ten users, at fifty users, and on renewal?
- Do you carry any recognised security certification, and can we see the current report?
Insist on a paid or free trial with your own documents. Vendor demonstrations use clean data. Your data has handwriting, coffee stains, three different invoice templates from the same supplier, and a scanner that crops the bottom line.
How to test an accuracy claim in half a day
A vendor’s stated accuracy figure is meaningless until it is measured on your inputs, and this is the step SMEs most often skip.
- Build a test set of twenty real items: fourteen typical, three awkward but legitimate (multi-page, rotated scan, handwritten amendment, unusual supplier template), and three that should be rejected outright (wrong document type, illegible, duplicate).
- Decide the three to five fields or judgements that matter. Extracting a supplier address wrongly is an annoyance; extracting a container number wrongly puts a lorry at the wrong dock.
- Have a person produce the correct answer for each item first, in a spreadsheet. This is your answer key and it takes about an hour.
- Run all twenty through each shortlisted tool untouched, with no hand-tuning by the vendor.
- Score per field, not per document: count correct, wrong, and “flagged as unsure”. A tool that says “I am not confident” on the hard three is more useful than one that guesses confidently.
- Set the pass threshold against your baseline, not against perfection. If humans currently get a field wrong occasionally and the review step catches errors, the tool needs to be good enough that reviewing is faster than typing.
Keep the test set. You will re-run it after every major product update and after any supplier changes a template, which is how you detect quality drift before a customer does.
Step 4: Governance and PDPA obligations, kept proportionate
Singapore organisations operate under the Personal Data Protection Act, administered by the Personal Data Protection Commission, which governs the collection, use and disclosure of personal data. Feeding customer records, CVs, employee information or identifiable service history into a third-party AI tool is a use and usually a disclosure, so the ordinary obligations apply: consent or another lawful basis, purpose limitation, notification, accuracy, protection, retention limits and accountability.
Four obligations catch SMEs adopting AI tools in particular, and all four are worth checking against the current text on the PDPC’s website rather than any summary, including this one:
- Accountability and the DPO. Every organisation must appoint at least one individual responsible for ensuring compliance and make that person’s business contact information available. In an SME this is usually the operations or finance lead, not an external consultant.
- Transfer limitation. If your AI vendor stores or processes personal data outside Singapore, you are responsible for ensuring it receives a comparable standard of protection, normally through contractual terms. Ask where processing happens before you upload anything.
- Data breach notification. Notifiable breaches must be assessed and, where the threshold is met, reported to the PDPC and affected individuals. A misconfigured AI tool that exposes a customer list is a breach like any other, so your incident process should cover the new tool from day one.
- Guidance specific to AI. The PDPC has issued advisory guidelines on the use of personal data in AI recommendation and decision systems, and IMDA and the AI Verify Foundation publish the Model AI Governance Framework, including a version for generative AI. Both are periodically updated; read the current versions.
For a company of 15 to 500 staff, proportionate governance is roughly one page plus one register. The page covers:
- Permitted tools. A named list of approved tools. Everything else requires sign-off. This single line prevents most shadow-AI problems.
- Data classes. What may never be pasted into a general-purpose tool: NRIC numbers, bank details, medical information, unreleased financials, customer lists, anything under a client NDA.
- Human review. Which outputs a person must check before they leave the building, and who that person is.
- Disclosure. When you tell a customer they are interacting with, or being assisted by, an AI system.
- Logging. Keeping a record of inputs and outputs for high-impact processes, so that when something goes wrong you can reconstruct what happened.
- Review date. A quarterly diary entry to revisit the list.
The register is a simple table listing each AI use in the business, its owner, the data it touches, whether personal data is involved, where that data is processed, and the date of last review. Appoint your data protection officer or an operations manager as the keeper of it. If you are in a regulated sector such as financial services or healthcare, check your sector regulator’s guidance as well; sectoral expectations sit on top of the general ones. If you use AI in hiring, remember that screening decisions remain subject to fair employment expectations and that you must be able to explain the basis of a rejection.
Two practical habits matter more than any policy document. First, turn off training on your data where the vendor offers that setting, and check it again after major product updates. Second, teach staff that a general-purpose chatbot is a third party, and the test for what goes in is the same test you would apply to an email to an external consultant.
Step 5: Run the pilot, with a kill date
A good SME pilot has five properties: one process, one department, a named owner with time protected in their week, a written success threshold agreed before the start, and a date on which you will decide to scale, fix or stop.
Write the threshold as a sentence anyone can check. “Average handling time per document falls by at least a third, with no increase in downstream errors, by week six” is a threshold. “Improve efficiency” is not.
A worked example: a 40-person logistics firm
Consider a 40-person freight forwarding and warehousing company in Jurong. Three operations coordinators spend a large part of each morning reading emailed shipping documents from customers and keying reference numbers, container numbers, weights, incoterms and delivery addresses into the transport management system. Errors are caught downstream, usually by a driver who arrives at the wrong dock or by a customer who queries an invoice.
Baseline week. The operations manager times sixty documents. She records the average handling time per document, the daily volume, the fully loaded cost of coordinator time, and the number of keying errors found downstream in the previous month by searching the credit-note log. She notes that documents arrive in four formats from twelve regular customers, that two customers still fax, and that the TMS has an import function nobody uses because the CSV template never matched.
Scoping. She narrows the pilot to the eight customers who send PDFs in a consistent layout, covering most of the volume. The two fax customers and the two irregular ones stay manual. This is the single most important decision in the pilot: she resisted the urge to solve the whole problem.
Tool choice. She trials two off-the-shelf document extraction products, giving each the same twenty real documents including three deliberately awkward ones, scored field by field against an answer key she prepared first. One handles multi-page documents poorly and is dropped. The survivor is configured to output the CSV format the TMS import already expects, so no integration work is needed in the pilot.
Human in the loop. Extracted fields appear in a review screen. The coordinator checks four critical fields against the source document, corrects anything wrong, and approves. Nothing reaches the TMS unreviewed. Corrections are logged so the team can see which field types fail most often.
Six weeks later. Average handling time per document has fallen materially against the signed baseline, the review step catches extraction errors before they reach operations, and the coordinators report that the tedious part of the morning is the part that changed. Two problems surface: one customer changed their template in week four and extraction quality collapsed until someone reconfigured it, and the approval screen created a bottleneck when the assigned coordinator was on leave.
Decision. The firm scales to four more customers, writes a one-page runbook covering template changes, names a second trained approver, and adds the monthly tool cost to the operations budget. The freed coordinator hours are redeployed to chasing delivery confirmations, which was previously done late and inconsistently. The fax customers stay manual, and the firm uses the pilot as a reason to ask them to change.
Notice what this example does not contain: a model, a data science team, or a transformation programme. It contains a measured process, a narrow scope, a review step and a decision date.
A second example: a 60-person specialist retailer
Not every SME has a document-heavy back office. Consider a 60-person retailer with four outlets and an online store, where two customer service staff answer the same questions all day: stock availability, warranty terms, spare part compatibility, delivery lead times. Enquiries arrive by email, by chat widget and by WhatsApp.
The owner’s instinct is a customer-facing chatbot. The better first project is the internal version of the same thing. The team assembles the material that already answers those questions — warranty policy, compatibility charts, delivery matrix, the top fifty replies from the shared inbox — and puts it behind a search-and-answer assistant used only by staff. The baseline is the average first-response time and the proportion of enquiries that need a second person to resolve. Human review is automatic, because a person sends every reply.
Three things come out of it. Response time on the messy middle tier of enquiries improves, because staff stop hunting through shared drives. The exercise exposes that the compatibility chart has been wrong since a supplier changed part numbers, which was causing returns. And the team now has tested, accurate content, which is the only sound basis for eventually exposing anything to customers. The customer-facing version becomes project two, scoped to the enquiry types that were answered correctly every time internally, with a clear handover to a human and a line telling the customer they are talking to an assistant.
Step 6: Decide honestly at the kill date
At the end of the pilot, re-run the baseline measurements and put the two columns side by side. Then make one of three calls.
- Scale. The threshold was met and the process owner wants to keep it. Move to the next-most-similar process, reuse the same tool and the same review pattern, and add the cost to a permanent budget line.
- Fix. The threshold was missed but the cause is identifiable and cheap to address: one data source is dirty, the review step is in the wrong place, two staff were never trained. Extend by four weeks with one named fix and the same threshold.
- Stop. The threshold was missed and the cause is structural. Write half a page on why, circulate it, and move to the next candidate. A clean stop costs six weeks; a pilot kept alive to protect somebody’s reputation costs a year.
The discipline of publishing the result, including the failures, is what makes the second and third projects faster than the first.
Step 7: Skills and adoption
Tools do not change work; people do. Budget as much attention for adoption as for procurement.
- Name a process owner, not a project manager. The person who owns the business outcome should own the tool.
- Train on your own work. Generic prompt-writing courses fade within a fortnight. A two-hour session using last week’s real documents and real customer emails sticks.
- Write the new SOP. If the AI step is not in the standard operating procedure, it is optional, and optional steps are skipped under pressure.
- Make the manual route slower, not forbidden. People revert under deadline. Keep the fallback available but ensure the new path is genuinely the easier one.
- Create a visible feedback route. A shared channel where staff post bad outputs. Review it weekly. Fix the top complaint. Say publicly that you fixed it.
- Train two people, never one. Single-approver processes break at the first medical certificate.
- Talk about job content early. Staff will ask whether this replaces them. Answer honestly and specifically: what stops, what starts, what happens to the freed hours. Silence produces the worst possible answer.
Working with your existing IT vendor
Most SMEs already have an IT support company handling laptops, email and the network. They are rarely the right party to select an AI workflow, but they must be involved in three decisions: identity and access (who can log in, and whether it uses your existing single sign-on), device policy (whether staff can install browser extensions that read your screen), and offboarding (removing access when someone leaves). Put those three items in writing with them before the pilot starts, not after.
Where the national programmes fit
IMDA runs SMEs Go Digital, with Industry Digital Plans and pre-approved solutions by sector, and CTO-as-a-Service for businesses without in-house technology leadership. On funding, Enterprise Singapore administers the Productivity Solutions Grant for pre-approved solutions and the Enterprise Development Grant for larger projects, while SkillsFuture Singapore administers the SkillsFuture Enterprise Credit towards employer-borne training and transformation costs. Workforce Singapore runs career conversion programmes that can support reskilling existing staff into technology-adjacent roles.
Eligibility criteria, support levels and application windows change, and several of these schemes have been revised in recent years, so check the current terms on the administering agency’s own website before you build any of them into a budget. Two practical rules: build the business case so it stands up without the grant, and check whether your chosen tool is already on a pre-approved list before you shortlist alternatives, because that often decides which of two similar products is cheaper after support.
Step 8: A realistic first-year sequence
| Period | Focus | Output |
|---|---|---|
| Months 1–2 | Process inventory, scoring, baseline measurement, one-page AI use policy and register | Ranked shortlist, signed baseline, approved tool list |
| Months 3–4 | Pilot one: narrow scope, human review, kill date | Scale, fix or stop decision with measured numbers |
| Months 5–6 | Scale pilot one to adjacent cases; write runbook; train a second approver | Documented, owned, budgeted process |
| Months 7–9 | Pilot two in a different department, reusing tooling and review patterns | Second measured result; internal confidence |
| Months 10–12 | Data tidy-up exposed by the first two projects; quarterly governance review; plan year two | Cleaner core data; refreshed register; year-two shortlist |
The year-one goal is two measured wins and one working governance habit, not a portfolio of experiments.
Costs to plan for beyond the licence fee
Subscription pricing is the visible cost and usually not the largest one. Budget the internal effort explicitly, in days, and assign each line to a person.
| Cost line | Typical effort for a first pilot | Who carries it |
|---|---|---|
| Process inventory and scoring | One to two days | Owner or operations lead |
| Baseline measurement | Half a day spread over one week | Supervisor of the process |
| Vendor shortlisting and accuracy testing | Two to three days | Process owner |
| Data clean-up and template standardisation | Two to ten days, highly variable | Whoever owns the source system |
| Integration or export-import handling | Zero if you match an existing import format; several days if not | IT partner |
| Training and SOP rewriting | One day, plus two hours per user | Process owner |
| Ongoing supervision and quality review | One to two hours a week, indefinitely | Named approver |
| Reconfiguration when a format or product changes | Unpredictable; assume it happens quarterly | Process owner |
Add a line for the decision itself: senior time spent choosing badly is the most expensive item on the list. And assume the ongoing supervision cost never goes to zero — it shrinks, but a process with no one watching it is how quality drift becomes a customer complaint.
Common failure modes and the fix
| Failure | Symptom | Fix |
|---|---|---|
| Tool-first thinking | “We should do something with AI” | Return to the process inventory and score candidates |
| No baseline | Debate about whether it helped | Measure before, not after |
| Scope creep | Pilot needs three systems integrated | Cut to one customer segment or one document type |
| No owner | Nobody chases the vendor | Name a process owner with protected hours |
| Shadow usage | Staff pasting client data into personal accounts | Approved tool list plus a frank conversation |
| Zombie pilot | Running for nine months, no decision | Kill date in the original scope |
| Unredeployed savings | Hours saved, costs unchanged | Decide in advance where freed capacity goes |
| Silent drift | Quality falls after a supplier changes format | Monthly spot-check using your original test set |
| Single-approver risk | Process halts when one person is on leave | Train a second approver before scaling |
| Unchecked offshore processing | Nobody can say where the data sits | Ask the vendor in writing; record it in the register |
What to do in the next two weeks
- Block two hours to walk one department and list every repetitive text, number or image task. Owner: you.
- Score the top six candidates with the table above. Thirty minutes.
- Pick one and time ten instances with a stopwatch. Spread across one week.
- Write the one-page baseline and get the department head to sign it. One hour.
- Draft the approved-tool list and the never-paste data classes; circulate to all staff. One hour.
- Confirm who your data protection officer is and that their contact details are published. Fifteen minutes.
- Read the current PDPC advisory guidelines on personal data in AI systems and the Model AI Governance Framework for Generative AI. Two hours.
- Build a twenty-item test set with an answer key. One hour.
- Shortlist two vendors and ask each for a trial on those twenty items. Half a day.
- Put a kill date in the calendar before you start. Two minutes, and the most important item on the list.
Done properly, the first project is small enough to be unimpressive and disciplined enough to be repeatable. The second takes half the time, because the governance page, the test-set habit and the review pattern already exist and get reused.
Related articles
- How Singapore SMEs should adopt AI without breaking operations
- Selecting AI tools for Singapore SMEs: a practical framework
- Why most enterprise AI projects fail in the first 90 days
- How to upskill teams while implementing AI
Want help applying this? See how Fetch helps teams put AI to work.