Start with a frustrating task, not a fashionable tool
For a small business in Singapore, the most useful AI opportunity is often hiding in an ordinary working day. It might be the same delivery question arriving ten times, an enquiry that gets lost between two inboxes, or a report that someone rebuilds every Friday. Start by observing the work. A clear problem is more valuable than a long list of impressive product features.
Ask the person doing the task to walk you through a recent example. Record what arrives, which information they need, what they produce and where they pause to make a judgement. Do not assume every step needs AI. A shared template, a better form or a simple reminder can sometimes solve the problem more cheaply and reliably.
Build a baseline you can actually compare
Before changing anything, measure a normal week. Count the requests, estimate handling time and note common mistakes. Include the time spent checking work and fixing exceptions, not just the time spent typing. If a task takes five minutes but creates another fifteen minutes of follow-up, your baseline should reflect the whole process.
Choose one primary outcome that matters to the business. For an enquiry workflow, that might be fewer requests left unanswered at closing time. For reporting, it could be a consistent report ready before the weekly meeting. Keep your notes simple enough that the team can maintain them without turning measurement into another administrative burden.
Pick a narrow and reversible pilot
A good first pilot has one owner, one workflow and a defined set of inputs. A retailer could trial draft replies for product availability questions without letting the assistant make promises about refunds or delivery dates. A service business could organise incoming enquiries without allowing the system to quote prices or confirm appointments.
Agree what the pilot will not do. Use approved business information, remove personal details when they are unnecessary and keep a manual fallback. Choose a review period that includes ordinary work and a few realistic exceptions. It should be possible to stop the pilot without losing enquiries, documents or the ability to serve customers.
Make human review part of the design
Someone needs to be accountable for the result, even when the system produces a convincing answer. Decide which outputs require approval, which can be used directly and which must be escalated. Financial decisions, customer commitments and sensitive information deserve particular care. The owner should understand the workflow well enough to recognise an answer that sounds plausible but is wrong.
Create a small review checklist. Does the draft answer the actual question? Is the supporting information current? Has the system added a promise that the business never approved? Review a sample of routine outputs as well as flagged exceptions. A system can make the same small mistake repeatedly without triggering an obvious warning.
Use three questions to shortlist the first task
Write down three recurring tasks and ask the same questions about each. Does it happen often enough for an improvement to matter? Can the team recognise a correct result without a lengthy investigation? Can a mistake be caught before it reaches a customer or changes a business record? A task that scores well on all three is usually a better starting point than an occasional, high-stakes decision.
Consider a fictional neighbourhood homeware shop. Staff repeatedly answer product-care questions, negotiate unusual refunds and reconcile supplier payments. Product-care drafts have a clear source and can be reviewed before sending. Unusual refunds require judgement, while supplier reconciliation depends on accurate records and controls. The shop chooses product-care replies as its first experiment and leaves the other tasks with the existing process.
Frequency alone is not enough. If the approved care instructions are incomplete, the shop should repair them before introducing an assistant. The shortlist is also a way to uncover process problems. Sometimes the most valuable result of the exercise is discovering that staff need a shared reference page rather than a new tool.
Put the pilot on one page
A useful pilot brief names the problem, the owner, the allowed inputs, the expected output and the review step. For the homeware shop, the input is a product-care question and a current care sheet. The output is a short draft for a staff member to approve. The assistant has no permission to send messages, process returns or modify stock records. These details turn an abstract AI ambition into a workflow that someone can explain and operate.
Add a practical success condition and a stop condition. For example, the shop might aim to reduce total handling time while keeping the same accuracy standard. Any unsupported care instruction is a reason to pause the affected product and review its source material. These are proposed pilot rules, not universal targets. Choose thresholds that fit the consequences of a mistake and the volume your team can realistically review.
Describe the fallback in the same brief: where unanswered questions go, who can disable the assistant and how staff return to the approved reference page. Give a second colleague enough information to run the process. A pilot should not depend on its creator being available every time a connection fails or an unfamiliar question arrives.
Try a two-week schedule that leaves room to learn
As an illustrative schedule, use the first few days to observe the existing process and select representative examples. Spend the next few days preparing approved information and trying drafts without sending them. Include a vague question, an outdated product reference and a request outside the agreed scope. Look for specific failure patterns rather than judging the assistant from one impressive answer.
In the second week, let one or two staff members use the workflow on a limited set of real requests, with approval before every reply. Keep a brief record of handling time, corrections and escalations. At the end, review both the numbers and the staff experience. If the sample is too small or unusually quiet, extend observation instead of treating the calendar deadline as proof that you have learned enough.
Finish with one decision: continue at the same scope, improve a named weakness, expand cautiously or stop. Attach that decision to the evidence. This gives the next experiment a useful starting point and prevents the business from collecting subscriptions without a clear account of what each one improves.
Decide whether to improve, expand or stop
At the end of the pilot, compare the new process with the baseline. Add subscription fees, usage charges, implementation effort and the time spent reviewing outputs. Ask the team whether the workflow genuinely feels easier. A faster first draft is not a useful improvement if checking it takes longer than doing the original task.
If the evidence is positive, document the process before expanding it. Keep the approved information, access permissions and fallback instructions in a place the team can find. If the pilot is disappointing, record what you learned and consider a simpler approach. Choosing not to automate an unsuitable task is a sound business decision, not a failed AI strategy.
