1+1 = 4: Why an Integration + Automation Approach is the Key to Scale | Workato + OneLogin

Alright, well, let's dig in. It's nice to meet everyone. My name is Kristen Ditsch, and I'm the Head of Product Marketing for Embedded Solutions at Workato, a leader in enterprise automation. And with me today is Oscar Rodriguez.

Hi everyone, my name is Oscar Rodriguez. I'm the Director of Professional Services at OneLogin, a cloud-based identity and access management provider.

And we're here today to talk about how powering integration with automation is the key to success for SaaS companies. Every founder wants their company to someday be on a list of newly minted unicorns or brand featured on a main— mainstream event like SaaStr. But what's the key to their success? According to research done by firms like SaaStr, Pandium, and Workato, integration is a critical point of commonality across the world's top-performing SaaS companies. In fact, the world's largest SaaS companies, as measured by market cap, have an average of 347 integrations in their product. And it's not just a volume game. SaaS leaders are looking at integrations because they're also strategic and good for business. As Blissfully's 2020 annual SaaS trends report showed, integrations help with 3 highly scrutinized business metrics: sales friction, retention, and net new revenue. More than 30% of SaaS buyers prioritize integrations in their buying criteria. Companies see a 25% increase in stickiness when their product is integrated with 4 or more applications, and customers have a 20% greater willingness to pay for your product when you have 5 or more integrations. Oscar, do these strategic differentiators resonate with you?

Absolutely. Stickiness is a big one. As an identity provider, stickiness is the key to growing and retaining customers. Ever since our partnership with Workato, we've become more sticky as adding additional use cases and automation capabilities. So it's been big.

Thanks for confirming. And we've seen customers try many different approaches to building integrations and tackling that backlog of requests. Here are the 3 most common. Number 1, offer integrations through customer success or professional services teams. And while this is a tailored customer experience, these solutions can often be one-off out of product, and offer little opportunity for scale as your business grows. Number 2, refer customers to an integration partner. While partners offer your customers specialization and should provide great outcomes, your customers are then forced to manage an additional vendor and budget cost, which creates friction in their experience. And your team is quite literally handing over known possible revenue. And last but certainly not least, number 3, build integrations in-house. While this option allows you to bring integrations in product and not leave revenue on the table, there is a cost to this option that's worth weighing more. Regardless of which of the three attempted paths to integration you took or might be looking to take, we find that most product teams looking to strategically solve for integrations ultimately find themselves at an intersection of build or buy. And there are certain circumstances where your team should consider forging down or continuing down the path of build. If there is an integration that's absolutely central to your business, if the scope of the integration is shallow and won't require a lot of maintenance, or if it's a single point of integration where the maintenance will be manageable post-deployment. But if your team is concerned with the opportunity cost of building integrations, buying your integration strategy may be the best way. Your team may be concerned about your time to market, whether for competitive reasons, delivery requirements, or just general efficiency. Building integrations can take weeks, if not months, which creates delays in your ability to release a solution to your customers. By buying an integration solution, you can unlock new points of connectivity in minutes. Number 2, your team may be concerned about the commitment of building integrations. Building in-house requires expensive technical resources who understand complex APIs and how to build to them, and then also manage the ongoing maintenance of this API work. Buying an integration solution means you can outsource this core utility and refocus your team on building core capabilities that are unique to your product and that your customers are dependent upon you solving. And last but certainly not least, your team might be concerned about volume. There's nothing worse than a growing backlog of integration requests or having to say no to customers. By buying an integration solution, you can unlock hundreds of points of connectivity instantly. Buying an integration solution ensures you can solve for your customers' experience and capture that missed revenue while still maximizing your most expensive resources, your engineering teams. And why else would you want to buy an integration solution? Well, you built your product to solve a specific market problem. And you're doing great. You may still have a standalone solution, but you found product-market fit, you're servicing your customers, and you're here at Zaster to learn more. As we've discussed already, building integrations can help connect your product to other key tools for your customer, which we now know can improve your ability to gain and retain customers because you can offer an integrated solution. But by buying a modern integration solution, you can actually build even more value for your customers by leveraging automation capabilities that turn your individual app into a platform that centralizes your customers' key workflows. So to reinforce my last slide, a modern integration tool does so much more for your product than point-to-point connectivity. It's a true enterprise automation solution that helps you center your customers' processes in your product, which will help you gain new customers, reduce risk of churn, and increase revenue. The next generation of enterprise automation will make embedded solutions easier to create, deploy, scale, and manage. This includes improved control of the UX to create a seamless look and feel with your product, and your customers will never know that your integration solution is outsourced. A marketplace view of applications inspires the art of the possible amongst all the points of connectivity that you now have available. And with an embedded integration solution, you have flexibility of configuration and deployment so that you can tailor your integration and automation solutions by market segment or geo safely and at scale. So hopefully by now you see that the old inefficient ways of managing your integration backlog are narrow and not scalable, and that there is a more strategic and better way. And you don't have to take my word for it. This integration approach has been adopted by some of the companies we're all here to learn from and emulate, and we're fortunate enough to have one of them here to share their story. So I will turn things over to you, Oscar.

