Scalable Bookkeeping Flow

Context & Challenge

Osome is a software platform that handles company admin for entrepreneurs: bookkeeping, accounting, tax, compliance, all across SG, HK, and UK markets. When I joined, the automation looked solid on paper, but under the surface, 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. 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. I also tracked behavior through Amplitude and Microsoft Clarity.

North star: contact rate.

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: agents were running the entire bookkeeping workflow through Slack messages and Excel files. Every question to a client, clarification, document request, all of it happened in chat, with no record in our system, no standardization across markets, and no way to measure any of it. The two verticals (product and operations) had drifted so far apart that when I showed up asking to see their spreadsheets, agents looked genuinely surprised.

At the end I mapped the entire operating system: shadowed agents in KL, reverse-engineered the document pipeline with engineering, diagnosed client confusion through support tickets, and aligned accounting, ops, and tax teams around a unified workflow. The research informed the design and 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 wasn't a single feature: it 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 all main steps

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. Agents stopped working in personal Excel files and started working in a shared, trackable system. Client UI was updated in parallel to show the true status of their documents at every stage. For steps where full automation wasn't yet possible, we used chat-based tickets as a bridge — tradeoff, but structured enough to track and visible enough to measure.

After release

We shipped structure. The cracks showed fast.

We had a trackable bookkeeping flow for the first time. Agents were working from a shared system instead of personal spreadsheets. Clients could see the status of their documents without asking.

I realised one thing we missed:

Once v1 shipped, one pattern dominated: agents were spending most of their time asking clients few questions, eg '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 would be measurable, queryable, eventually trainable. An answer a client gives once becomes a durable asset. None of that future is reachable from Excel.

Adressed this in transaction page updates

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 treatment 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 — they were just having them in the wrong place. Moving that conversation into the product, attached to the data it was about, turned the Transactions page from a display screen into a shared operating surface.

Tested it with users

The comment pattern landed. One label didn't.

Two rounds of recruited client testing. 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 required.

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

Just to look back at the journey we've taken

Results

For the first time, bookkeeping had a cost model. The outcome I think about most: the CFO could finally calculate cost-per-client. That model directly supported expansion into the UAE. The headcount didn't grow — the same team handles roughly 10× 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.