Airbase CRM

Moving fast to build a do-it-all customizable enterprise CRUD app.

Chatting with a Lead over SMS

Chatting with a Lead over SMS

A better CRM from scratch

While there were existing CRM options for the debt relief industry, none achieved the right combination of per-seat cost, feature set, and vendor responsiveness to meet the needs of most small to midsized debt relief firms.

As a major payment processor in the industry, and already the provider of a large and robust SaaS application for managing payments across multiple channels and ensuring regulatory compliance, we felt we were in an excellent position to build a modern CRM for the industry and offer it at a terrific price. Finxera set out on an 18-month project to ship Airbase, taking our first customer (Pacific Debt Inc.) live in July 2021.

My role

  1. Visual design

  2. UX design

  3. Written product specifications

  4. User research (offsite in-person contextual inquiry)

  5. Sprint planning during initial stages

Timeline of my involvement

  1. Late 2019

    • Information architecture

    • Full visual design system creation

    • Written specs for core CRM features

    • Initial prototype creation with external developers

  2. 2020-now

    • Written specs and full designs for self-service administrative features of the CRM

    • Ongoing product implementation support and iteration

    • Ongoing participation in customer-specific implementation

I produced hundreds of unique real-world mockups to iterate and validate the design system early on.

I produced hundreds of unique real-world mockups to iterate and validate the design system early on.

Project tentpoles

At the start of the project, our heads of engineering and product set out the following goals for the CRM. It had to:

  • Be modeled to support the layers of users, organizations, and partnerships in the debt relief industry, while supporting both collaboration and privacy requirements across units.

  • Be architected to support most known requirements through module reuse and low-code configuration rather than incremental development.

  • Rigorously stick to a small set of powerful page layouts and UI elements, easing the production of a large number of pages and interactions within a short timeframe.

  • Have an administrative area that could allow business users to customize many aspects of the CRM without developer resources.

  • Address a number of engineering and UX point problems problems that the incumbents hadn't yet solved.

I was assigned to write the initial product specs for the platform, and get to work on the user interface.

Standard page types are broadly applicable, allowing fast development

Visual design system

The product has an initial set of CRM features, and is enhanced and customized to meet the unique needs of each individual B2B customer as they are onboarded, which can be quite varied.

To support most foreseeable use cases in an efficient way, the design needed to have the following key elements of a CRUD app:

  1. A powerful list view, with the right interactions for filtering, sorting, and displaying lists of different data objects to a multitude of user groups. I focused on the following:

    1. Providing for dynamic column visibility, with the ability to turn on and off columns, so that different groups of users could share the same list views with different column visibility settings.

    2. A standardized filter sidebar that can provide any number of possible filtering options for each list view

    3. The ability to sort the table by any column, whether or not the column is currently visible (by relocating the option from the column header to a separate dropdown)

    4. A way to save and share these settings as Custom Views, so that both individual users and groups of users with the same needs could leverage the same list views for a multitude of day-to-day use cases.

    5. A variation of the list view that supports multiple lines of text within each table row for specific use cases

    6. Narrow and wide variations of the list view

    7. An ability to display sum totals at the bottom of the list view

    8. A pagination method that just makes it easy to show more records if needed, and does away with numbered pagination

  2. A flexible detail view for displaying records, such as Leads, Clients, and Transactions, with incredibly rich and extensive data and relationships to other connected records. It has the following characteristics:

    1. A card-based visual approach that can keep a variety of layouts and interactions contained and isolated within themselves, allowing the overall page to always look aligned and orderly.

    2. Single and two-column layouts as choices

    3. A tab design that supports any number of tabs within a page

  3. An heavy leveraging of modal windows that employs them for most data manipulation and non read-only interactions, keeping it easy to maintain and enhance varied detail view layouts without the burden of supporting multiple UI states for each.

  4. A persistent app navigation sidebar that can organize any number of pages under hierarchical menus, while also supporting badged links for lists of action items, toggle switches that allow agents to set their availability for inbound calls, and more.

  5. A clean, uncluttered starting design that anticipates plenty of future product enhancements.

  6. A library of UI components that are carefully selected or custom-built for the unique needs of our niche in consumer finance.

Early on, I defined the typography, color palette, page layouts, UI element library, and core interactions that are reused throughout the app.

Writing the platform specifications

Likely the most challenging and time-consuming part of the project for me was writing the specifications for how various aspects of the platform should be structured and behave, and how each of the screens I designed should work.

