System of Records Part 1: Evolution and Challenges

About this series

System of records have always been an important piece of the B2B software ecosystem. As the current B2B software environment is evolving fast we wanted to write a series of articles to cover it in details. This series will be split in 3 posts:

• The first article focuses on defining SORs, exploring the major trends shaping its current evolution and analysing the challenges they face in this environment.
• In the second article we analyze what are the implications that these changes have for SaaS startups.
• In the final post we explore what’s coming in the next years.

What is a System of Record (SOR)?

For the definition I will not reinvent the wheel and just quote what brilliant people have already written:

“System of record (SOR) is software that serves as the backbone for a particular business process. […] The power of systems of record is that they are the ultimate source and therefore “record” of critical business data. Your general ledger is stored in Quickbooks or Oracle Financials. Your pipeline data is in Salesforce. And your compensation and payroll information is in Workday. Once you are the “store” for critical business data, other applications, by definition, have to integrate into you in order for their solutions to work.”

Ajay Agarwal — Bain Capital

“A simple way of dividing the software world is system of record vs workflow application. Systems of record are the single source of truth about a particular department or company. A CRM is the canonical source of sales information; the ERP system is the canonical source of a company’s financial information. Systems of record are valued for their ability to generate reports and insight to the company’s management team […] On the other hand, workflow applications enable workers to do work. The products that appeal to salespeople, sales development reps, marketing associates, customers support reps are the most successful.”

Tomasz Tunguz — RedPoint Ventures

But, as with everything, this definition is evolving and sometimes the distinction between a system of record and a workflow application can be thin. This becomes clear once you look at the evolution of SORs.

A bit of history: the evolution of SORs

SORs are not new. This class of software already existed during the “on-premises” era in the 80s — 90s. Big companies had to adopt huge horizontal solutions from SAP, Microsoft, Sage or Oracle to store and manage everything from finance to HR or customer data. It was the golden age of on-premises ERPs.

These ERPs were really expensive and complicated to sell and setup. They required dedicated IT firms to be installed, long sales cycles involving the top level management and were generally license based with various fees for maintenance and upgrades. For all these reasons these solutions were costly, with poor UX and reserved to the enterprise segment.

The second wave of SORs was sparked by the internet. Between 1999 and 2006 the first generation of SaaS SORs like SalesForce, Workday, NetSuite, Marketo (etc.) started to change this landscape.

These solutions were still tailored and sold to enterprises but they introduced the cloud model and made SORs entered the digital age: products were available in web browsers, UX started to be a key differentiator and it was a first step in the great “unbundling” of horizontal SORs / ERPs.

Because the on-premises model is so heavy, most on-premises vendors bundled as many functions as possible in their offer (finance, HR, customer data at the same time). Since the cloud model introduced more flexibility, “specialized” SORs were suddenly more viable (SalesForce is your source of customer data, Marketo for marketing, Workday for HR…).

And you’ve probably guess but from that point the movement just accelerated. A new wave of products amplified the unbundling and the democratization of SORs. Companies like Zendesk, Xero or more recently Segment, Expensify, Workable etc. enabled small and mid-size businesses to benefit from products that were once reserved to big companies.

To sum up this brief history section on SOR’s evolution the big trends which are shaping the current landscape are:

• Product: UI and UX are more and more important in order to sell a SOR (and it’s becoming more and more competitive as many startups create great products and as users expectation rose).
• Unbundling: plenty of “ business records” that were once bundled in one software have now their dedicated solution. For example you can find many standalone SORs for the “Finance / HR” function: Expensify for expenses, Docusign for contracts, eShares for cap tables etc… A consequence is a much more fragmented SOR landscape.
• Democratisation: the cloud model enabled the democratisation of SORs with cheaper and more specialized (re: unbundled) products that suit small and mid-sized businesses (more SORs for more different types of companies). And these customers don’t have the same needs as big companies.
• Distribution: if traditionally the sales model of SORs was “top-down” (you sell to the C level that imposes it to the employees), the bottom-up approach is now possible as well (employees use your product and you sell it after to the management level).

Now that we have analysed the big trends shaping the current SOR landscape let’s dive in some of the challenges that these companies face in such an environment. In the rest of the post I will focus on two particular pivotal moments for SORs:

• The challenges on the way to product market fit (PMF).
• The challenges when transitioning from a pure “record repository” to a platform model.

Challenges on the way to product market fit (PMF)

As with any type of startup it’s extremely hard to get to PMF. That being said I would like to touch on two particular challenges that the vast majority SORs face at early stage:

• Creating a seamless record collection process
• Finding a replicable user adoption & sales model

Creating a seamless record collection process

A major challenge touches the product itself and how it collects business records.

The value of a SOR lies as much in storing records (payslips, contracts…) as in the process it uses to do so. If data collection is painful for the users the product won’t stick. There are 3 main approaches when it comes to record collection:

