➡️ Summary ➡️

In this episode, Scott Covert interviews Adam Zuckerman from Omnitoria, discussing the development of their product, Declarative Webhooks, a no-code integration platform for Salesforce. Adam shares insights on transitioning from consulting to product development, the challenges faced in scaling a consulting business, and the importance of finding product-market fit. He also discusses the technical challenges encountered, the significance of integrations, and the strategies employed to attract users, including a freemium model. Adam emphasizes the need to focus on niche markets and offers advice for aspiring ISV founders.

➡️ Guest ➡️

Adam Zuckerman https://www.linkedin.com/in/adam-zuckerman/

Omnitoria https://omnitoria.io/

➡️ Takeaways ➡️

Omnitoria built a no-code integration platform for Salesforce.

The journey from consulting to product development is challenging but rewarding.

Customer validation is crucial in the early stages of product development.

Transitioning from consulting to product focus requires careful planning.

Scaling a consulting business presents unique challenges.

Finding product-market fit is essential for success.

Technical challenges can arise as the product scales.

Integrations are vital for customer satisfaction and retention.

Targeting the right audience can enhance product adoption.

A freemium model can lower barriers to entry and attract users.

➡️ Youtube ➡️

Watch this episode on our Youtube channel

➡️ Keywords ➡️

Salesforce, Omnitoria, Declarative Webhooks, Integration, SaaS, Consulting, Product Development, AppExchange, Freemium, Product Market Fit

➡️ Hashtags ➡️

#salesforce #isv #gtm #pmf #appexchange

Mentioned in this episode:

Sponsorships

Advertise on AppsemblyLine to elevate your brand and connect with a passionate community of leaders!

Sponsors

Simplify Your Salesforce Security Review

Get clear explanations, actionable insights, and step-by-step guidance to pass your review and get to market faster.

Security Review Partner

ISV Forge

Accelerate Your AppExchange Success!

ISV Forge

All right, so very excited today for another episode of Assembly Wine because I'm joined by Adam Zuckerman of Omnitoria. Welcome to the show, Adam.

Thank you for having me,

Yeah, so this is gonna be a good conversation. So Adam has been working in the Salesforce ecosystem for a very long time. He goes back to 2010. And we were just chatting about how we actually got a pretty similar background here. So Adam's run the gamut in terms of acting as an SI partner. Now, obviously with Omnitoria an ISV partner, he's even done a little bit of PDO work in the past. So I'm looking forward to

getting into the meat of the talk today. So.

Let's just jump right in. Tell us a little bit about Omnitoria, what you guys ⁓ have built, and how came up with the idea.

So Omnitoria has built a product called Declarative Webhooks. ⁓ Kind of as its name suggests, it's essentially a no-code ⁓ integration platform that's native to Salesforce. ⁓ It handles both outbound and inbound integrations. It includes things like more advanced features like logging, retry, callout sequence, sort of everything that you would expect from a fully functional integration platform.

That's great. so this is actually, I think that anyone who's built ⁓ on the platform integrations, which these days is pretty much everybody ⁓ understands like what a big important aspect this is. ⁓ I'm honestly sometimes surprised that Salesforce hasn't done more to support webhooks natively, but so many folks have built out, I think, ⁓ you know, an Apex class that supports ⁓

the RESTful protocol so that it can be called through an API and kind of a DIY webhook framework. So it's great to see what you guys are building because I think it's very needed. So, you did this come out of your consulting projects and there were folks that needed this and then eventually you realized it had generic ⁓ applications or did it just come to you in a stroke of inspiration?

No, I mean, it was definitely a lot of lessons learned on the consulting side. I mean, we probably built and completed, you know, hundreds of types of like Salesforce integration projects over the years. And, know, a lot of times, you know, there are like different, obviously like middleware tools that you can use to push and pull data out of Salesforce, but

A lot of times what we found is that kind of could get you like 90 % of the way to where you wanted to be. But then there'd be this like extra 10 % that was like non-negotiable. And whenever that happened, we obviously would have to resort to some custom Apex, at least back in the day. ⁓ And so we just got a lot of experience building custom integrations ⁓ using Apex. ⁓ Came up with sort of our own framework and design patterns ⁓ for doing that. Tried to make those. ⁓

Mm-hmm.

think those integrations that we built kind of as friendly to be able to change over time, you know, sometimes with like metadata mappings and different things. And at some point we were like, you know, there's no reason why this couldn't be a product, right? And that we couldn't like fully make this a point and click interface that any Salesforce admin could use to send and receive web hooks from Salesforce. So that was really the concept.

Cool. And just to give context to listeners, so where is, you've declared a weapon for that right now in terms of revenue size or customer count, things like that.

Yeah, I mean, have hundreds, certainly like many hundreds of active users, a combination of like paid on our paid and free tier. ⁓ You know, in terms of revenue size, I mean, obviously we're looking to grow our revenue. ⁓ But, you know, I would say we're still kind of in the beginning ⁓ phases of really launching ⁓ this or growing the paid side of our. ⁓

Mm-hmm.

So yeah, it's like super exciting. We've seen a lot of revenue growth over the last couple of years. And, ⁓ you know, as someone who's sort of transitioning from being on the consulting side to the product side, it's kind of been like a lot of incremental steady advances to kind of, you know, really grow this into a full, a full-fledged product. So it's, it's pretty exciting.

Yeah, okay, so kind of walking back to the early days. First off, I think I read that the declared webhooks first release was in 2021. Do have that timeline right? Okay, so rolling back the clock to 2021, maybe late 2020. Although nobody really wants to go back to 2020. But thinking back to those early days, did you build this out and kind of do some beta testing with the...

Yeah, that's about right.

Thank

consulting clients? How did you go about like validating before you, you know, now you have hundreds of customers back then. Was there anything you did to kind of make sure you were going to have product market fit?

Yeah, I mean, we kind of knew that there at least was like a solid concept here just because we had, you know, people had paid us money to build custom Apex around these use cases before. So if we could put a tool in their hands and save them money, then we knew that there was at least like some concept of product market fit. ⁓ But in direct answer to your question, ⁓ we had a client that agreed to be sort of like our first like beta testing users and they were like,

