The Audacious but Rational Onboarding Package Trend
It seems pretty audacious: the company wants to sell you their technology/product, and then they ask for an up-front contract as well to "help" you get started. Shouldn't that be free? Is there documentation so non-existent I can't do it myself? Or maybe there's something different going on and it's not so audacious an idea after all, but eminently rational.
Speaker: Terry West Guest: Raquel Gonzales
read podcast TRANSCRIPT:
[00:00:01] - Terry West
I'm sitting here today with Raquel Gonzales, our marketing director. We were just chatting a few minutes ago about custom services and when you have to pay a company to help you use their product. It's an interesting trend. A while ago, Raquel had researched a variety of marketing automation tools and that's why I wanted to her here with me today to discuss this trend.
As we research different marketing automation tools that help you with your web site, to figure out you know what people need on your website, and things like that. We also looked at some Salesforce plugins and a variety of different SaaS-type tools including SAP. Were an SAP shop so we got up and running on SAP business one. And all of those tools, as we were engaging with the companies that sell that software said .... Of course theyre are SaaS right. So they charge you a monthly fee or an annual fee or whatever it is. And we get that that's the business model. But all of them up front said – “Oh, yeah. But you can't buy our product unless you also buy an upfront-onboarding package or kickstart package.”
They used a variety of different phrases. But basically what they were saying is, “We’re not going to let you buy our product and go to the monthly fee model until you pay a whole bunch of money first.” OK. Now I've got to say, from my perspective, that hit me kind of weird. Wait a minute. And if your Salesforce, of course you're just taking every dollar out of my pocket. For those of you have to pay for salesforce on a monthly basis, you know what I'm talking about. So I'm thinking wait a minute, you're going to charge me that many thousands of dollars every single month. And as insult to injury, you're going to make me pay this huge fee 10 20 30 whatever thousand dollars up front just so I have the privilege of using your product. OK.
So I didn't react well to that kind of, what I thought was, audacious ask. And I've completely changed my view on that, quite frankly.
So Raquel. I know when you were looking for marketing automation tools, HubSpot and a few others. They also said the same thing. Right.
[00:02:24] - Raquel Gonzales
Yeah. Every single one of the SaaS software that I was looking at had some sort of onboarding package included. Everyone had their own lingo and specific terms for it.
[00:02:36] - Terry West
What kind of terms did you see out there.
[00:02:39] - Raquel Gonzales
What I saw was that for a specific number of months or days you would receive this onboarding package service. And they would help you by expediting whatever that automation platform was. Some of them had terms like "we will help you for the first month," while others said, "we will commit to helping you for the first quarter of your time with us," and others we're somewhere in between that. Those terms played a role in deciding who I would choose, because a big concern was - who is going to be able to support me to a level that I needed. But all of them had some sort of onboarding package.
[00:03:13] - Terry West
So how did you feel about that, because I know how I reacted, when you went to them and you and they said, "Ok, pay me so that will give you customer support." I mean that's what I just heard you say, "pay me so that Ill custom ..." I mean I'm going, "Wait a minute. I'm your customer support me." Right? So how did you respond to that. Is there a differentiation in those companies between what you get for free versus what they'll do extra. My understanding is that onboarding package wasn't really optional for many of these companies. It was mandatory that you bought that up front.
[00:03:45] - Raquel Gonzales
It was definitely a mandatory investment. Now whether I decided to take it or not was optional, some of them I passed on because I didn't see any value in their level of onboarding package. But there was a difference between support, as in regular maintenance support, service calls, asking your typical technical questions about a specific portion of that solution, whatever the software was.
There's also a level of service package that is different from that. Onboarding is not "I'm going to call you for a question about the specific portion of your tool." Onboarding is "I am diving into this entire platform by myself, and my platform for me is my marketing automation platform that I currently use. I'm diving into this journey by myself and I have a limited time to onboard. We really we needed this platform within three to four months. That was self-impossed goal (much like time to market for our industry).
And so at the time, that the distinction between the support services and the onboarding was very visible to me. As a customer, they were going to help me get my complete platform system up and running within that allotted time. Now some people would promise it would be a month, and others would promise it would be a quarter. There were those disaster stories I heard that it could take a whole year for a certain software platform to be completely onboarded and implemented.
I ended up choosing what we currently use now, which is HubSpot, because of the level of onboarding package that they were able to promise me and they did fulfill that. They did exactly what they promised. They got me "to market" like you say, but they got me functional in under three months. And that was really helpful for me. Within about a month I already had access to real-live working tools and assets on my end for our marketing team.
[00:05:47] - Terry West
So did they offer you different levels of onboarding package like for this you get this and for this you get that?
[00:05:52] - Raquel Gonzales
Oh, absolutely. Depending on what you are using on the platform, there's pieces of the platform that I'm not even using at this stage. Some teams have call centers for example that might leverage their service areas and things like that and I just didn't need those areas of the platform. But yes, if you were going to purchase certain key elements of that software, then you needed the onboarding package to support that.
[00:06:19] - Terry West
So when you did this and I want to ask you one more question here before pivot to the embedded space because I think there's a very interesting analogy of where this is going. In your experience with HubSpot is very relevant to embedded designers and the way things are moving in the embedded space.
So when you did that activity of implementing a marketing automation solution, you could have theoretically done a DIY HubSpot. Can you just randomly pick a number somewhere that says, "hey, for every hour that they did on the onboarding,it saved me this many hours of stumbling around in the dark myself"?
[00:07:00] - Raquel Gonzales
Wow. I cringe to even think of what it would have been like without their onboarding support. They took about three months, give or take, to get me to a point where we were super-efficient on the platform leveraging 80 percent of what we need to. And I think learning curve wise, that probably took another month after that. That's with their help. If I didn't have their onboarding guidance, I think I would have stumbled around for about six to eight months later. So it could have been even later.
[00:07:26] - Terry West
That's three or four to one easily, right?
[00:07:29] - Raquel Gonzales
And to me it was worth the investment. Having looked at the overall cost. If you consider the marketing team's salaries and you consider the time, the investment, it just makes sense.
[00:07:39] - Terry West
Right. And probably if you had not got that onboard package, you would have been calling them all the time asking them what the best way to do this would be the best way would be that would be.
This is where I want to pivot to the embedded space. I just did a seminar today for the Beningo group that talked about this whole platform transformation and how you able to do more. The goal here as software engineers in the embedded space, and certainly your experience in HubSpot Raquel, was you didn't want to build a custom implementation on HubSpot. You wanted them to take all the platform capabilities that they delivered, pre-customize it for you. And then you want to say I want to be a customizer not a custom developer of this tool. And quite frankly I love the fact that customizer has the word Mizer in it. OK. Because what you said was, "it was the cheapest, fastest, best way."
Now yes it cost you dollars. But the cost of your time to research all the APIs and all the ways that HubSpot, this incredibly powerful tool, could be used would've been a bigger investment. How would you know best known methods without googling forever, looking at people's histories, and case studies. I mean my gosh the amount of work to take a tool and capability, like HubSpot which is very complex, that has amazing capabilities and components (that are all very well documented) and somehow take those elements and put them together into a system that works for you and for your business needs. That's a big gap. Even though it's a great platform and that first onboarding program got you to the point where you could be a customizer at the very last mile and it was effective day one.
Now I want to pivot to this imbedded thing, because I think we're starting to see the same thing happen in the embedded space. If you think about the way that RTOs vendors, like our good buddies over at Segger, license RTOSs and stacks like, TCP IP stacks. These are very complex elements a TCP IP stack is a fairly complex beast; with thousands of lines of code. USB stacks are complex beasts. OS are wonderfully elegant and somewhat simple, but there still have a lot of APIs. Segger does a great job of documenting all of their APIs very very well.
However, the question is not documentation. In fact, I was on a call with a customer today; smart guy who was trying to build a new product by really rethinking about how he redid his platform approach. He said to me, "can you send me some documentation on your APIs. I thought it was an interesting question that kind of feeds into our conversation here. Because when he asked that question I said, I can absolutely send you some documentation our APIs. We were talking about our SCM318 platform coming up soon. It's a comms, control platform with enormous capabilities. It comes with all the Segger stacks and it's extensible. It's almost like an embedded single board computer with all the capabilities. And so, kind of like HubSpot, an incredibly powerful platform. In this case software plus hardware. All the APIs, especially all the Segger stuff, are very well documented.
Here's the difference. What's the gap between having a very well documented, safe set of APIs and having something that you can actually get functional, maintainable, to develop and deliver your app. Here's the challenge Raquel. I think what you just said which was "HubSpot is a great platform, but I have a instantiation of that platform ( a usage model for that application of how you want to use it, what it plugs into, something's you don't need, somethings you do need). So you paid HubSpot for the first three months to do a whole bunch of work for you to get it to the point where you could start with a fully functional thing and add to it. So you didn't have to learn about all the APIs, and how they fit together, and all that stuff. You could start with a 98 percent nearly fully functional platform and start customizing it around the edges for the first while. Then when you ran into bigger problems you could go back and say "can you help me with this."
And in the same way we've done that with our customers. One of the reasons I'm doing this podcast is because we're struggling, quite frankly, with some of our first engagements where we go into some of these customers. Maybe one you're one of them listening out here on the podcast. And we said to you "hey, we've got this great SCM318 or SCM318. It's got all this great Segger code, a lot of serious code. It's a hardware, software platform for creating embedded devices off the shelf." Great. And now we want to charge you an onboarding program. And you probably had the same reaction I had. "Wait a minute, I'm going to buy your products from you and you still want to charge me. Shouldn't you throw that in for free?"
And so we're actually going to our customers and we're saying, "as part of this engagement process, it would be best if you would invest up-front in some onboarding package to help you get through the front end of this process." And our estimate is that when we do that with customers, every hour we spend saves them about four hours of their time. I was like drill down. Why that's important.
And Raquel's conversation with me helps us understand that, I think. In that HubSpot knows HubSpot really well. They're kind of like the State Farm folks. They've seen it all right. HubSpot has seen it all. They've seen all the customers make all the mistakes and put it together the wrong way and then have to redo it. In that same way, we see how customers use OS and maybe do messaging wrong, or inter-process communication wrong, or don't construct how their data moves correctly. It kind of hurts when you watch customer stumble around like that, because you say "oh, man! iIf I could just help you construct your application and your architecture just for a little while up front it could make such a difference."
And so I really wanted this podcast to create this understanding and this baseline association between what we're seeing in the SaaS world and what we're now seeing happen in the embedded world. And I don't think we're alone. In that, we want you to use our products, but at the same time some of our products (like the communications control modules) we're really asking for a upfront onboarding package.
And I wanted to paint that relationship of what you saw Raquel on HubSpot and why that saved you so much time, money, and agony as a way of illustrating why this is happening in the embedded space as well.
I would be very interested for those of you who are out there Podcast world about any other examples in the embedded space kind of like Serious, and like HubSpot is in the SaaS space, where companies are selling their technology but also strongly recommending or even requiring an onboarding package at the beginning to help configure and set up the technology ready for you to use.
Absolutely fascinated in this topic. Leave a comment below, send me an email and give us some feedback on this podcast. I'll follow up with your comments.
The challenges of HMI and IoT can be overwhelming. Listen weekly to our Captain – Terry West, CEO – on industry trends he sees and implications for the embedded systems designer.
You'll find practical thought leadership conversations covering all facets of embedded technology, human machine interface evolution, architectural challenges, IoT readiness, and much more.