Thank you. So OneLogin before Workato— before we partnered with Workato, we had 4 key areas that we identified that we need to solve for as a company. The very first one is market movement. The first area we wanted to focus focus on is really keeping up with the market. As everyone knows, the market is never stale. It's always evolving and changing. I've been at OneLogin 7 and a half years. In my early years of my tenure, most customers came to us to solve a single sign-on, a multi-factor need. But over the years, integrations have become more and more popular. On a daily basis now, we get customers and prospects asking us for new integration and new integrations and ways to automate those integrations. So in addition to kind of keeping up with the market, other competitors in the space had made some huge strides in their integration strategies. So it was very key for us to kind of keep up. And one competitor specifically actually purchased an integrations partner— provider. So every conversation that our sales folks are going into, integrations were a part of that conversation. So we needed a way to solve for that. The second area that we needed to really focus on is a lack of agility. Like most startups, we didn't have a huge product management team. That was large enough to build in-house expertise of every API our customers were requesting. It was near impossible to keep up with that. In addition to that, we had a lot of concern from our team internally about how we would get, you know, keep up with the technical debt that building a solution like this in-house would, would cost. And then many of the customer use cases that we were seeing were not small. They were very large, very complex. In our solution specifically, we try to build integrations that will work for all customers, not one specific one. So, you know, these integrations were very focused and customers were, you know, bringing us more and more every day. And as a result, we just felt we didn't have a good solution to solve for these integrations as we scaled as a company. The third area that we really wanted to focus on was missed revenue opportunity. I cannot even begin to tell you how many deals that we lost simply for not being able to check a box around a specific integration that we supported. And obviously, the more and more integration requests we received, the more and more lost revenue that we had. And the last piece was poor customer experience. In many cases where we had customers that were very happy with us, we were still left with less than ideal workaround solutions. Most of the solutions that we had to provide were based on partners deploying a specific one-off solution, which added additional vendors to be managed in the sales process, which made it much more complex and painful, as in many cases, detailed scoping exercises were required before the deal closed. And then many people know on this call, the longer a deal stays open, the smaller chance you have of closing it. So that was definitely becoming a pain point for our sales org. And the partner approach also meant that even when a solution was deployed, the partner had to do knowledge transfer over to the customer, and the customer was then in charge of maintaining a custom integration, which was not ideal. This approach also led to two support teams supporting the customer, not only the OneLogin internal support team, but a partner support team would have to be involved for the custom integration, which left customers scratching their heads. Well, where do I send my support ticket to? Right. So that became a problem, which is less than ideal for a customer experience. And again, OneLogin is all about customer experience. That was definitely a pain point of ours specifically.

Next slide.

So here comes OneLogin Workflows. With the Workato embedded platform, we actually built and released what we call OneLogin Workflows. Not only were we able to tackle integration customers were requesting, but we also added workflow automation capabilities that provided even more customer value. Here you can see what OneLogin workflows powered by Workato actually looks like. The screen capture shows a simple workflow triggered by the user status within the OneLogin UI. Once the user is disabled within the OneLogin UI, the OneLogin workflow goes to work. In this specific example, the user was disabled within OneLogin and an offboarding workflow was triggered, which transferred all G Suite user data, calendar, and mailbox to the disabled user's manager automatically and sent an email to the manager and the IT team. Operations like this in the past would have required manual intervention from the customer's IT team, which burned valuable resource time. Workflows like this have become set-it-and-forget-it exercises, which allows customer IT teams to focus on other areas. Next. All right, in addition to providing customers value, we also— we actually benefited around 3 key areas beyond just integrations here at OneLogin. The first one is scale. With the scale we're able to deliver with Workato's embedded platform was unimaginable to us before. In many cases, we had to create feature requests that went to our product team to do analysis to see how much resource it would take, how long it would take to deliver, how many months it would take to deliver a certain solution. And many of these we're actually able to do in days now, which is extremely important to the sales cycle that we're currently on. Our market is very, very fast-moving, so a lot of customers are looking for things to get done very quickly. And the way we kind of look at this, we're able to essentially move from deployment within 6 months down to a matter of days. Which is super, super important. In addition to that, this is a low-code platform, which means I can hire less technical, less expensive resources, and no need to hire engineers to deliver these integrations, which is a huge change for us. And then, like I said, additionally, it saved our PM resources. Those PM resources are now focused on the OneLogin product and delivering other features to customers beyond integrations. Another cool piece about The delivery of this is since, since our initial build, my professional services team actually handles day-to-day operations of the Workauto solution. So there is no need to have partners involved, which also has brought us to a case where there's no more handoffs to partners, no more customer goals or technical requirements being lost. And now we're providing a seamless experience to our customers. Since this is a no-code solution, or in many cases no-code, our customers can also build their own workflows integrations within Workato without even my team's assistance, which is a huge step forward for OneLogin as a platform. And the third benefit was expanded revenue. Within our first 3 months, we unlocked $674,000 of ARR, or influence ARR, which was 1.5 times more ARR than any other tier 1 launch within OneLogin. So this was a quick-selling project or process. And even in addition to that, it also expanded our professional services revenue opportunities by allowing additional deployment opportunities.