fully transparent with us. were like, you know, okay, we'll use it. can, you know, leverage it for this use case, but I'm like, we're making no commitments to like actually purchase anything and whatnot. I was just excited that they had agreed to like literally be the first install of our product in an org. And ⁓ yeah, it actually worked out ⁓ really great. And I think...

Mm-hmm.

They didn't become a paid customer for a while, but I think about six months later, they did become paid. They did become a, like a fully paid, customer. And that was kind of, I mean, that was gravy for me, but, ⁓ yeah, was, it was very exciting to just get it installed, see someone kind of using your application in the wild. And then, yeah, obviously converting them into a paid customer was, was cool too.

That's so cool. Are they still customers today?

⁓ kind of, of, the, the company is named, was named really. And, ⁓ unfortunately they, they did go out of business, but the, the, ⁓ the principle there actually moved to another company and they're now using our product. So in a way they, they're still using our product, but it's not, ⁓ in the same, in the same company, it's the same. Like end user person. ⁓ but that.

Yes. Well,

it's a nicer story maybe on the omnitorious side than for the really side, but still that's really cool. All right, so go ahead.

Yeah. I think the main thing is like you're

in service of, you know, you're in service of companies, but you're also in service of people. you know, if you do a, if you do a good job and they're happy with your product, you know, when they jump ship and, know, go somewhere, go somewhere else, they, remember you and, know, they bring you along for the ride. you know, that, that's a, know, if we're talking about like product market fit, that's probably a good, good indicator also that the, these guys are still, still using us, you know, four years later, almost five years later. So.

That's a really important point to make. I think a lot of people just stay focused on the logos, And thinking only about customers in terms of companies. ⁓ you know, people change jobs, ⁓ companies go out of business, and then people are forced to change jobs. So making those great impressions early on really goes a long way. And unfortunately, you know, making those bad impressions can haunt you, I think, later on.

So you mentioned the consulting business. ⁓ Is the consulting business then, was it propping up in the early days where you're getting the revenue engine going for the application or did you decide to fundraise?

No, we didn't decide to fundraise and definitely ⁓ having the consulting business was part of what allowed us to kind of build a team around, ⁓ you know, building out this product as something we were sort of doing ⁓ kind of on the size. ⁓ And then I guess like, in addition to that, ⁓ just, you in addition to just sort of having like the, you have your successful consulting team and you're able to sort of like port it over into. ⁓

developing a product. mean, obviously we had certain revenues that we could, in terms of getting maybe some initial marketing efforts going and some of that stuff. ⁓ So yeah, it was definitely helpful. And then ⁓ you also have your consulting clients, right? So each of those is an opportunity to kind of put your product in their hands ⁓ also. like I was mentioning earlier, like our first customer was a consulting client. ⁓ And yeah, and that kind of helped us build like that initial

credibility, think, because we were able to sell five or six of our consulting clients on our tool and then collect some success stories and then kind of go to market with some of those success stories that maybe if we hadn't had a consulting business would have been a little bit harder to find.

Sure. Yeah, think the transitioning from consulting to kind of the ISV route, like you said, it can, you can help get you some instant customers. But I also think that it can be challenging sometimes, uh, you know, because focus is so important and you know, you've got this revenue engine that's up and humming with the consulting firm. And now you're thinking about taking away time and dollars from that and investing into an application that you're not even sure it's going to work.

⁓ And you're trying to sell, even though your consulting customers could be potential new clients, they might have their own initiatives that they'd rather you focus on. And so I'm sure in the early days, you sort of feel like you're cutting off your nose despite your face ⁓ by pulling maybe some developers ⁓ and consultants off of active projects to focus on the Declared Webhooks app. Was that a challenge for you guys at all in the early days?

Yeah, for sure. mean, you're definitely, ⁓ I mean, speaking particularly for myself, I mean, you're stealing, you know, time late at night and, ⁓ there's a lot of pressures in the consulting business to like turn stuff, you know, turn stuff around very quickly and, you know, meet, meet different deadlines and, you know, clients are, demanding. one of the things that I've often said on the consulting side is like, ⁓ demand for my time is like,

Fundamentally like elastic but my time is not elastic like I have a finite amount of time in the day So like I might have one day where it's like, okay today's not so bad and then the next day, know I'm getting hit from 13 different angles that I had no idea like I Couldn't have I couldn't have planned for those those things and those clients to reach out to me on that particular day And then I'm completely completely buried. So you're just it's definitely like a struggle to sort of find the time and also

You know, in the consulting business, there's sort of like a quantifiable understanding of like, this is what, this is what an hour of my time is worth. Right. So, so any time that you dedicate to other things, like, I mean, the one way to look at that or, you know, other resources on your team, is kind of a law is sort of a loss to the top line of the business in some sense. And even if you're sort of more favorably disposed to view it, and this is the way that I actually view it as more of an investment of your time, it's, it's, it's a speculative investment. Like you don't know.

you know, is this going to be the thing that just sort of like blows up and, we're, all going to be, you know, making millions or tens of millions of dollars, or is this just going to be a waste, a waste of time? And, know, people aren't really going to, you know.

really aren't really going to vibe my product, right? Or maybe even if they vibe it, maybe they won't buy it, right? They won't pay for it. So yeah, that's definitely like a risk and the concern, but on the positive side, you also have a much more scalable business. in the same way that my time is not elastic, right? With a product business, right? You can essentially build the product once and sell it, you know, an infinite amount of time for no additional marginal costs other than, you know, maybe like, we have to have people who can respond to support tickets and that type of thing.

Mm-hmm.

⁓ It's a type of business that just scales fundamentally, any SaaS business really, that just scales so much fundamentally better if you actually have a product that the market wants.

Sure. Yeah, I think I heard once someone say the problem with consulting is I don't scale, which is exactly what you were saying. And you mentioned getting bombarded by requests some days, ⁓ having light days other days. But you always get bombarded late on a Friday afternoon, Or like right when you're about to take a holiday. That's always the way it seems to go.

You

Yeah,

definitely in the early days of consulting, when we had like a much smaller team, when we had a much smaller team, it felt like, you, there were no vacations. I mean, there were vacations, but like there were no vacations, not really, you know.

Right.

