Clarifying accounting workflows and streamlining customer input through a new homepage, reducing churn and accelerating month-end close
Context
How do we reduce churn from our larger customers?
Ceterus is a fintech startup that provides bookkeeping and tax services for small businesses and franchises through an online portal with automated bookkeeping and advanced reporting. The company primarily supported franchise owners with 2 to 10 locations, but churn increased as customers grew beyond 10. Our systems did not scale well, and larger clients struggled with slow or inaccurate bookkeeping and confusing workflows.
Impact
Decreased time to close books
Decreased monthly churn
Increased customer capacity
100% reduction in cost, with the company no longer requiring Zendesk
My Role
I served as the product designer for this project, leading the design work across research, workflow definition, interaction design, and final screens. I worked closely with a product manager and a team of about five engineers, and regularly presented progress and direction to the broader product team and investors. This work was completed alongside the design of a custom support ticketing system.
The screens shown here combine my original product design work with both production UI patterns from our React library and a later independent visual refresh.
This project originally shipped in 2025. The lead visuals shown above reflect the independent refresh I explored beyond the product direction at the time, while production screens are included throughout the case study.
Discovery
The most common reasons for churn at Ceterus were tied to how quickly a company’s books could be closed and how accurate those books were. After losing several larger customers, the product team prioritized interviews with high-location customers and recently churned accounts.
In addition to qualitative interviews, I analyzed session data for higher-location customers using our analytics tool. This helped identify behavioral patterns, engagement gaps, and friction points in critical workflows.
Features
Bringing clarity to required customer actions
Business-critical tasks were not only split across multiple pages, but users lacked clear context around what was required to close their books. Customers often relied on external tools like spreadsheets to track and prioritize tasks for individual locations. Without a clear system inside the product, they risked submitting incomplete information, which could delay closing books across all locations. These challenges only worsened as the number of locations increased.
I proposed consolidating those pages into a single unified experience, since they represented two parts of the same workflow. I designed a new home page that brought both parts of the process into one place, allowing users to complete required actions without moving between screens. Tasks were grouped by what they accomplish, helping users prioritize based on business impact or speed of completion. A location filter further improved that prioritization by allowing customers to focus on specific locations instead of managing everything at once.
Streamlining business-critical customer input
Prior interviews had already surfaced major friction in the transaction categorization workflow, which lived on a page called Transactions to Code. Beyond missing context, the interface was bloated and difficult to navigate. Transactions were displayed as single-line table rows that required users to categorize, add details, and leave comments all in the same row, which extended beyond the screen width. The comment workflow was especially unintuitive, which often led to important clarifying details never being submitted.
While the home page addressed broader contextual gaps, the categorization experience still required significant improvement. I redesigned the workflow around a drawer that opened detailed transaction information without taking users away from the main page. This provided more space for a clear visual hierarchy and allowed the process to guide users step by step.
I also simplified the copy into plain language to make the process more accessible for users with less accounting experience. At the same time, I advocated for flexibility for power users through a feature called Accountant Mode. By default, the Chart of Accounts was grouped into guided categories to support less experienced users. When Accountant Mode was enabled, those groupings were removed, allowing experienced users to navigate directly to specific accounts.
Boosting engagement for higher location customers
When analyzing session data, I noticed that customers who regularly used analytics and reporting tools logged in more frequently and stayed more current on required action items. Many higher-location customers, however, were not using those features, which led to fewer logins and a buildup of unresolved tasks.
To increase engagement, I focused on two improvements. First, I introduced more flexible reporting filters. Previously, users could only view data for a single location or all locations combined. For customers managing many locations, viewing everything at once was often too broad to be useful. I added the ability to view subsets of locations, enabling more actionable analysis.
Second, I surfaced high-value data points through clearer data visualization. By identifying which metrics active users relied on most, I prioritized those insights and made them easier to digest. The goal was to increase the value of logging in, encourage more frequent engagement, and indirectly drive better completion of required bookkeeping tasks.
Component Library
Process
While this case study focuses on the homepage, this project reshaped how Ceterus handled month-end close workflows more broadly. There were two major areas of focus:
Externally, the goal was to create a more intuitive experience for categorizing transactions and showing customers exactly what was required of them to close their books at a more granular level.
Internally, the work required changes to how Ceterus closed books and how support operations were handled. A new internal ticketing system would need to be introduced to support those external improvements.
Discovery + Research
After recently experiencing churn from larger customers, the product team and I focused our research on high-location customers and recently churned accounts.
These interviews led to a few key findings:
Users lacked key details about the information required to close their books
Larger customers were quickly becoming overwhelmed by the volume of action required across locations
Users managing many locations struggled to parse financial details at scale
Communication inside the application was clunky and unintuitive
The existing pages responsible for customer input were far from perfect, but those issues became much more severe as the number of locations increased.
These items that require customer input and block critical business functions would come to be known as blockers, which fell into two categories: Transaction and Non-Transaction. At the time, Transaction Blockers lived on Transactions to Code, while Non-Transaction Blockers lived in the Action Center. I had already identified issues in Transactions to Code, especially around comments and submission flow, but there was a larger structural issue. Two separate pages were being used to complete one workflow, and completing all blockers on one page still might not close the books for a single location.
The Action Center also did little to help users prioritize their actions. It did not show how old blockers were, how up to date a company’s financials were, or whether a given item was truly preventing books from being closed. Even identifying the related location for an item required hovering one by one, while large stacks of transactions still had to be handled on an entirely different page.
I proposed we combine the pages at least, but that was not as simple as it seemed. Because of how Zendesk tickets were being pulled into the Action Center, they could not coexist with another item type like transactions. That technical constraint is what created both the internal and external sides of the project. If we wanted blockers to appear together for customers, we first had to create a new way to manage them internally. That work eventually became a custom support ticketing system called Blockers, which was developed alongside the homepage redesign.
The original Action Center that could only link to the Transactions to Code page.
Once that decision had been made, the question was how to display them together. In early conversations with leadership, I proposed introducing a new homepage rather than continuing to layer more functionality onto the existing Action Center. A new homepage created room to better contextualize blockers, and with drawer interactions, users could take action without being pushed across the product.
Early iterations explored different ways of grouping blockers and showing close status across locations. Month, location, and blocker type all mattered, but they needed to be organized in a way that felt natural for accounting workflows. Leadership wanted blockers to dominate the page and demand attention. My role was to balance that business need without creating notification fatigue for users.
Early homepage draft for blockers list divided by close periods.
At that point, it became clear that improving customer input alone was not enough. Even if the workflow became easier, it was still asking customers to do more work in service of getting their books closed. I did believe the current user flow was slowing the process down, but the analytics pointed to a broader product opportunity. If the application was going to ask more of users, it also needed to offer more in return.
That is where financial insights became important. They introduced a more valuable customer-facing layer to the product, one that could encourage more frequent engagement while also helping customers make better business decisions. It also created an opportunity to present a clearer break from the older version of the application and define a stronger product direction going forward.
During this time, I was also asked to reimagine what our application, then called Edge, could look like in a complete redesign. I knew that direction was unlikely to ship in full, and creating entirely new interfaces that quickly was not ideal, but it gave me room to explore new components and interface patterns.
Design
As I worked through the redesign of some of our most frequently visited pages, one of my main goals was to establish a clearer visual hierarchy. Prior versions lacked obvious paths through the interface due to inconsistent sizing, grouping, and emphasis, which made key actions harder to identify. I wanted to reduce cognitive load by making required actions more visible and presenting them in a way that could be understood regardless of a user’s accounting knowledge.
I also looked for opportunities to restructure the sitemap and make the application feel more personal. By recategorizing pages, I aimed to speed up key navigation paths and better set expectations for what each page could help users accomplish. I also wanted to introduce settings that gave users more control over the financial views they were greeted with.
Because blockers, especially transaction blockers, were still at the center of the project, I wanted to introduce possible solutions for them early and often. Over the next two weeks, I iterated on low-fidelity transaction concepts with leadership and development to find a simple way to handle a naturally complex workflow.
Early 99%er screen after development revealed a multi-layer drawer would be required.
In early discussions, leadership focused heavily on two-line transactions, where a user would only need to edit one line. This type of transaction was the most common we handled and eventually became known as the 99%er. Getting that experience right was essential. I wanted the UI to make it immediately clear where a transaction came from, what it was, and where it needed to go. The accounting logic would always require some effort, so the interface itself needed to stay as straightforward as possible.
Transactions with three or more lines introduced a different problem. Early in development, it appeared that customers would not be able to edit them directly and would instead need to leave comments for our team to handle manually. Development later found a way to support both transaction types, but only if they shared the same UI components. That introduced a major risk, because the extra fields and complexity of multiline transactions would start to compromise the simplicity of the 99%er experience.
Early proposed UI for a 99%er.
Multiline transaction UI with a 99%er.
I pushed back on that direction. The 99%er flow had already started to bloat under development constraints, and combining both transaction types into one pattern threatened to make the most common workflow harder for everyone. Once we were able to validate the designs, users strongly preferred the simpler version. It became clear that sacrificing the experience of the majority in order to accommodate less common edge cases was the wrong tradeoff. Even with added development time, preserving a distinct 99%er view was the right decision.
Initial launch bersion of the 99%er view.
With transaction coding more clearly defined, I continued working through the rest of the redesign. Scope had removed a full application redesign from the table, but the Homepage, Blockers, and potentially financial statements were still in play. Because those were some of the most heavily used features, there was still an opportunity to make the experience feel meaningfully new.
Non-transaction blockers were more straightforward externally. Most requests fell into a small number of categories, including information collection, external integrations, and text entry. Even though there were technically dozens of blocker types to account for, that variety could be handled through a smaller set of UI patterns. When designing those flows, I focused on maintaining context so users could always understand what action was needed, for which process, month, and location, without navigating around the product.
Early iteration blocker templates for a range of possible customer needs.
One of the bigger product and engineering tensions in this part of the project centered on the drawer itself, specifically submission behavior. I pushed for a one-click solution where users could make their changes and submit everything at once. Development pushed back in favor of a simpler implementation that would require users to save or submit each change independently and then manually close the drawer. Leadership ultimately aligned with the simpler user experience. Even if it required more engineering effort, this was not a tradeoff we wanted to make at the user’s expense.
Final mockup blocker templates for a range of possible customer needs.
As scope narrowed further and financial statement redesign was removed, focus returned to the Homepage UI itself. With a clearer understanding of the technical possibilities and timeline, I stripped the interface back and focused first on workflow clarity, then rebuilt the visual direction from there. From that point on, the challenge became finding alignment across leadership, the product team, and other stakeholders, all of whom had different preferences for how bold or restrained the interface should feel.
Some of the many UI options for the blocker list that were presented to various stakeholders.
As those conversations continued, I narrowed the gap between those preferences and found a middle ground that allowed the work to keep moving. That also gave me room to continue developing financial insights, which would shape much of the Homepage experience. From the beginning, I only planned insights around data and chart types I knew were already possible within the product and our existing library. Even within those constraints, there was still a question of what would be most useful to surface first. Working with the product team, engineers, and accountants, we defined an initial set of charts that could support both multi-location and single-location views and evolve over time.
Early Homepage Iteration in a Testing Environment.
Conclusion
After a period of UAT, we rolled the update out gradually over several weeks, beginning with beta testers and accounting for the migration from Zendesk into the new blockers system. The impact was noticeable quickly. Users were highly engaged with features like transaction editing, and the clearer categorization of blockers made it easier to understand what was actually blocking the close process and what to prioritize first.
More importantly, the project created a clearer and more scalable foundation for supporting larger customers. It gave users more control, improved the visibility of critical workflows, and established a stronger product direction moving forward.
Revisiting the Interface
After the product launched, I revisited the interface to explore how the homepage could evolve with fewer constraints. This refresh was created independently while updating this portfolio and reflects how I would approach the project today, with a stronger focus on hierarchy, current technologies, and responsiveness.
During the original project, product timelines and broader platform priorities limited how far the visual system could evolve. The focus was on delivering functional improvements quickly, which meant some system-level opportunities were deferred.
I focused the refresh on areas where the original experience had the most opportunity for improvement.
Stronger Visual Hierarchy
The refreshed layout creates a better balance between business metrics and the actions customers need to take. Financial insights remain prominent, but blockers are more clearly organized, helping users understand both the state of the business and what requires attention.
This approach reduces visual competition between elements and allows users to move more naturally between monitoring performance and taking action.
Modernized Component System
The refresh introduces a new UI with a three-tier token architecture in mind, along with more consistent patterns for tables, cards, and controls. Beyond a more contemporary visual style, the updated system improves responsiveness and creates a stronger foundation for scaling the product across different screen sizes.
It also simplifies interaction patterns and creates a more predictable experience across the platform.
Responsive and Mobile Experience
The original product focused primarily on desktop workflows. In the refresh, I explored how key operational tasks could translate to a mobile experience.
This included adapting navigation patterns, and action flows so users could review and manage tasks from smaller screens without losing context.
Expanded Data Visualization
Some data visualization concepts explored during the original project were ultimately cut due to development constraints. In the refresh, I revisited those ideas to better highlight trends within financial data.
These visualizations help users quickly identify changes in revenue, expenses, and operating performance without relying solely on tabular data.
AI-Assisted Transaction Categorization
Transaction categorization is one of the most repetitive tasks in the product. In the original experience, users needed to review each transaction and manually select an account from a long dropdown list.
In the refresh, I explored introducing AI-assisted categorization. Incoming transactions are analyzed and the system suggests likely expense categories based on transaction data. Users can quickly confirm the suggestion or choose a different account if needed.
This approach reduces the cognitive load of scanning long account lists while still preserving manual control when the suggestion is incorrect.