So with that, we'll open things up for questions. But please do feel free to reach out to either of us and connect with us. Follow our respective companies on LinkedIn. And with that, we'll open it up for some questions.

I see the first question. How long did it take to implement your solution? With the help of the Workauto team, initially what we did is we built our, what we call the OneLogin SDK, which was built generally within a month. We've been modifying and tweaking it since, but essentially within a month we were able to start to get users and customers through the Workauto platform, and which helped us really start to scale this out very, very quickly.

Awesome. The next question that I see coming in, and please do feel free to use the Q&A function to chat in some questions, But the second question is, we have a lot of native integrations that are built in product already. How does Workato fit into that work? Do we have to rebuild everything? So we actually have a number of customers who have very strategic integrations that they've built natively, that they, in some cases, have had in place for years. In other cases, it's just strategically important for them to build them now. And those things can coincide. TangoCard is another customer of ours that comes to mind. Who, their head of product, has, has had some really great conversations with us, and you can find some of this stuff on our YouTube page. But speaking to how there were certain circumstances for their team that it made sense, their integration to Salesforce, for instance, was really critical to their business strategy, and they decided to build that natively. But then for the volume of requests, like Oscar was just describing, that one login experiences, TangoCard had a similar thing where their integration backlog was pretty extensive. And so then a solution like Workato's embedded platform allowed them to make sure that they were solving everything at scale where they didn't need to have the same depth of knowledge or integration. Oscar, I see another one coming in for you. How did you— yeah, I'll let you read it.

Yeah, how do you justify the initial investment in Workato? Who was involved in the purchasing process? So this was a team effort on the OneLogin end. We had couple people from the product team, my boss who was the lead of strategy, but we came to the conclusion that it was going to be a much less, less, much less investment going directly with Workato than trying to build this in-house. And honestly, we chose the best-of-breed solution, so we knew we were getting a top-notch solution, whereas we would have to spend months and maybe years to build a similar product in-house. So we wanted to really test out the capabilities of Workato's automation engine to really get us going. And obviously we've seen huge strides and gains in our short amount of time. Hope that answered the question.

What kinds of skills do we need to build recipes? So as Oscar mentioned, the recipe builder is a low-code environment, and a lot of the steps that are within it are actually no-code. So I'm a very non-technical resource. I'm in, in the product marketing team, and I I've successfully built and deployed recipes that I've built, which are those automations that we have. But there's definitely— it's, it's a very easy-to-use product, but something that has a great degree of sophistication in terms of what you can build, considering how accessible the UI is. And Oscar, I don't know if you have anything else to add to it since you're in the system every day.

No, again, this— again, I think there's opportunity for every level or skill set. Again, myself, I'm not the most technical person in the world, and I was able to build out a simple use case like I demonstrated during my presentation within, you know, 35-40 minutes. And again, there will be some more technical requirements if you're trying to build custom SDKs. Or one of the benefits of Workato is that also allows you to use your provision down to an on-prem system, which pretty much no competitors out there really do very much. So again, that would be a little bit more technical requirements there to do the on-prem stuff. But for the most part, Workato has a good library of pre-configured recipes that simply you can click, point and click, and kind of get going very, very quickly.

Awesome. I think this is a great question for you. Was there any roadblock from a security or compliance perspective when rolling this out to customers? Any impacts to the existing terms of service, legal contracts?

Yeah, before we actually, you know, signed on with Okada, obviously my security team did a deep dive, and also that, you know, our legal team also did the kind of deep dive and making sure that we were meeting all customer requirements based on, you know, the OneLogin standards that we put out to every customer. Again, we do kind of protect this like we do with any other application, you know, with SAML authentication and multi-factor authentication. So it was no real security pieces that would change from our normal product, which made it very easy for us to kind of get through the partnership process.

And I think that's one of the nice things about finding a partner who specializes in this piece. Since integrations are all we do, we're very oriented around the security compliance governance that we need to have in place so that folks like Oscar have great peace of mind when they are choosing to outsource this kind of tool. With that, I think that's all the questions that I'm seeing at the moment and that we have time for, but really appreciate everyone joining today's session. Hopefully you've learned a little bit more about how integrations and automations together can help successfully scale your business, but do feel free to reach out on LinkedIn or through other channels if you have any additional questions. Thank you so much and have a great rest of your day.

Thank you all. Have a great day.