because you had clients and they had needs and they trust you and you want to meet those needs and you're sort of like under the presumption as a consultant that if you're not highly responsive to your client, then another consultant behind you will give them that level of care. So there's this constant sense of kind of having to sort of prove yourself and justify your value. And I've always kind of liked that, to be honest, like that feeling of like, yeah, I'm... ⁓

like in a new consulting gig and I have to prove myself in the same way you have to prove yourself in a new job, let's say, but you have to do that, you know, once every few years or five years or whatever. But as a consultant, you have to do that, you know, dozens of times, you know, ⁓ per per year. And that to me is like, very, can be like very exciting and, fun. ⁓ but it's also like very taxing and, and tiring and.

Any.

There comes a point where it's like, you look, just don't, I don't, I don't have enough hours in the day. don't have more time. And, you know, yes, I can hire people and I can try to scale that way. But then even still your, your, the, the scaling laws are linear to the number of people that you can hire and train and who can do a good job and, and your ability to effectively manage those people. ⁓ and so yeah, that it's, it, becomes a challenge to skip, like, at least I found it to be a challenge to scale the consulting business, like past a certain, ⁓

unless I didn't really want to be a Salesforce developer, architect or consultant anymore, I wanted to be like a people manager. just knowing myself, that's not my talent. I'm very good at building things on the Salesforce platform. I'm not necessarily like an exceptional people manager.

by any stretch of the imagination, nor do I really want to be. So then it sort of begs the question, like, why are you in the consulting business then? Because at some point, that's what you have to be. Unless you're happy with a small team or something, and that's your only ambition, which is fine.

Sure. Yeah. Yeah. mean,

Yeah, yeah, like you said, can with consulting, you can grow, of course, you can hire more people, but I have yet to meet someone who found more than 24 hours in their day. So you still end up hitting the scale problem, right? Okay, so you had some some you had your first customer use it and after six months or so, but they actually did become a paying customer. You had some some usage from other consulting clients, it sounds like.

No doubt.

Do you recall how long it took to get that first customer, that first unknown customer, know, that first logo that was net new to the organization. You never even interacted with them for consulting.

Yeah, I don't remember exactly how long, but it was definitely within like a couple of months of, you know, like maybe, yeah, maybe two, it could have been, you know, one to three, somewhere between the range of like one to three months. Definitely before that customer became a paying customer, we acquired like our first like organic customer, ⁓ from the app exchange. ⁓ and it was.

Amen.

pretty exciting because they were like a large real estate development company, I think in like Dubai or somewhere in the Middle East. Somewhere that we were like meeting in the middle of the night about our product and their use case. Literally like at midnight my time or 1 a.m. my time to sort of go over what they needed. Yeah, and that was super, I remember that just being like tremendously exciting opportunity.

Mm-hmm.

I figured it would be. That's a very exciting time. Especially that use case. All of a sudden you go from no customers, your first one is in a different country. You go global overnight. That's cool.

Yeah, exactly. And it wasn't like a, it wasn't just like another little tiny company. was like a really, like a really significant, ⁓ like a very large real estate developer in the middle, in the Middle East. So, ⁓ that was pretty, ⁓ pretty cool. And, know, like I said, very exciting. And, ⁓ I think it was part of, cause I was mentioning before that, you know, that you can sell things to, to your consulting.

You know, you're consulting customers, but that doesn't necessarily like truly validate your product. think much more so than that, when you get that validation that someone who didn't know you before that kind of comes to you as like a product and as you know, the list of features that someone can glean from the app exchange or like, okay, like I want that. I think that.

for me was like much stronger validation that we at least had like some degree of like product market fit than my ability to sell a product to people who already trust me as a consultant and who know who I am and who've worked successfully for many years. then if you're, if they hear that, you have a product that can solve my use case. They're like, they're all about it, right? They're happy to use it, but it doesn't really necessarily, it doesn't necessarily represent the market at large, I guess is my point.

Yeah.

Sure, yes.

I have spoken to other founders that started out transitioning from consulting to ISV and felt the same way that they had a request from a client, ⁓ which can be great because then you can get paid to build out your MVP, but that can lead to a false sense of product market fit or like you get a false sense of security that you already have validation when really you haven't hit the market at large yet.

Yeah, for sure. And then, you know, also too, like in the back of your mind, and this is kind of like among the kind of interesting incentives that sometimes exist in consulting, like in the back of your mind, you're like, I'm selling a product where I could sell someone like, you know, maybe custom apex development. So I'm maybe accepting a, you know, I'm generally ⁓ accepting less money on a subscription, you know, product.

Hmm.

than I would on selling custom development time for the same use case. And I could just as easily have pushed them to one as the other. of course, as an ethical consultant, you always want to push someone to do the thing that makes the most amount of sense, right? That's the most scalable and maintainable and those types of solutions. But you have to give them some type of like,

value prop right in the in the product that you're selling them. So it does kind of maybe cannibalize at least like early on some of that, you know, potential like consulting revenue.

Yeah, that goes back to what we talking about, right? We're feeling like you're cutting off your nose and spitting your face a little bit because that's great point. If you're building out a product that could be consulting engagement, those early customers, you're taking a haircut on and you're not really sure that that's going to be worth it in the long run.

Yeah.

Right. But, you're very excited to like, want to get my product in somebody's hands, right? We were very motivated to be like, yeah, I don't, I don't care. Right. Like, yeah, I could sell a $10,000 consulting engagement or $15,000 consulting engagement. And instead I'm to sell, you know, a SaaS product for, you know, $2,400, you know, for the year. And maybe even I'm going to offer to implement it for free. Cause I just want someone using my product. Right. So, ⁓ but you know, I think these are all, you know, you, you do also though, like learn a lot from implementing your product.

Right.

to a use case too. it's like, you install products. So we were getting some like learnings out of it, but yeah, from a revenue standpoint, wasn't necessarily like the best, to convert consulting business to product business isn't always the best financial decision.

Do you have any ⁓ memories, ⁓ maybe some painful learning experiences you went through in the early days, like hitting some bugs, things like that when you were implementing early on?

