Real Case Study: From Customized AI Tool Design to User Adoption in an SME
- Aug 13
- 5 min read
Most companies don't fail at AI adoption because the technology doesn't work. They fail because nobody with authority made adoption non-optional.
Lynqra builds AI automation systems for Singapore SMEs (Small and Medium Enterprises). We help automate unglamorous manual work, like: accounts payable, work orders, compliance tracking, the spreadsheets that nobody wants to own. After a year of client project deliveries, one pattern showed up clearly: whether an AI system delivers its value depends almost entirely on the user's willingness to exploit the tool, and less on how good the tool is.
This article shares one project we worked on: an AP/AR (Accounts Payable/ Accounts Receivable) automation build for our client, Vision Green Pte Ltd, from the discovery stage to post-implementation review.
Lynqra is OnlyVenture's technology-enabling partner. OnlyVenture works with founders and management teams on organisational and leadership transformations. Lynqra builds the tools that change gets applied to. Business Design consulting to digital turn-key operation workflow implementation is the combined unrivalled value we provide to our clients.
Why "AI Readiness" Is Usually Assessed Wrongly
When SMEs ask themselves whether they're "ready for AI," they usually mean: do we have clean data, a decent tech stack and budget? Those matter, but they're the easier factors to address. The hard one is behavioural. It's whether the staff doing the manual work today will actually stop doing the old way when a smarter system can replace the workload.
That comes down to ownership, not an organisational chart designation. The critical factor isn't whether a founder or a manager is driving the rollout. It's whether whoever is driving it has the authority and will to genuinely retire the manual process rather than a fallback people quietly keep using. In a small startup, that person is usually the founder. In a larger or more departmentalised organisation, it can just as easily be an operations lead or department head, provided the rest of the leadership team visibly backs the call.
What breaks adoption isn't the organisational design. It's ambiguity. If staff sense that the old way still has implicit permission, especially under deadline pressure, they tend to revert to the familiar. Whoever owns the rollout needs the authority, or the visible backing, to close that gap. Businesses that get it right tend to align their rollout plan correctly to the organisational authority that person has. Someone with less formal authority needs more structure to compensate: clearer SOPs, more training, a longer parallel-run period before the manual process is switched off. Misjudging that, at the discovery stage, is the single biggest reason automation projects stall after a promising start.
The Case Study
Vision Green Pte Ltd is a Singapore-based company whose finance operations, accounts payable and accounts receivable, ran largely on manual document handling. Staff pulled data off invoices and delivery documents by hand, cross-checked it, and re-entered figures into tracking sheets. It's the kind of workload that scales poorly with headcount and becomes more error-prone when workload increases.
The infographic below shows the AI tool design process flow:
Discovery
The first weeks weren't about the AI model. They were about mapping how AP/AR actually moved through the business day-to-day. Which documents came in, in what formats, who touched them, where the manual tagging and cross-referencing happened, and where errors typically crept in.
One issue surfaced early that shaped the whole build. The underlying data model had a many-to-many relationship between source documents and item-level records that the initial workflow design hadn't accounted for. Resolving that structural mismatch before writing any automation logic on top of it was a discovery-phase decision, not something patched in later. It's cheap to fix on a whiteboard but costly to fix once the workflows go 'live'.
Discovery also meant identifying who in Vision Green would own the system on a day-to-day basis, since that ownership question shapes how the whole rollout gets structured later.
Design and Implementation
Rather than getting into the specific tools, it's more useful to describe the flow, since that's what actually determines whether a business benefits from it.
The core automation loop works by scanning incoming AP/AR documents. The relevant fields are extracted and read. The system tags and cross-references those fields to the actual records, and the results land in a live, continuously updated dataset. Staff check status through a simple dashboard instead of digging through spreadsheets, and can query records conversationally instead of searching for them manually.
The build itself was iterative, by necessity. Each version of the automation logic was tested and refined against actual documents, not test data, because inconsistencies in formatting only show up once you're working with the actual paperwork a business generates. The target from the onset: eliminate roughly 70 to 80% of the manual document-handling workload, not 100%. Exception handling and edge cases still benefit from a human check. The AI tool is enough to fundamentally change what the AP/AR function spends its time on.
Post-Implementation: Demo and Evaluation
An MVP (Minimal Viable Product) was delivered and demoed directly to the team, not just the initial champions but the people who'd actually be using the system daily. The demo is where the ownership question gets tested in practice: Does leadership, whoever holds that role, treat the new dashboard as the new default, or does it become a parallel system staff can quietly avoid?
Here's the honest part, the part most case studies leave out. Automation projects like this aren't "done" at MVP level. The 70% to 80% success rate is measured against the resolved data model and actual documents. It's not a number one get to claim with a straight face until the system has run through a full operating cycle with the team using it unprompted. That's exactly why post-implementation review matters as much as the build itself: usage patterns, exception rates, whether staff quietly revert to the old spreadsheet the moment nobody's watching. That's where you find out whether the rollout is a success.
What This Means If You're Evaluating AI for Your Own Business
Before you evaluate vendors or tools, evaluate yourself and your leadership team honestly.
Who will stop doing the old process, and does the person have the will to make the new process stick? If the answer is unclear, plan for a longer, more structured adoption period.
Where does your data actually break? Not where you assume it breaks. Assess the real documents and edge case scenarios before any automation logic is scripted, so any data-model issue can be addressed early.
What's your realistic automation target? Full elimination of manual work is rarely the honest target. 70% to 80% reduction of manual work is a defensible and achievable bar for most document-heavy SME workflows.
Does your post-implementation review actually happen? Most SMEs treat going 'live' as the finish line. The ones that get real value treat going 'live' as the start of the measurement period.
AI readiness, in the end, isn't a checklist. It's a leadership decision, made visible in how the organisation actually operates in the weeks after the initial implementation, long after the excitement of the initial build has worn off.
Written by Mark Tan Li Jie, founder of Lynqra. Connect on LinkedIn.
