Scalable Bookkeeping Flow

Context & Challenge

Osome is a software platform that handles company admin for entrepreneurs—bookkeeping, accounting, tax, compliance across the Singapore, Hong Kong, UK and UAE markets.

When I joined, the automation looked solid on paper. Underneath, the operations team ran the entire bookkeeping workflow through Slack threads, Excel masterfiles and one-off Google Sheets.

We were promising entrepreneurs peace of mind while running their bookkeeping on Slack threads, Excel files and a bit of hope.

Metrics

Before this project, bookkeeping operations were essentially unmeasured — so measurement came first. Metrics were defined together with the PM and C-level; my contribution was proposing what to instrument and co-building the analytics infrastructure: a Looker dashboard, built with an analyst, that the team still uses today. The first weeks of data gave us our baselines. I also tracked behaviour through Amplitude and Microsoft Clarity.

North star: contact rate. Once instrumented, it read 82% — the majority of client requests were handled in chat.

I started with research

I went to our Kuala Lumpur office and sat next to the agents. What I expected: some manual steps, the usual gap between process docs and reality. What I found: the entire bookkeeping workflow running through Slack messages and Excel files — every client question, clarification and document request in chat, with no record in our system, no standardisation across markets, no way to measure any of it. Product and operations had drifted so far apart that when I asked to see their spreadsheets, agents looked genuinely surprised.

I shadowed agents, reverse-engineered the document pipeline with engineering, and dug through support tickets to see the client side. The research reshaped how the company thought about bookkeeping as a function.

Then mapped the whole flow

Research gave me and the team a clear picture of where the real work happened and allowed me to map the full bookkeeping flow. The first design challenge was mapping the entire bookkeeping process from document intake to general ledger, identifying every step that was running manually in chat or Excel, and turning each one into a structured, trackable unit of work.

Each step in the new flow got tickets, states and ownership. For the first time, we could see how many open items existed per client, who owned them, and where things were getting stuck.

Designed tickets to cover every main step

A ticket for every step and a clear status for every client: each step in the new bookkeeping flow (classification, extraction, verification & normalisation, categorisation) got a structured ticket with ownership and state. The pipeline ran with humans in the loop of an LLM: I designed the states and handoffs around the model, what it processes on its own, when it escalates to a bookkeeper, and when the bookkeeper escalates to the client. Agents stopped working in personal Excel files and started working in a shared, trackable system. The client UI was updated in parallel to show the true status of documents at every stage.

For steps where full automation wasn't yet possible, we used chat-based tickets as a bridge — a trade-off, but structured enough to track and visible enough to measure.

After release

We shipped structure. ..but the cracks showed fast.

Realised what we'd missed

Once v1 shipped, one pattern dominated: agents spent most of their time asking clients a handful of questions. "Is this business or personal?" "What is this payment for?" "Can you upload a receipt?" All of it in chat and spreadsheets, unattached to any data. Clients actually wanted to respond proactively, they just had no interface to do it.

Operations wanted to keep Excel. I pushed back with one concrete argument: every answer clients gave in those cells was disappearing, never reaching our system, never feeding anything forward. Bringing it into the product meant every question and answer became measurable, queryable, eventually trainable. An answer a client gives once becomes a durable asset. None of that future is reachable from Excel.

Addressed it in the Transactions page

I redesigned each transaction row to surface clear states and required actions at a glance: what's missing, what's waiting, what's resolved. The agent app got the same updates in parallel: for the first time, agents could ask a question from inside the product without leaving it.

The key decision was comment-based escalations, inspired by how Figma and Notion handle collaborative annotation. Agents and clients were already having conversations anchored to specific transactions, just in the wrong place. Moving those conversations into the product, attached to the data they were about, turned the Transactions page from a display screen into a shared operating surface.

Tested it with users

The comment pattern landed, but one thing didn't.

Two rounds of recruited client testing, where 100% of participants correctly identified which transactions needed action. The comment metaphor needed no explanation — clients had already internalized it from other tools. Borrowing a universal pattern eliminated an entire category of confusion without any onboarding.

One thing failed: “Needs attention” was too vague. Clients understood something was wrong but not what to do. We split it into “Documents required” and “Answer needed”. Confusion resolved.

Before vs After

The same page, a year apart. On the left, a list you could only read. On the right, a working surface: statuses, open questions, missing documents, and a way to resolve them without leaving the page.

Results

For the first time, bookkeeping had a cost model. The outcome I think about most: the CFO could finally calculate cost per client, and that model directly supported expansion into the UAE. Headcount didn't grow, same team handles roughly five times the volume, because the work became structured, trackable and partially automated.

Personal takeaways

What looked like a UX problem was an operational one. What looked like an operational problem was a measurement one. Every layer had another underneath it, like a very stubborn onion. I learned to map before designing and sit next to the people doing actual work before forming any opinion about what they need.

The freedom was uncomfortable at first: vague scope, no obvious solution, a company under real pressure. But somewhere between mapping nine-step Excel workflows in KL and arguing that comment threads beat spreadsheets because the future is trainable, the discomfort turned into curiosity. I know now that I can take something really messy and make it legible. Not by simplifying the problem, but by understanding it well enough that the right structure becomes obvious.