gosh, I mean, I just remember it like, was always sort of a race to kind of continue to add features. I, I think, not so much like bugs, but like we would hit roadblocks of, of, you know, discovering things that we couldn't do with our own product that we felt like, okay, like,

We have to be able to do, we have to be able to do, ⁓ do that thing. And then also like a lot of like incremental advances, like for example, when we first started, ⁓ we only, we, we launched only supporting like the outbound use case only. ⁓ like we knew like we were going to, we, we, we were going to have to support the inbound use case because a lot of integration projects, ⁓ not only involve like sending data from Salesforce, but also like reacting to data from an external platform also. So it was kind of like racing to kind of add.

Mm-hmm. Mm-hmm.

⁓ find these use cases and then continually adding features and improving our product. I mean, yeah, like anything, ⁓ we have had issues where suddenly a bug has cropped up in our platform. ⁓ Probably one of the most memorable one was that, so a portion of our inbound webhook service is actually hosted in Heroku.

And we were having an issue where the Heroku server would just like suddenly like restart and like mess a bunch of things up. ⁓ and so we had to figure out like solutions, around that so that, you know, we had like good backups and, ⁓ and stuff like that. Cause it's, it's much different when you're like serving, let's say, you know,

Mm-hmm.

Yeah.

a few thousand web hooks across a handful of people versus I think today, we're certainly in the tens of millions or hundreds of millions of web hooks per month that get sent through declarative web hooks. a lot of ⁓ that, like anything outbound happens native in the Salesforce org, but anything inbound kind of traverses a little bit of our infrastructure.

Yeah, just having support and scaling that out and then, you know, hitting some roadblocks around the, you know, along the way as things scale and you realize like, okay, we don't have enough, we don't really have enough infrastructure to support this, you know, and, and, we have to have fast solutions, ⁓ to these things that we don't bring our customers.

Yeah.

Well, especially with something as sacred as integrations, right? I mean, you can get, a lot of people can love and hate you really fast, I feel like, when that thing goes down. So can imagine that being a little bit scary when your Heroku server, or I think they call them dinos, right? Would go down and need to be restarted or whatever.

Yeah, exactly. then, know, Salesforce has also ⁓ made some changes to like the guest site user over the years. like, ⁓ that's one of the reasons why we decided to stand up our own, like Heroku server, you know, our Heroku dino anyway, because there were so many limitations to the guest site user. like Salesforce would, could restrict some of the permissions to the guest site user. And then all of sudden, like,

⁓ a certain type of action that was working just fine all of sudden breaks, right? Because the security on the guest site user is sort of hobbled in some way. So. ⁓

Mm-hmm.

Yeah, I mean, you have to react to Salesforce platform changes, customer usage patterns and changes over time as you scale. And yeah, there's definitely a lot of things. of course there are sorts of little bugs that of like crop up and we try to fix those sort of as quickly as possible. Most of those have been pretty minor over the years.

Sure.

Yeah, so you know, I love your application because like I said earlier, think everybody ends up needing to build this or has built this at some point. And I also think that it can be a great learning point for a lot of ISVs out there that are building in a space a little close to the native platform features. so...

I'm going to play devil's advocate for a minute, right? And think about maybe some early days, some possible pushback that you guys could be getting. ⁓ know, there were obviously, you know, the platform has evolved since then, but there's outbound messaging from workflow rules. There is technically the possibility to roll your own ⁓ receiving endpoint with a REST ⁓ enabled APEX class. I know that webhooks involve so much, you know, there's

We're set.

You mentioned some of the features earlier. know, bet some of these came out over time. You mentioned the iterative development. would imagine retries is something you probably didn't have in v1, but you realize, this is important because sometimes the other guy's server goes down, and we've got to be able to handle that, right? But just going back to my point, was this a problem to, did you have to convince folks that, look, yeah, some of this you can DIY if you want with Salesforce, but you're not going to really get what you need?

unless you have a full-fledged platform and solution like ours.

Yeah. So I mean, like in terms of like the soap outbound messages, right? So like all of that's in, in XML, it's kind of was sort of two and older, at least at the time when we released, um, was to sort of a, a pretty old like integration standard. Um, it's sort of, it's sort of like fire. It's it's fire and forget, right? So you don't, you don't really know like what happened, how it was processed, you know, um, that type of thing. So it, kind of like,

Just putting it nicely.

You could get something to work with outbound messages, but it was pretty, pretty limited and not that, not that easy to use. I mean, it was easy to configure from the Salesforce standpoint, but it pushed a lot of the work outside of Salesforce for whoever was receiving the outbound message and then doing something with it. So it doesn't really like keep you in the Salesforce platform. It doesn't keep the, like the Salesforce team actually like doing a lot of the work themselves ⁓ in terms of like.

Sure.

like inbound, you know, just like, you know, creating your own like rest resource and, and, and all that stuff. I think in terms of that, ⁓ it's not really, you know, of course you could do it. Like it's, it would be like the standard way to do it on a kind of a custom basis ⁓ with Apex, but, ⁓ you know, it's all code, right? So it's not fundamentally fundamentally maintainable. If you have to add actions, if web, if the,

if there's an API update and the webhooks change, you're now having somebody who knows Apex to be able to modify it and change it. So in no way is it no code or maintainable with purely clips by an admin. So yes, you could do it, but it's hard. And maybe for very basic webhooks, someone could sort of roll their own, even if they're not super sophisticated with Apex. But for things that are a little bit more complicated or require like,

more complex processing of some kind. It's like all of sudden, you're really turning this into a very heavy code challenge. And ⁓ it's just not the smartest way to go if you want to build a maintainable integration, I think is the idea. And actually where we've been getting more, where we got kind of... ⁓

pressure later on was more from HTTP call out in flow, which kind of came along, came along later. Cause like, I think I mentioned before that our first use case was basically the outbound use case. And like, that's what we worked with. And at the time there was no ability to do that, like natively in Salesforce at all. ⁓ And then Salesforce came along and, actually did it, ⁓ did it. ⁓ And so

in.

That kind of forced us to think about, where are the real value adds in the outbound use case? And in terms of that, it's like retry, logging, ⁓ more complicated authentication, kind of delivering on more enterprise integration features. ⁓ And then on the...

