In the early days at Divvy, there were only two roles in the app: 1) Admin – a role with access to literally everything and 2) a Member – a role with access to virtually nothing. It soon became clear that we needed a third role closer to the middle of both extremes and thus the bookkeeper role was born.

From 2018-2021, the bookkeeper role was among the top 5 most requested features from customers.

Product Research

The mission was not as simple as just building a new role; Divvy needed a role and permission framework due to years of tech debt and “bandaid” solutions.

In order to architect our solution properly and define roles in a way that made sense, we needed customer input.

Methodologies:

  • Customer support chat analysis (122 related chats)
  • User interviews (14 customers)
  • Card sort activity for interviewed customers (153 customers)
  • Survey (123 customers)
  • Competitor analysis
  • Wire-framing
  • User testing
  • UI design
  • Prototyping

Key insights

  • The primary job to be done was to reconcile financial records. This included activities such as categorizing transactions to match accounting systems, making sure transactions included required fields, syncing transactions to their accounting software, and running reports.

  • The two most common job titles users indicated for this role were Accountant and Bookkeeper.

  • Separation of duties was critical to our users (especially enterprise customers).

  • While there was consensus on most permissions, there were 3 permissions that were split 50/50.

  • We identified 2 additional roles needed by our customers in our research process.

Post-launch analysis

  • Overall, the bookkeeper role was a success and set us up with a role and permission service to quickly build additional roles. The customers who need the bookkeeper role use it regularly
  • 30% of bookkeepers used cards which validated our designs for a toggle-able card holding permission
  • Although 80% of customers did not use the optional attributes (i.e. additional permissions for a bookkeeper), the 20% who did regarded these optional attributes as critical to separation of duties
  • There was no significant support ticket volume as a result of this launch
  • About 10% of total users (at the time 300,000 total users) utilized this new role, which was expected due to our concentration of SMB customers

Scope

  • “Rolex”, a role and permission service
  • Migrate legacy permissions to Rolex
  • Bookkeeper role on the Web app
  • Bookkeeper role on the Mobile app
  • “Role printer” to verify backend permissions and roles
Tools

  • Typeform (surveys)
  • Zoom (customer calls)
  • Optimal Workshop (UX research)
  • Intercom (support ticket analysis)
  • Figma (designs)
  • Maze (maze testing)
  • Usertesting.com (user tests)

30

Bookkeepers with cards

10

Total specialized users using the bookkeeper role

20

BETA customers