The specs that I wrote dealt with subjects like the following:

  • What types of fields do we support in our data model, and how do we describe them to users.

  • What is the scope of the permissions system. How does it impact what individual users see at the level of the user interface, the data objects, and individual data records.

  • How can users create and manage templates for emails, e-sign documents, text messages, and more.

  • How do we support multiple companies collaborating within a single customer's instance, while maintaining data privacy between them.

  • How do users reset their password and take action if someone is trying to hack their account.

  • How does work get assigned and tracked using ticketing.

  • How do agents schedule communication with clients using appointments.

  • How do we handle flows where users need to make corrections to data by looking at it side by side with an uploaded document on the same screen.

  • How do we aggregate notes and event logs related to a single client on the interface when their data is scattered among multiple related entities.

  • How do we pop up an incoming phone call on the screen for our custom integrated contact center platform, and allow agents to answer, pass, transfer, coach, and conference phone calls.

And more. This was a highly collaborative process with the engineering leads, and where my dual role as a PM and designer came into the picture. Each part of the spec was accompanied by high-fidelity designs for how these features would look and work in practice.

Designing, writing specs, and being on scores of Zoom calls at home for Airbase through the 2020 lockdown (with support from my cat, Norah).

Designing, writing specs, and being on scores of Zoom calls at home for Airbase through the 2020 lockdown (with support from my cat, Norah).

Complex interactions among users and organizations

Complex interactions among users and organizations

Organizations, hierarchies, privacy, and collaboration

Normally, designers would talk about personas here. However, I needed to step away from specific user types and more broadly consider all the ways in which users could access a customer environment.

  1. Multiple companies working together within the CRM can serve each consumer (debt relief company, marketing affiliate, lender, and many others).

  2. Staff can have controlled access to one or more companies within the multi-tenant setup.

  3. Frontline staff play a large variety of changing roles, and supervisors manage teams with compartmentalized access to data.

  4. UI-level visibility of elements depend on each user's access and permissions, and some users can switch among interfaces owned by different companies within the same multi-tenant setup.

  5. There is data privacy in some cases, and collaboration in others. Some companies can see all leads and clients in the database, others can only see the ones they serve. Some frontline staff only see individual records assigned to them, while others work across multiple customers and can see everything.

Drag-and-drop layout customization

Drag-and-drop layout customization

Visual tools for self-service CRM customization

Once the primary CRM functionality was designed, specced, and on its way to implementation, I was directed to create exploratory specs and designs for the admin area, which is a highly complex product in itself, allowing non-technical users to customize their CRM instance in a variety of ways.

We explored a multitude of ideas, many of which didn't make the cut due to their complexity. We finally zeroed in on MVP basics such as allowing admins to manage third-party integration accounts, modify their document and communication templates, manage users and roles, and many other basics.

Below, you can see a few examples of screens I designed for the admin area. I created hundreds of screen iterations, high-fidelity mockups, and spec documents over the course of a year for this part of the project.

The Balance Calendar

The Balance Calendar

Solving unique pain points

I created often-requested solutions for key pain points in the industry that incumbents had not yet solved. One example is the balance calendar, a widget that tells debt relief negotiators:

  1. The peak balance that a client will achieve in their escrow account on each month in the future based on future scheduled transactions, allowing the negotiator to determine at a glance how to juggle multiple debts for clients and settle them opportunistically when funds are available.

  2. Improperly calculated outbound activity that is going to cause a client to have a negative escrow balance, needing urgent attention.

I created features like these in tight collaboration with individual users at debt relief companies, often flying to their offices to perform in-person contextual inquiry sessions. These features have been very well received.

Looking back on the project...

It's clear that the following decisions were the right ones:

  • Focusing on a tightly-limited set of reusable UI components, and not doing anything that could be done with existing components. This let us ship a lot of product really fast.

  • Focusing first on creating a data model that supported the complex web of interactions among players in the debt relief industry. This made us an easy sell to every customer and their ecosystems of partners.

  • Designing the system to be customizable via configuration rather than actual code. This let us be more responsive to all of our customers than the incumbents.

Some of the features we envisioned weren't sized well for our company, and we eventually decided not to pursue them unless we achieved unforeseen scale.

  • The drag-and-drop UI builder. From the explorations we conducted and the designs I created, we learned that this would be incredibly complicated. Even if implemented fully, it would have been unsuitable for creating more intricate screens, especially those contained in modal windows. It made sense in retrospect that most CRM's don't offer this.

  • The drag-and-drop automation builder. Like the UI builder, we explored this feature and learned that it would be difficult to achieve, and easier to solve with a low-code configuration approach than a visual interface. While possible to do, it didn't provide enough leverage at our scale.

  • The timeframe. Even though we kept things simple, 18 months wasn't long enough to bring the CRM to a high level of polish and tailor it each of our early adopters. If we could go back, we might have greenlit the project earlier, or tried to be even more lean in our approach, leaving the admin area explorations described above for later.

Trying to find Airbase on the web? Reach out.

To hear more about my role or the product, drop me a note and I'll connect you with a manager at Finxera. Airbase was launched in 2021 after being rebranded as BluCircle CRM, and is sold directly to a small market of B2B customers through a high-touch sales process. It doesn't have a public-facing website.