On the other side, it's like, well, there's no real support for inbound webhooks at all. So let's double, let's double down on like the, inbound use case. So it's kind of interesting that our product kind of started really like focused on outbound. And then I think at this point, it's, it's pivoted a little bit where like, think outbound is our inbound is our strongest, ⁓ our strongest use case or more, maybe not as strong, but our most like differentiated, ⁓ differentiated. And then of course, if you want to keep like a consolidate, you know, if you want to build like a full like.

integration solution, right? It's not just one way. Like you can't just be like, okay. ⁓ I mean you could, but you wouldn't necessarily want to say like, I want to send my call-outs from HTTP call out and flow, but then I want to react to some, you know, ⁓ you know, an invoice paid event in QuickBooks, through declarative web hooks. doesn't, it doesn't really make sense to keep those kind of separated, right? You kind of want one, one solution that does everything. So I think we have like certain advantages of being able to handle like both, you know, both use cases. ⁓

Mm-hmm.

Sure, yeah, no, that makes total sense. And it's interesting that I was just curious if that was like ⁓ a common pitch you had to make or you had to often differentiate yourself from the native tools. It makes sense though that before the advent of HD piccolas from Flow, people were more on board with the outbound value and then over time it switched to be more about the inbound. ⁓ That's interesting.

Yeah.

So we've had to, I guess the point is really

we have to answer that. ⁓ I hear more about that now and having to answer that objection now as opposed to in the early days when it was just like, know, soap outbound messages ⁓ or we could like roll some Apex to do it. you know, we weren't hearing very much of that at that time. So, and probably more commonly we'd hear stuff about like.

⁓ can't we use Zapier for this or Workado or blah, and kind of competing as those other tools that are out there. ⁓

Hmm.

So, you often, you know, would you say that the Salesforce admin is basically your end user ⁓ or consultants or developers or maybe a combo?

I would say, I would say it's a combo. ⁓ mean, you have to under, so in order to use our tools, like you have to understand what integrations are and kind of how they work. So if you're sort of approaching it as sort of a, maybe like a newer Salesforce admin who isn't really familiar with like, I don't know what an HTTP request is and I don't know what Jason is and I don't know what web hooks are. Right. ⁓ Not that that person can't figure it out, but there's going to be like a, there would be like a little bit of a learning curve, but a more advanced admin.

Mm-hmm.

Or someone who was like a consultant who understood like just basic, ⁓ like integration design patterns would like instantly kind of like get and grasp our tools. So would say that that's sort of like our ICP is like someone who sort of like maybe just.

a little bit along their journey, who's done some cross-platform stuff and understands maybe basic mechanics of integration, but then understands the benefits of, ⁓ we don't actually want to build this thing with code. We could, I might know how, or I might have developers on my team who could do it if I asked them to do it, but that's not the right way to do it. ⁓

Yeah.

Yeah.

So, ⁓ and in terms of like developers, I think there's like a good use case for using our app, even if you are a Salesforce developer, because we can handle like the configuration of the web hook itself. And then we actually have like a lot of apex hooks. you can like, yeah, you can, you can, you know, invoke.

cool.

⁓ a declarative, ⁓ or like send a request that's configured in declarative web hooks from apex, which I think is pretty cool. You can actually extend, ⁓ some of the mappings and the transformations, ⁓ through apex. we have like a lot of cool hooks for developers to be able to use, but who still want to have like a good portion of their integration work be like configurable. ⁓ but I think there is, you have to sort of overcome the developer's mind who, like, who can actually build the thing fully in apex that that's.

Mm-hmm.

value add so it's a little bit of a case that you have to make but I think it's a case that we we can make. ⁓ So yeah it's definitely definitely a combo.

Yeah, that makes sense. And it's nice. I'm sure it's nice to not have to educate the client if they were like newer to the platform or newer to integrations in general. It's better to work with someone who's a little further along, like you said, that would already understand some of the basic concepts in the alphabet soup of integration work.

Yeah.

One of my favorite, I wasn't necessarily expecting this in the very beginning, but I feel like a great sense of accomplishment when someone has installed our product from the app exchange. And then they, we have certain feature parameters, which allow us to see like the usage in our application and sort of like what stage people get to in the application. And like, without talking to us, you know, if they can get something working and I can start to see like usage coming through.

you know, with their integration without ever having talked to us. Like that to me is like the best compliment in the world. And a lot of times, like we literally had people who they weren't even responding to like follow up emails, like, Hey, I saw that you installed our product, blah, blah, you know, left on red, you know, two or three emails. ⁓ and then like a month later, their trial expires and be like, you know, we really need to buy that thing. And, know, they basically not exactly like a traditional sales process where you're like constantly hounding someone, trying to get someone on the phone, but it's like, they just.

installed your product, got it working, and then decided basically on their own accord to pay for it without ever like really having to sell anybody on anything. Um, it's happened enough times that I'm like, I mean, that's, that's part of why I think we have like a reasonable amount of product market fit is cause we we've had so many people sort of go through that process without ever having talked, you know, spoken to, to us and, um, and just boom, they're, they're a customer basically.

Sure.

Yeah.

Well, that's one thing I think that's nice about your tech stack, right? Is that you have, mentioned you have the middleware running on the Heroku platform. So then you're able to see some more usage. There's, you know, folks can build out some, a usage framework kind of using like feature parameters, but it's not as nice. You know, there are a lot more tools out there if you're running something on Heroku. And I wanted to ask a little bit about that. So.

⁓ Was the decision to run on Heroku versus building the metalware out on ⁓ like Lambda or some other serverless framework, ⁓ was that intentional because Salesforce owns the Heroku platform or can you take us back to the decision process thing?

Yeah, I mean, I think it's just, it's probably, I mean, we definitely could have looked at other things, ⁓ just over the years, like working as a, like a Salesforce SI and being involved in a bunch of sales cycles with like Salesforce account executives where they're maybe trying to sell, sell Heroku to the end customer. And that's kind of like the tool that you have. We just had a lot of familiarity with Heroku. And then I think as a general proposition, like aligning with Salesforce as much as you, as much as you can, ⁓

