System of Record Part 2: Workflow Apps and Third Party Ecosystems

Clement Vouillon
Point Nine Land
Published in
7 min readSep 12, 2016

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 emergence of the third generation winners

In the previous post we saw that two macro trends — the democratization and unbundling of system of records — were shaping the B2B software landscape. The consequence is an increasing number of specialized SORs for an increasing number of customers (especially SMBs and SMEs).

Like most tech evolutions this third wave goes through the cycle: precursors, market education, emergence of winners and widespread adoption.

For SORs the first wave was about horizontal on-premise ERPs with Microsoft, SAP, Oracle Sage… being the winners, the second wave was about the first SaaS SORs with SalesForce, Workdays, New Relic… being the winners and we’re maybe in the middle of the third wave, specialized SORs, with the emergence of the first winners (Slack, Segment, Gusto, Docusign, Github, Intercom…) of this generation.

The current software landscape increasingly looks like a network of interconnected platforms and third party app ecosystems:

And it has major implications for workflow apps which we’ll analyse in the rest of the post.

What are the consequences for workflow applications?

As reminder:

“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. 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.“ From Tomasz Tunguz.

Since more and more software platforms are emerging, it becomes increasingly important for workflow applications to adapt well to this environment.

To discuss the many consequences that this changing landscape involves, the rest of the post is structured around three practical questions that a founder could ask himself today:

  • Why should I connect my application to a SOR?
  • How should I build the integration ?
  • Can it become a customer acquisition channel?

Why should I connect my SaaS to a SOR?

We need to distinguish two types of workflow applications:

  • Workflow applications which are SORs add-ons / extensions.
  • Workflow applications which are stand-alone apps (they can exist without any SOR).

SORs add-ons and extensions

As more SORs are transitioning to platforms there’s also an increasing number of SaaS products that are built on top of them and which approach is to offer extra features / specific enhancements. These products inherently need to be connected to one or more SORs.

ChartMogul is a great example of such software. ChartMogul is a SaaS, for subscription based companies, that connects to their payment system (Stripe, Braintree, Chargify, Paypal etc…) to analyze their billing data and help them understand their business better. They basically built an extra layer on top of these payment SORs.

The second type of products which is tightly linked to SORs are “vertical” add-ons.

Once a SOR grows big enough it can become the de facto platform of its software category. Ex: SalesForce. At this scale the SOR operator doesn’t bother building specific versions of its product for the myriad of niches and industries that might need it.

Instead they let third party apps do that job. For instance Veeva is a Billion dollar company that started as a CRM for the pharmaceutical and life sciences industry purely built on top of SalesForce.

“Verticalizing” an existing SOR is a real viable business strategy.

Stand-alone workflow applications

In the case of stand-alone workflow applications the answer to the question is a bit more nuanced. Here are some common situations for which it makes sense to integrate with a SOR.

The majority of your customers is working with a SOR and the majority of your competitors is already integrated with it.

Then you should definitely offer an integration too. For example if you develop a sales software for the enterprise segment chances are high that you need to offer a SalesForce integration ASAP.

Your workflow application needs initial data in order to work properly.

Many workflow applications need initial data before they can work properly. A good strategy to avoid the “empty product” effect is to fetch that data directly on existing SORs.

For example if you develop a lead scoring product, instead of asking your users to import data manually or to wait that your product fetches itself enough information, you can create an integration with Segment that will access the customer’s existing data.

Your workflow app creates additional data that can be added to existing business records.

This is probably the most common connection that exists between workflow applications and SORs: data synchronisation.

If your workflow application generates new data or modifies existing business records then it makes sense to offer automatic data sync. And if it’s not critical you can probably do it through a third party API platform (Zapier…) which are very convenient for this purpose.

How should I build the integration ?

A common theme that comes back when I discuss with founders who have built such integrations is how they underestimated the resources required to build and maintain one.

A first aspect to take into consideration is the platform’s API maturity. Some platforms like SalesForce are extremely mature with real developer support. For instance to appear on SalesForce AppExchange you need to pay a fee of several thousands dollars and to go through an app audit (security and usability) before you are accepted. Smaller SORs don’t have this level of control.

As a consequence a common advice that I hear is to spend some time doing due diligence (a.k.a ask other developers) to learn more about the quality of the SOR’s API, the quality of the documentation, the terms of use and also the quality of the support offered (many platforms don’t offer real support to their third party apps).

The second important aspect to take into consideration is how you choose to build your integration. Three options are offered to you:

  • Build the integration in house.
  • Entrust your integration to an IT consulting firm / platform partner that will build it for you.
  • Use an intermediary API platform.

The in-house option is definitely the way to go if your integration is critical to your product or goes deep into the SOR. But be ready to allocate plenty of developers’ time to it.

Outsourcing the development of your integration is also possible. Some IT firms are specialised in it and some platforms, like SalesForce, even have certifications for development partners . The advantage of these firms is the knowledge and the relations they have with the platforms but they are costly and better suited at big companies than young startups.

Finally, a good compromise between the two options mentioned above is to use API connectors like Zapier, elastic.io etc… These products act as intermediaries between you and major SORs and are very interesting for basic use cases.

How can it be a customer acquisition channel?

One of the major reason to integrate with a SOR is not only to please existing users but also to acquire new ones. In some cases these platforms can be interesting acquisition channels.

When I ask SaaS founders whether these platforms bring them new customers the vast majority answers yes, mainly through:

Platform Marketplaces

Many of the SORs listed above provide a catalog of third party apps available for their customers: SalesForce AppExchange, Xero add-ons marketplace, Intuit marketplace, Workday marketplace, Zuora appstore, Gusto appstore, Slack app directory, GitHub app directory, Zendesk app marketplace, Hubspot marketplace, Marketo marketplace, Docusign appstore, Segment catalog, Stripe listing etc…

All of them are not equal, far from, and it ranges from sophisticated marketplaces powered by algorithm fueled with user reviews and usage (SalesForce) to simpler but real appstores (Xero) or even minimalist bullet point listings (Stripe).

Obviously the more mature and sophisticated an add-ons marketplace is, the more it has the potential to bring new customers. The best one, by far, is SalesForce which is known as a very valuable distribution channel if you manage to rank high (and that’s not easy).

But some founders told me that they managed to get a decent amount of new customers through smaller marketplaces such as Zapier or segment.com.

SORs Customer Success Team

If your product brings real added value and if you manage to build a good relationship with the platform, it’s possible that the customer success or support team suggests your app to their customers.

Content Marketing

Some of the platforms cited above also write blog posts, customer testimonials and send marketing newsletters that promotes third party apps, which can bring new leads.

Software resellers

Another interesting aspect that I discovered while speaking to founders of third party apps is that software resellers are scouting these marketplaces and sometimes contact them to distribute their product (and obviously ask for a fee, based on performance, classic affiliation).

Now you’re probably asking yourself how much $ these channels can generate. Well I’ll probably disappoint you because I cannot provide clear numbers but while discussing from founders I could learn that:

  • Clearly some companies are doing really well on SalesForce AppExchange and you can do hundreds of thousands of dollars there. The other software platforms are all smaller than this one.
  • For the majority of founders I’ve interviewed the marketplaces were nice additional customer acquisition channels and not their main one.
  • The majority told me than they could generate from a couple of thousands to several tens of thousands $ of MRR.

--

--