• Manual record collection: the user has to manually enter data in the system (ex: employees need to take pictures of their receipts or forward them by email to Expensify)
• Automated record collection: once installed the software automatically fetches data (ex: Segment which collects customer data directly from your app once installed).
• Mix of automated and manual. Ex: SalesForce with some sales data that is automatically processed by the software and some data that has to be manually entered.

If each of the way to collect business records I gave as examples above sounds pretty obvious today, it was not necessarily the case when at the beginning.

Before the widespread of smartphones people had to scan their receipts or send them directly to the person in charge. It’s because Expensify came up with a much better way to process receipts (thanks to the smartphone’s camera) that they could get an edge. It’s because they focused on making this process seamless that they made their product sticky.

It’s the same situation with segment and others “javascript snippet” based SaaS. If adding a javascript snippet to your website to collect your customers’ data sounds obvious today it was not the case early 2010s when solutions like segment or Intercom started to get popular. I remember that a major struggle back then for marketers was to convince developers to add and configure the snippet properly. Nowadays we are so used to this process that it’s not a problem anymore.

My point is that if you look at the list of successful SORs you will notice that a lot of them managed to get initial traction because they came up with a better way to collect specific business records. Working on this aspect is key to get to PMF.

There are so many different types of business records with so many different types of challenges tied to them that there is not a unique path to success.

You also have to take into account that new ways of interacting with data are regularly emerging. Chat bots and AI are for example two trends that could give birth to new SORs as they enable new ways of collecting business records.

Finding a replicable “user adoption” & sales model

Another major challenge for SORs is that very often the decision maker is different from the end user.

This is especially true for SORs built for enterprise and mid-market customers. For these customers the employees who are using the expense management tool or the single sign on solution on a daily basis are not the ones who decide whether to buy the product or not.

You have two main approaches to solve this problem:

• The top-down approach: target the decision maker directly
• The bottom-up approach: target the end user first

With the top-down approach you market and sell directly to the decision makers. This is a classic enterprise sales playbook where you need sales reps to convince big companies to buy your product.

In the bottom-up scenario you put the product directly in the hands of the employees who, if the product is great enough, will use it and spread it across the company without the initial approval of the C level. Once your product is adopted by enough employees it’s easier to sell it to the management level.

The first sales model (enterprise) obviously requires a strong sales force and can be more capital intensive at the beginning. The second sales models relies more on the product and whether you can replicate “product virality” from a company to another.

This user adoption “replicability” is crucial for bottom-up startups. In order to be valuable a SOR needs to reach a critical mass of employees in each company it targets. If enough employees use the product then the other employees will have more incentive to use it and the management level will have more pressure to buy it. Getting to a replicable process to reach critical mass in every new company you target is key and extremely difficult.

For SOR targeting SMBs the situation is slightly different as the decision makers are very often end-users themselves. The difficulty in that scenario, like for any SaaS for SMBs, is to scale customer acquisition.

Now let’s pretend that we managed to reach PMF, another very big, but interesting, set of challenges arises when it comes to transitioning the product from a pure record repository to a software platform.

From record repository to platform

A big part of the appeal and the power of SORs is that they can become platforms. Once you have convinced a company to entrust its business records to you and once you have reached the critical mass in terms of usage (within that company) you create a lock-in effect. It becomes hard for this customer to migrate to a new solution.

And once you manage to acquire enough companies you can become the de-facto platform of your category. That means that other software have a strong incentive to offer connectors to your platform and that it’s getting harder for new entrants to compete with you directly.

Are System of Records network effect businesses?

No. Not in the sense that the more businesses use a SOR the more valuable it becomes to other users. The main reason is that the data — or records — shared by companies is not used directly to increase the value for other users. It’s not because you join SalesForce’s platform that you’ll benefit from the data added by other users like you.

There might not be network effect but there’s definitely a critical mass component to SORs. The more businesses are on SalesForce the more it’s appealing for third party apps to come and connect to the platform to sell 3rd party apps. And the more 3rd party apps SalesForce can offer to their customers the better it is.

If the path to becoming a platform was a real option for the majority of first and second generation SORs, this path is now less clear. Why? Again because of the democratization and the unbundling of SORs.

One of the consequences of the unbundling of SORs is that many more types of business records have now their dedicated SORs product. The problem is that not all “business records” were created equal and not all of them have the “business critical” level.

For instance it’s very possible that Expensify becomes a platform at one point in the future but for the majority of companies “expenses” — as business records — is probably less critical than their sales data (SalesForce). And the potential to build an ecosystem of third party applications purely around expenses is also lower than for sales data.

So the more you unbundle a category the more you’ll have standalone products and the harder it gets to transition to a platform.

The counter argument here is that in order to transition to a platform you could first aim at dominating a very specific business record to later “re-bundle” other records. This is the path adopted by Gusto, HR tool, which started with payslip only and is now adding more “records” to its product (like benefits).

This unbundling also makes the line between SORs and workflow applications much thinner. Because many highly specialized SORs now exist businesses can compose their own SORs environment “a la carte” and switch from one product to another quickly through import features.