I think is also just generally a good thing to do ⁓ as a Salesforce partner. So we kind of want to just like stay in the Salesforce world and the Salesforce ecosystem in some way and not try to pull out of it. And just to clarify the Heroku, so Heroku just governs the inbound use cases, not the outbound use cases.

Gotcha,

okay.

Well, and the main, the main, honestly, the main reason we probably wouldn't have even done that. You have the ability actually to bypass Heroku entirely and not, not use it. ⁓ but, ⁓ it requires you to either get, ⁓ our application working on a force.com site, which takes a little bit of configure, which takes a little bit of configuration and then limits you to the guest site user, which kind of limits some of the functionality and things that you can do for, because of, you know, some of the ways that Salesforce has locked down the Salesforce guest site user.

Um, then yeah, outbound happens like totally like that's really a 100 % native to Salesforce and all of that usage. We, do kind of have feature parameters that kind of count, like how many calls has people made, you know, did they, you know, how many tests have they made? Um, and that type of thing. And we use that to kind of build our understanding of who's using our product and you know, who maybe just installed it and then forgot about it basically.

Yeah, that's so cool. even even stuff is just even though you mentioned it's just something about not about it's a nice story. I've always heard that when you're building on the Salesforce platform, it's better to have a narrative of like better together. Right. And then so that you don't want to build you don't want to build something that competes with an add on that Salesforce has built because you're not going to get much love from the A's and the SC's that way. But it sounds like as

declarative webhooks grows, so would naturally your usage of your own Heroku instance and therefore Salesforce, obviously they're getting the rev share from your product, but also everyone's just kind of winning together. I feel like that would be a good use case.

Yeah, for sure. And then that also has been kind of like one of the challenges to the product too, is because you do have like, know, a Salesforce AE that might be waiting in the wings to sell like a juicy MuleSoft, you know, something like that. And what we've always felt is that we kind of fit in like a nice middle ground between like, maybe like a Zapier or something like that on the low end and kind of maybe a more of an ESP style tool like MuleSoft on the high end, that there's sort of this like middle range.

Mmm.

And so when we are in discussions with like Salesforce AEs about our product and its positioning, ⁓ and. You know, there's sometimes when they might be trying to sell a deal and integrations are like a not a complete, like non-negotiable, like I need my Salesforce platform to like integrate with these three other tools. And then they come in real soft and then the customer gets sticker shock. Like that AE has to know like, okay, well, what, what else, how else can we solve this use case?

Mm-hmm.

And still like at least get this person like on the platform. Right. And I think that's how we kind of position our tools. Like, yeah, you could sell MuleSoft, but then, you know, you, you might just like sticker shock the customer and then they might bounce for HubSpot or something like that. ⁓ So we definitely have tried to like build those like win-win relationships with Salesforce AEs where like, we don't try to like necessarily like compete against the MuleSofts of the world.

Right. We try to kind of find like a nice, a nice lane and a nice gap so that our app is kind of at least in the mix of, of conversations and can like maybe save a deal that the Salesforce AE would, you know, otherwise lose. So that's kind how we.

Sure,

sure, that makes sense. And would you say that ⁓ a number of your deals ⁓ are coming through Salesforce AEs or through the Salesforce team? Has that been a good lead gen source for you or is it still mostly organically grown by you and your team?

I would say it's ⁓ mostly organically grown. So I would say our biggest lead source is definitely ⁓ like the app, probably the app exchange itself ⁓ is good, is a very good lead source for us. Obviously our consulting business kind of does, does sell our products. So that's a, that's a decent, a decent kind of lead source in some sense for us. And then ⁓ yeah, I would say that the, Salesforce AE is like educating ⁓

Mm-hmm.

You know, the, some Salesforce AEs, hasn't been like a big channel, but it does, ⁓ it does happen ⁓ with some, with some frequency. And I think it's good. You you want to educate Salesforce and you know, they're solution engineers and their accounting executives on, on your product. And, know, you never know ⁓ when that comes in handy. I would say like our consulting business is much more tied to the Salesforce AEs than our, than our product business is, but ⁓ yeah, they, throw us, you know, a bone here and there from time to time also.

Sure. Yeah. Okay. I want to ask you a couple of questions about some possible headwinds that perhaps you all have faced. And I think, because I think it could be valuable to some listeners. So your end user is often like we talked about, ⁓ admins, consultants, developers. But the and declared webhooks are extremely important. I mean, integrations are just like you said, they're in that one, that one deal you're talking about, like

there are some must from the customer standpoint when they're working with Salesforce. But even still, it's not an application that ⁓ makes the necessarily directly makes the sales rep more, ⁓ bring in more dollars and things like that. my point is that your end user, I'm guessing is not necessarily your buyer. A lot of Salesforce admins themselves don't have budget.

or the Salesforce developers don't have the budget, they're needing to get approval from someone else, their manager or their manager's manager. Could you walk through, has that been a challenge for you that your end user is not necessarily your buyer or would you, ⁓ how did you navigate that?

You know, it's a good question because I like, I think the closer you can get to sort of like the revenue generation engine, like ⁓ of a company, I feel like the easier it is to make like very big claims about the impact of your product. you know, it's, you know, companies who use our product experience, you know, 10 X growth in their revenue or something ridiculous like that. Like I think as a, kind of a tool or more of a utility on the Salesforce platform.

Like we can't make those kind of like really big, monstrous claims. Like we can make claims that like, Hey, if you install our product and you build integrations with it, you know, you're going to be able to implement your integrations, you know, in, you know,

I don't know, 30 % of the time and half the cost or whatever the case may be. ⁓ It's more of a productivity enhancer from the perspective of the Salesforce team and also ⁓ more of a reduction of costs. So there's definitely ⁓ some limits in terms of what kind of dramatic claims we can make to the market, if that makes sense. ⁓ But to be honest, ⁓ I think a lot of...

the users of our product, especially like the organic ones, like they tend to be part of like, maybe like in at large organizations, but part of like small scrappy, you know, Salesforce teams where it's like, you know, the director of, know, it's, like a, technical kind of director of revenue ops who's like, he, know, he technically like controls the budget, but he's also like doing a lot of things like on the sales on the Salesforce platform. So

Hmm.

I don't think we've gotten much pushback where it's like the end user themselves is having like trouble like allocating budget or ⁓ making the case, but it is true that we're not necessarily like. ⁓

talking to, we're not often talking to like the CEO or the CFO, like if the, of a company and like making a sales pitch directly to them, it's sort of more at the, maybe like the director of rev ops level, you know? ⁓ And I think that probably does, like it would be better in some ways if we could make that like more of a, of a, of a sexy business case, if you will, to like the CEO of a company or something like that, you know? Because

Yeah, well, mean,

Cause they won't necessarily

you're powering...

understand our, they want to hear like the business side of it and they might not get the tool as well. I think as to your point, like a Salesforce admin would get our tool or Salesforce consultant would get our tool.

Sure, sure. I mean, I can understand that. You're essentially providing the electrical outlet that everybody needs to get anything working. You got to be able to integrate with this third-party platform that you love so much, right? ⁓ But sometimes ⁓ it can be a little bit more challenging to convince the ⁓ buyer of ⁓ that. when you're not so close to the revenue engine like you were saying, that you can point to this, this is the impact.

even though it's absolutely necessary to get that impact from that other tool to be able to hook it up.

But it has also been like, as we're considering like building other things and other products, it's, one of the things that I've thought about more as like developing a tool that's more geared towards like a, like a very like maybe like an industry, an industry vertical or something along that, that can kind of bring people more to the Salesforce platform where I could make, where you could make a much stronger case to Salesforce AEs about why they want to loop you into a deal, right? Because maybe it's not something that Salesforce, you know,

⁓ natively supports and you're basically helping, you're giving people like an on-ramp onto the platform itself. Like that's something that a Salesforce AE would be much more interested in paying attention to, you know, certainly like within specific industry verticals. And then also where you're dealing with more like specific, like business leaders, you're able to like more directly like engage and sell them and kind of get their, get their intention, you know, their attention directly, you know, by making

Yes.

more of a business case, I guess.

No, that makes total sense. that's actually, it's funny because that's exactly what my next question was. I was curious if this has been an headwind for you guys that you're such an important, vital, horizontal product that everybody needs. sometimes that I know that can be a challenging challenge on the marketing side ⁓ because you're not hyper focused on one particular vertical or one particular industry.

And so then it can be difficult to land your messaging sometimes with your your ICP has that been a challenge for you guys or have you have you found a niche that For whatever reason even though you could work in any industry, you know This particular industry seems to really prefer using declarative webhooks

Yeah, I mean, one of the, one of the, ⁓ one of the areas has kind of surprised me. And there's definitely like a, a decent cluster is, ⁓ like solar solar companies and like solar contractors. there's a lot them because it's a very, it turns out it's a very like integration, like heavy space because there's all these different tools. Like there's, ⁓ like APIs, which tell you like how much energy usage like a home has. And then there's, ⁓ different parts of a solar system where like, ⁓ you can like,

Okay.

they have API endpoints that you can interact with that gives that solar contractor intelligence about ⁓ maybe their existing customer base and other products that they could sell them. ⁓ Or also just sizing a solar system on behalf of a customer. I don't ⁓ know, making them, can you print out your utility bills or email your utility bills? They can just plug directly into their utility and pull that data and then start building their, ⁓ or right sizing the.

the solar install that's necessary for those customers. So we have found like a little bit of a niche there in different areas. We're constantly kind of looking for those. Like what are the opportunities like even within an integration where it's like, you know, good luck finding a zap for integrating with, you know, PG &E or something like that. you're not going to find it. So that kind of gives you like a little bit of a gait and a little bit of a moat. And then you kind of flex that muscle and build that expertise and

Mm-hmm.

you find yourself ⁓ in a pretty strong position because then the next person who comes along is like, yeah, we've done this like five times. And here's how you do it. And here's the services. And we've got templates that you can just plug and play and go for it. ⁓ But yeah, you have to be on the lookout for those opportunities. And in the case of the solar one, it was very organic. We didn't necessarily go looking for it. It sort of got us, and then we've sort of...

and

Mm-hmm.

you know, try to take as much advantage of that as we can.

You just started seeing a lot of traffic on AppExchange from those types of customers you realized this might be a vertical you should double down on.

Yeah, and then you see a

few of the same tools and the same that they keep using over and over again. So you realize, hey, this is a good little, like a rich little niche that we can kind of leverage and use. ⁓ Yeah, think it's definitely, I would say it's definitely important. In the early days, I didn't really understand this idea.

Thank

Mm-hmm.

of like, we have to focus on a niche because it's like our product can do anything. Right. And that's like the temptation is especially someone like me, who's maybe like a little bit more technical. It's like, want to, I want to focus on solving as many things as I can. don't want to like limit myself, but it's much harder when you go to market with a product that's completely, you know, you know, it's like, we can do anything is not ⁓ a marketable message really, you know. Yeah.

No, in fact, oftentimes it's a negative rather than

a positive. Even though, even though I've talked with folks on the show before how developers building on the platform, building managed packages, it's like ingrained in us to look out for any landmines that would ⁓ handcuff us to a particular feature or a particular product on the platform. Because we want to make sure that anyone and everyone can install the app.

and then sometimes that translates into the marketing, but that's where it kind of falls flat. Technically it's great to work anywhere and everywhere, but when it to positioning, it oftentimes helps to have a really, really niche focus.

Yeah. And I think we've sort of found similar things like in the financial services industry too. There's a lot of like very complicated tools ⁓ and just being able to serve those tools and say like, Hey, we can integrate with them. ⁓ And especially ones that tend to be like more like proprietary, they don't necessarily even like publish a public API, but you've done enough integrations of them that like

you have everything ready to go for someone to get started on them. So yeah, just really looking for those opportunities. But I think we have done it very organically. We wanted to see what do people need and what do people want. And then we've tried to double down on just the things that we see.

Yeah.

⁓ as they've developed organically, ⁓ I don't know that's the best way to do it. Like maybe we could have benefited, ⁓ earlier on from being like, trying to sort of laser focus on, you know, on a niche, but by the same token, you know, how sure are you that you're right? You're right about that. So it's kind of nice to also just kind of let's, let's sort of see, let's collect some data and some information and see what the market is actually telling us it's interested in.

Sure. Well, speaking of the market telling you about its interest, I also wanted to ask you a little bit about your pricing. So you have a freemium usage-based model, ⁓ right, that I saw on the AppExchange. Is that what you launched with? Is that a model you grew into? ⁓ Did your pricing change at all over time?

Yeah, originally, ⁓ let's see, originally we started off with just like basic tiers, kind of like a, you know, a basic ⁓ kind of a middle tier and a premium tier. ⁓ And that was all based upon like, mostly like an annual, you know, an annual or monthly amount with certain usage limits. ⁓ I think what we thought over time was, especially on the lowest tier, that that was creating a little bit of a

barrier in terms of getting people like into our, into our product. So we wanted to kind of lower that barrier as much as possible. So the first thing that we did was, ⁓ we, we tried to create like a, lowest tier where it's like a monthly, a small monthly amount with like rel a relatively high usage charge. Basically the idea of being, we're trying to like, get people into the product as cheaply as possible. If they don't need to use our product for that many calls, then it ends up being like a very like.

Okay.

inexpensive tool, but it also creates some pressure to kind of graduate them to the higher, to the higher tiers. That was kind of like our pricing strategy. Um, and when actually, when Salesforce released HTTP call it and flow, we realized that, all right, like that's kind of going to take a little of the steam out. So we have to give, we really should just give away like some of our product for free, right? So that people can get into our product and can use it on, on some level, um, and decide that it's actually like the better tool, the better tool, um, for them. we, we, we launched the freemium.

Okay.

later. And then, yeah, I think that's sort of been the evolution as we started off with like basically just three tiers with certain usage caps, we created a usage tier and then we and then later we added the freemium because, you know, we just want people using our tool. And we were actually finding it wasn't enough. Like we give people like an unlimited, basically unlimited sandbox trials, like you can use our product in sandbox for as long as you want. ⁓ We don't

Mm-hmm.

We want people to get into our product and love our product and use our product. ⁓ And we think the best way to do that is for people to build whatever they want in a sandbox first, make sure that we're the right tool for them. ⁓ But I don't think that that was resonating enough with the market. And I think it definitely did help us to give like...

a freemium version of our product for a way for free. And of course you sort of get that indicator on the Salesforce app exchange itself, which is kind of allows people kind of, think draws people in a little bit to, the possibility of just at least playing with your product, you know.

Sure, I'm a big fan of the freemium ⁓ model. There are some ⁓ folks ⁓ working in the B2B space that don't love freemium because they say, well, you end up having your paid clients ⁓ need to subsidize those free users. But that's in general B2B SaaS ⁓ companies. Whereas when you're a partner on Salesforce, one thing that's nice, I mean, know you all have the Heroku instance, but first of all, you mentioned that it's

if you really wanted they could bypass it, but also that's only inbound. ⁓ With the freemium model in Salesforce, mean, everything is running on Salesforce infrastructure. So that whole kind of downside of freemium sort of falls by the wayside because you're no longer having to subsidize for the free users. The free users are just running on the same CPU that they would have before with their Salesforce org.

Yeah, exactly.

Yeah, there's no, there's no like infrastructure costs, right? To like, mean, it's all on this, you know, it's all on the sales, really on the Salesforce side with the customer already has. So there's no significant disincentive. And it is true, like us with a little bit of our infrastructure potentially outside of, outside of it. ⁓ Maybe there, there is a little bit, a little bit of that, but ⁓ I don't, I don't really view it as that much of a, of a disincentive to be honest. I think I'm a big believer in.

Yeah.

Yeah.

I really want people to use my product, right? And I think if they use it, they'll like it. And if they like it, they'll buy it. So I don't want to create really any barrier to someone coming to that realization that I think that they would come to. And so I know that there's arguments against it. There's certainly like arguments against it, but in my mind, I think the benefits outweigh the costs by a lot.

I'm with you. with you. think that scarcity mindset is actually can end up hindering folks. And I feel like what you just described is kind of that flywheel effect where you want to bring people in because you're proud of what you've built and you know that they're going to like it and then they do like it and then they want to stay and become customers. And then that allows you to fund more growth and more feature development so that people will even more want to use it. So that's great. Well, so I've taken up a lot of your time. So we should wrap up here.

Yeah, for sure.

I do want to ask, ⁓ if you were going back to giving advice to yourself when you were starting out in the ecosystem or to maybe today to another wannabe ISV founder, is there anything you've learned from ⁓ growing out declarative webhooks that you'd like to pass on ⁓ that wisdom to?

I think if I could go back in time and tell myself something, I would have started building products much sooner in like my ⁓ exposure to the Salesforce platform. ⁓ I was very focused as a kind of as a consultant, you know, on the consulting side as basically like a Salesforce developer and architect for a long time. And

Mm-hmm.

Adam, I love that. love that. There's a, maybe you've heard this before, there's a Chinese proverb, the best time to plant a tree was 30 years ago. The second best time is right now.

Yeah, exactly. So I would just say, like, if you have a good idea, like, don't be afraid of it and just just jump, jump in, try, you know, the worst you can do is to fail. Right. And there's a lot of a lot of people out there who, you know, have done it before. And, you know, I'm sure like would be willing to like give people tips and and help and

and that type of thing. yeah, it's and having gone through it too, I think I'd sort of built it up as something that was really maybe harder than I thought it was, right? And it was, it was, ⁓ and it really wasn't, I mean, it took time and it took effort and it took all of those things. But I had, I created barriers for myself, know, barriers and reasons not to do it that I don't think were actually real, you know? ⁓ So, yeah, and it's been a great ride, you know, so.

Sure.

Well.

Yes, well I'm enjoying tuning in to seeing where the ride takes you from here on. for anyone that wants to learn more about you, the company, or see about getting a trial of declarative webhooks, so where can they go to get more information?

Sure, so you can ⁓ visit our website, Omnitoria.io, or of course, look us up on the AppExchange and take us for a test drive, install us in a sandbox for free for as long as you want. ⁓ And of course, we have our freemium version, which you can also install in production.

All right Adam, well, thank you so much. Looking forward ⁓ to the days ahead, and I'll talk soon.

Alright, sounds good, Scott. Talk to you soon.

Cheers, bye.