➡️ Summary ➡️

In this conversation, Scott Covert interviews Ross Layton from Beaufort 12, exploring the unique partnership model that Beaufort 12 employs within the Salesforce ecosystem. Ross discusses the anti-PDO approach, which allows for better management and support of applications, contrasting it with traditional consultancy models. The conversation delves into the importance of building strong relationships with partners, navigating API limitations, and the critical role of testing in app development. Ross also shares insights on pricing strategies, feature development, and the future of partnership models in the app development landscape.

➡️ Guest ➡️

Ross Layton https://www.linkedin.com/in/ross-layton-b3a46813/

Beaufort 12 https://www.beaufort12.com/

➡️ Takeaways ➡️

Beaufort 12 offers a unique partnership model in the Salesforce ecosystem.

The anti-PDO model allows for better management and support of applications.

Consultancy and app development require different approaches and mindsets.

Building strong relationships with partners is crucial for success.

API limitations can significantly impact development capabilities.

Testing is a critical component of app development, especially for ISVs.

Pricing strategies should be fair and transparent to retain customers.

Feature development is driven by customer feedback and partner needs.

Micro economies of scale can be achieved through a consistent development framework.

The future of the partnership model looks promising with continued innovation.

➡️ Youtube ➡️

Watch this episode on our Youtube channel

➡️ Keywords ➡️

Beaufort 12, Salesforce, App Development, PDO Model, Integration, Nonprofit, API, Testing, Pricing Strategy, Customer Support

➡️ Hashtags ➡️

#salesforce #isv #appexchange #pdo #integration

Mentioned in this episode:

Sponsored by Drogba Studio

Drogba Studio helps ISVs build a repeatable partner process within the Salesforce ecosystem. Learn more at www.drogbastudio.com

Drogba Studio

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

Today on the show, I am joined by Ross Layton of Beaufort 12. Welcome, Ross.

Thank so much for having me Scott, looking forward to it.

Me too. I am so excited to share this episode with listeners. Ross's company, Beaufort 12, has a unique partnership with their customers, their partners, and Salesforce. In fact, I personally had never heard of it before, so I'm really looking forward to getting into it. So let's just get started. Maybe you could provide some background on Beaufort 12 and how you work in the Salesforce ecosystem.

Sure, I'd glad to. So, little thumbnail me, I've been working in the Salesforce ecosystem now for some time, probably around 99. I was one of Salesforce's first users in the UK in the financial service industry via Deutsche Bank. And then I did consultancy for many years.

before transitioning from sort of an end user into consultancy. I then did a speller in nonprofit working for the foundation in consultancy. And then the reason that we put both Fort12, myself and Matthew Aston, who's the other co-founder, is that we ran across two very common problems back in the day that was mass email and file storage. And so we actually worked with Dropbox to release one of the very first connectors on the AppExchange in terms of storage.

the Dropbox.

And we did the same for Campaign Monitor, who are not as well known. They are a massive solution out of Australia. They've become a lot more well known because they did incredibly well and moved to the US. Wind the clock forward many years. We now have the official integration for Emma, for MailChimp, Eventbrite. ⁓ So we've actually got five apps now. And the model is that we represent those companies as their official solution.

them

and the customers interface with us directly. So they get the best of both worlds. They get a really good product in Salesforce, great product in Eventbrite, Camp and Monitor, MailChimp, Dropbox, Emma, and our integration. We've worked very hard for the last 10 years to build a very reliable and robust integration.

That is so cool. ⁓ So first

off, I want to make a quick call out because you're too humble Ross. You mentioned you got started in the space around 99. For any listeners that don't know, that means Ross is maybe two months behind Mark Benioff and Parker Harris themselves because 99 is when the company was founded too. ⁓ But at any rate, so I think probably some listeners will be familiar with the PDO model, the product development outsourcer.

Exactly.

That's what I'm used to where on a consulting engagement, a company works with ⁓ a large brand that wants to sell into the Salesforce ecosystem through the AppExchange. And they hire a PDO to come in with their Salesforce expertise and build an application for the brand. The IP transfers, or the IP is fully owned by the brand, not the PDO. And generally there might be like a support and maintenance clause, but by and large, once the app is built,

it falls under the control of the brand. Now, Beaufort 12 has this anti-PDO pitch. Instead of receiving a flat fee and the brand walks away with the keys, you all build the app in partnership with the brand, but you control the entire management of the app throughout its lifecycle. You're paying for security review fees.

you're collecting revenues ⁓ for the app itself. ⁓ You really just are like stewards of the brand. So my first question is just, why did you decide to kind of flip that script of the traditional PDO model and retain the IP and branding yourself?

Largely because making a product for a flat fee and then leaving it doesn't work.

And we send it time and time again. People go out there and they build products, regardless of the Salesforce space everywhere. And it's a flat fee. They do a really good job at the time. And then it kind of gets given back to the vendor, the company to manage. Dropbox are an amazing company, Mountain Champlain, an amazing company. But they're specialists in storage. They're specialists in email marketing. They're not specialists in Salesforce. You need to live and breathe this space, both from a development and support perspective. When a customer pings us about a

Mm.

problem, could be about a very Salesforce centric thing, maybe a governor limit or how flex queues work, invoke actions, how agent force is working. Dropbox is not their job to keep up to date with that. It is our job. You know, we look at Salesforce release notes, we work through pre-release betas, we do a lot of work to make sure the product is good as it can be. So there's a development side and support side. And so I've always been at odds being a consultant as well.

in a previous life that you do this package of work, you've got to realize that it's got to evolve because Salesforce has three major releases a year and minor ones. The partner Dropbox, Campion Management, Eventbrite, and more are all continually updating their APIs and making improvements, adding features. So just doing that one off kind of leave it is just not kind of there unless you've got some sort of maintenance agreement in. Then you need a Salesforce specialist. And again, it should be the same team, same consistent team working

and

making it the best it possibly can. And then you need to dovetail that into support. Some of the support tickets we get in are us helping users, like in terms of user experience or just guiding them through. Other things are improvements we can make. We treat every ticket that comes in as a defect. Why did the customer come to us in the first place? Was it because our documentation could be better? Is it a feature? Is it a bug? And we improve it. You wouldn't get that in a traditional, we build the product and we hand it over and we go,

Does that make sense?

Yes, yes. ⁓ I definitely want to dive into the sales and service side of this. ⁓ But ⁓ before we go there, I'm curious. consulting, thing to consider is that consulting is linear as opposed to a SaaS model being exponential. So there's tremendous upside, I think, in receiving revenues for the app long term. But of course, the benefit of the

traditional consulting outers, get upfront ⁓ a larger warm sum. Have you ever kind of tried to do an analysis ⁓ of about how long it takes for your apps to break even with like a PDO type model? Or have you ever considered on a one-off basis ⁓ doing a consulting engagement with a brand?

So when we first started, we had to do a mixture of consultancy and getting the company off the ground. So when I mentioned earlier, those two initial applications that we built, we built them because of consulting projects.

Mm.

And so we built the consultancy business and to a point that the app business would cover a de minimis level, what we basically needed to survive to carry on with the business. So we got to that point with those products and that's the way that we did it. When we added additional products, to be frank, a lot of them came by reputation. So we were given Eventbrite because the team at Campaign Monitor were very kind of happy and impressed.

a very good contact event right there to talk to. We did a pitch to them. We showed them. They obviously saw the legacy and we got that kind of geek. We got that work on it. But we didn't look at it and say, there's an opportunity cost here, as in we could be going out and doing consultancy. And you're absolutely right. can. Matthew and I have been working in this space for some time. We've done consultancy at some very high levels. So you can get incredibly good projects and incredible revenue. ⁓

time versus the app business. But we're actually really proud of what we built and we really enjoy what we do from the app side. And it's a different set of challenges because when you go into consultancy and you work on a customer org, it's quite nice because you've got a lot of constraints. know what addition they're on. You know what features they've got on. You're dealing with requirements from one set of company users. ⁓

In the application space, it's really tricky because we support professional.

⁓ So we support a variety of different editions with different features, a lot of higher ed, a lot of nonprofits, and might have a nonprofit pack or different versions of Salesforce installed. So you've got to really think about solving global problems within quite huge constraints. And that's just on the Salesforce side. When you mix in the fact that you're working with third party and you need to do that securely via a native app.

It's gone through lightning design. We're now using lightning web components. It's gone through a few changes. We're in the process of making Agent Force ready. there's a continuing change, even after over a decade.

That is so cool. And you're preaching to the choir in terms of ⁓ solving cool global challenges with this. I mean, I think anyone with an engineering mindset would really appreciate ⁓ managed package. I'm biased, of course, but I think anyone with that mindset would really enjoy working on managed packages and ⁓ either being or serving Salesforce ISVs ⁓ for this exact reason, because it's sort of ⁓ another layer of ⁓ abstraction above that you got to be thinking about because you're not just building for one org.

and its feature set, you got to make sure it works for as many orcs as possible.

And you also have the possibility of very unique customization a customer might have.

And of course other managed packages which can cause like race conditions and things. So it is tricky sometimes, particularly debugging. mean, you know this well, Scott, if you're trying to debug something maybe off the contact object and there are several managed packages on there, ⁓ loads mixed in, some old process builder actions, suddenly your logs become incredibly complicated and tricky to solve. we kind of like that, know, sadistic, we kind of like that challenge. And it's kind of interesting.

Hahaha

On your point earlier about the app business as well, it does take a long, like it is hard. I'm not gonna lie, know, like a consultancy business, getting those projects and getting those kind of chunky paydays is lovely. And app business obviously is very different because...

we try to price very aggressively. So we start at just $25 per month. That's an org license, so less than a dollar a day. Like a provider, we have to pay a reasonable fee to Salesforce, about 15%, and then processing fees to Stripe. And that's what comes into the company, net of any company expenses or taxes. So what you get back per day is literally cents on that.

It takes a chunk of time and effort, which is why we did consultancy for a number of years with the app, on the app. And so it got to a point that we could actually ⁓ work off them. it's not an easy path.

Mm.

Sure. What is the size of Beaufort 12 today?

in terms of staff We've got four people in total. So we do we are quite lean

to say the least. But we built the product on a low cost self-service methodology. That's not to say that people don't contact us and need help, and we help out. But we've tried to make the app incredibly intuitive. We've tried to put a lot of work into support and make it really easy. There's a tool which I'm not sure if you're familiar with, or at least isn't familiar with, which is called Arcade.

which is relatively recent. I only came across it, I'd say, maybe a year ago, less than a year. We've been using that because it gives you a really good best of both worlds. It allows you to step through something and see a visual animation. And that's been quite a game changer for us in a lot of respects. It's not the YouTube video, which is kind of running and you've got to kind of pause it, rewind it.

Mm-hmm.

But it's not like screenshots or steps where you've got to step through it. It's an animation that sits there. You step through it like a slide deck. And it just means that you could literally have one screen with your arcade going and another screen with your import. And you can literally follow step by step what I'm doing in the arcade.

Okay.

And we found that to be incredibly useful. The other thing I'd say is we're very blessed in that we've been in the industry for such a long time. We've got great relationships with a ton of SI partners, some of on our site, some we've known and worked with over 10 years. And they know our product incredibly well. So they do a lot of heavy lifting for us in the sense that they'll implement it for a customer because it meets their needs. And we do a pretty good job for a reasonable price point.

the app, they get on with it, they support it and add almost as a first line for us. So that's been really successful for Siklitz as well.

That's great. And I knew that you were a lean team. I think it's amazing what you've done with a team of that size. I believe you said four full-time employees. I understand, being in the ecosystem so long totally makes sense. You've got a lot of great relationships, a great network built out for going to market with a new app. But what about before that, when you are pitching

a brand on building an app for them. mean, a lot of large brands like the ones you mentioned are very protective of their name. So how have you been able to convince like a household name like Dropbox, Campaign Monitor, et cetera, to let your brand stay on the app exchange listing next to theirs, right? As opposed to having it fully ⁓ branded as the large partner.

Yes.

No, it's a great question. I mean, we work hand in hand with the partner, so we have Slack channels.

with, in most cases, the sales team, support team, and in some cases, the product team as well. So people that might be making API changes, that kind of thing on there. So we have direct connections with them, which means it works very well. If they're working on a deal, like the sales team, for example, and they need our app and have some questions, they can fire us a Slack really, really quickly. And so there's a lot of trust in there. Same with support. If they've got a customer, and the customer

Mm-hmm.

might be bridging across two worlds. They might have a question about Mailchimp or Eventbrite, which kind of leans into us a little bit. instead of between two teams, we can answer the question as almost a joint team. And that's been highly successful. Our reviews are pretty solid. We're not the best, I'll be honest. It's probably a British trait, asking for surveys and reviews. So we don't actively ask. But we have some people that are very kind and less than very positive reviews for us, which is nice.

Mm.

And then our SI partners as well will feed into our partners with Dropbox, again have been very complimentary on, particularly the MailChimp integration of late because the MailChimp integration is kind of taking over from a legacy integration in some form.

Mm-hmm.

you know, the legacy integration was kind of passed to us because we could do a good job of it and bring it into, you know, a newer design and make it more live and stable and whatnot. And so we got a lot of positive feedback on that.

All that feeds back into the partner. So for their perspective, it's kind of a neat deal. Or it certainly feels that way that they're getting everything outsourced in a sense. They're getting subject matter experts maintaining the product, the listing, paying all of the Salesforce associated fees, doing all the security reviews, the re-reviews, customizing the product, doing all the support, the ongoing development.

but they're not having to pay a cent for that. But they are obviously getting money vicariously in terms of keeping the customer or they might see some expansion in it. ⁓ know, apps, particularly like mass email apps, there's a lot of choice out there. So the fact that you've got a very good Salesforce integration point has always been a big thing on them. So we get, you know, blessed with lot of hard work. We get a lot of positivity back from the partners. And again, you know, people, the companies

Mm.

either in San Francisco or some of them in Nashville. They kind of talk and again the reviews and feedback has been positive. It's actually how we ⁓ came across Eventbrite initially. ⁓ The team at Campaign Monitor Emma had passed our details on as they were looking for a ⁓ third party and they reached out to us and we had a great conversation with them. We did a proof of concept. We'd shown them what we'd done with other products and they were very kind and they took us on board and

We've had a great relationship with them. They add a lot of value. We add value into that set as well. And the feedback from customers is always quite positive. So it works very well in that respect.

You mentioned now a couple of times that you were introduced to Eventbrite from Campaign Monitor. ⁓ Generally, do brands ⁓ come to you or are brands introduced to you for a product idea or are you spotting yourselves kind of the white space in the ecosystem and pitching a joint venture to them?

I'd love to say that we're out there spotting a space, but as a quite a lean company, our days are pretty full.

We're not the best at sales and marketing, to be quite honest with you. we, which works for us. So the flip side of that is that we don't have to be out there. So, you you said you weren't as familiar with both what 12 and that's kind of my design. You know, you're very familiar with Dropbox Eventbrite Mailchimp. Sure. But they're the companies that you'll search for on the app exchange. The fact that it's powered by us with the official app shouldn't really matter. That matter in some form. if it long as it works and the reviews are good, good there, we're kind of the unsung

sort of engine that's under there, working away. And then we haven't because of that thought, we're going to go out to XYZ and say, you know, we like what you do. We'd love to build an app for you. We're lucky in the fact that so far people have come to us. The business does enough to sustain the employees. We enjoy the technical challenge.

Everything's kind of working. We're not like a ⁓ Zapier where we've got hundreds of employees and huge revenue. We're not that company. We're kind of a small little family business in some form that really enjoy what we do. We have had, over the years, many companies approach us to build integrations. And we've reviewed a few. But sometimes it comes down to their APIs on how much we can do.

Mmm.

And again, we're

quite blessed in the partners that we have. The guys at Dropbox, at Campion, at Mailchimp, their APIs are pretty good and allow us to do a number of things that the customers want. I can't obviously build something if the API doesn't support it. So it's an immediate roadblock. So that goes into the factor of what we build, because if we get a product where the API isn't as extensive or limited, then of course there's very limited things that we can do and then potentially maybe like something like a zap.

is a better solution that might be the key things. We like to own the whole thing as well. So like I mentioned before, it's important to us that we do the development and support hand in hand.

Mm-hmm.

And again, ⁓ working with the partners that we've been lucky enough to kind of sign up and want to work with us, that's always been kind of welcomed and understood and we work with them as a team. we are kind of like, you know, we have the good relationship. If another company came along and was interested, we'd evaluate on the same basis, like, can we work closely together?

Can we be the official solution? How extensive are your APIs versus what the market is looking to use your product for? Because it's a reasonable investment on our side, building a product from scratch.

going through a Salesforce security review, building all the support and development infrastructure, it takes months. And then that before going to quite extensive, we test incredibly, incredible amounts of testing we do. Like really run it through volume testing, all sorts of combinations of things. work with, you we have a lot of high ed and nonprofits, so we'll install nonprofit packs and we'll do additional testing on that. So we kind of go the extra mile just to make sure it works, but all that takes,

Yeah.

quite a lot of and effort. So it's got to be worth it to us. So we go through those initial checks.

Sure, that was something I was gonna ask later on, but we can jump to it now is obviously not every brand would be the right fit for this. I was curious what kind of red flags you look out for. You mentioned a few just now, ⁓ lack of API or ⁓ lack of feature rich APIs ⁓ and brands that don't seem set up for a good partnership where you would control some of the support effort. Are there any others that come to mind?

The

main ones in the sense of like, we again, so we've been lucky in the conversations that we've had that we've been able to articulate the value proposition, like we can take this for you without very little effort on your side.

and go to market with it. Generally, we'll do some comms together, some LinkedIn posts or some emails, but there's very little that's required on the partner's side at that point. That's very enticing. mean, companies like large companies, having people just sitting there ready to support somebody, it's just not there, it? Everyone's getting a little bit leaner. So you might have a few people in your partner team, but you don't

Like have somebody sitting there where you can say, okay Well, you can have this person for a month to is that would that would be very rare so the fact that we can get going and get started it has always been a key thing and and so when we Talk to the partner if they feel like they're like all very keen on us doing it and sort of running with it and they'll step into the comms that's that's definitely like a good green light for us if they're like, ⁓ you know, we want to add our product team we're gonna do this and that and the other and we want to control this bit and ⁓ it's like well

Sure.

Here's why we see that being possible issue in terms of slowing things down or if for example We did have a company that was more interested in owning the support. We're not negative on them owning the sport It's just that their team will be experts in their product it's very rare to see teams that then have an actual specialty in Salesforce and so that's we're happy to like work with teams like we wanted to have like a frontline team for example and we act as second line that that's kind of interesting

But the agreements we've had recently with all of our products we have now has been very much that we kind of own the Salesforce side of it. We will do the best possible job. We'll own all of the support, the development, the customer side of it, the upgrades and all that kind of thing. And it's just worked incredibly well for everybody.

Yeah, that makes sense. I think that's a really good strategy. You mentioned having kind of a shared Slack channel, right? Because I'd imagine these big brands, since they ⁓ do have that household name, something goes wrong. Even if it's fully on the Salesforce side, a bug is discovered in the application itself. I would venture to guess a lot of the support cases are first routed to the main brand.

You know, lot of folks might not even realize that Bofor 12 built the application.

Actually,

you would think that, and probably in the early days, in the first years, that might have been true, but the lovely thing about the Lightning Design System now is that we can put a lot of help posting ourselves. ⁓

Cool, okay,

embedded support in the app itself, huh? Great.

Yeah, exactly.

We have two types of that. We have your standard-like context-sensitive help. So if you're on a particular page...

it will spin you to the exact part of our support site. And then our contact form is there. And we also have an inbuilt chat bot that appears a little question mark within our app that you can ask questions of. And it's a chat bot. So it's using our FAQ base. We use Salesforce's knowledge as our FAQ database. And it queries that to help out. And then it's got an escalation point. So if you feel that you need help, it will just basically push up the contact form.

you'll open the contact in your phone and you come to us. So to be honest with you, most cases come to us almost immediately. But again, because we've worked incredibly hard to make the product very easy to use and set up and get on with. And so the support tickets we get, we get support tickets, but for the amount of customers we get, they're not as many as you would think because the app is really very easy to use. There might be feature

Wow, okay.

that come through definitely. There may be issues or somebody may be, you know, being marketing apps is more a marketing person than a Salesforce person. So they may be tripped up on how to build a report, what a list view is, that kind of thing, like Salesforce terminology. Some folks now, Salesforce are obviously very keen on like automation, like flows and things, and we do invocal actions. In my view, that should be a consultant or an admin developer job, to be honest.

Mm-hmm.

Setup screens are available to users that have that ability, know, like a user may be given access to flow, but not be a developer or an admin background. And so they'll maybe create a flow, but they're not sure exactly how it works, how recursion works, or how to loop stuff and bits and pieces. So we'll get platform questions on it, which are not really self, ask questions, they're selfless platform questions.

That makes sense. Well, I'm surprised that the majority cases go to y'all first. But it makes sense ⁓ with your embedded support model. And that is a really cool idea. think a lot of ISVs listening should maybe copy your playbook there and have an embedded support chat bot to reduce the number of cases in general. And then when cases are necessary, they're routed to the right folks.

That's a really good idea. ⁓

Yeah. We just want to

make it, I mean, one of the key things we like is we just don't want the customer to

you know, have a barrier or to have to think like too hard on it. So if they get to a screen, it's not kind of sense. There's a really, there's always like a help link, which then opens the support article. And if they prefer a lot of people these days, myself included, kind of like the chat, AI type of experience where you can ask more of a natural language question and get an answer back. And then it just helps, doesn't it? It kind of means that people can get self-service a little bit quicker.

Mm-hmm.

Mm-hmm.

And if it doesn't work out, then they simply fill in a contact form. The email will go to our team and we'll try our best to help. Or if it's more of a consultancy-led thing, we've got a whole partner page. we will suggest that maybe that if they're looking at doing like a project or something, or they're looking at doing something that they're trying to develop or enhance with flows and whatnot, then we've got a number of SIs out there that we can pass them on to. And those guys can work together in a consultancy-led program.

That makes sense. And so you mentioned earlier pricing at $25 per org per month. Does Beaufort 12 retain kind of carte blanche over the pricing model and strategy? Because let's just say for whatever reason you decided you wanted to make a drastic change to your pricing model.

Yes.

brand itself maybe could have received some flack, like, hey, all of a sudden I'm paying double what I used to. ⁓ Have you ever changed pricing? And if you have, ⁓ did you have to consult the partner brand first?

No, we've not consulted a partner brand. Amazing to think, but Campaign Monitor has been on the upper center a long time, and it's still on the original price that it was for that level. We did start off with an eight, no, I think it was a $15, eight or $15 plan, because at the time they had a 500 forever free license, and so we matched that.

Hmm.

Because we, on being on Salesforce App Exchange, we don't have the possibility of, a checkout customer, having like a free offering. It's got to pay, there's a flaw that...

Salesforce set. So we have some level and that level is kind set by Salesforce. So I guess we've to be respectful of that. But we haven't increased prices. And what we do is on all of our products, they all start at $25 per company. And we use a tiered pricing model. And it just keeps it fair because we do have a lot of nonprofits and higher eds. And so their use case might be, maybe they've got just less than

Mm-hmm. Mm-hmm. Mm-hmm.

10,000 on the list. So they're just going to pay $20, we offer a 10 % nonprofit discount to nonprofits. So that feels kind of a really fair, I mean, to us, that's a really at the margin kind of cost.

Mm-hmm.

They're getting a good deal. And then if you've got some larger companies on there that using a bit more, have bigger lists or running bigger events, they go up into the tier and they pay slightly more. But it's all based on usage and consequently, if they maybe did an event or did a big email out in December and then they drop back down again, then if they went up a level, they come back down a level. So it goes both ways. It's just made it fair. Again, that's really worked for us. Just having a very transparent, very fair pricing model that's tier based.

rather than having like a flat fee because you know some of the companies we operate with like the nonprofits particularly you know they've got a very tiny sort of set budget and so pricing them out just doesn't seem quite fair when we can provide a like a ratcheting system to keep everybody you know basically using the system on a fair basis.

That's cool. You all are like the Google fiber of the app exchange. Great service. Don't mess with the pricing. Just keep on keeping on. ⁓ What about roadmap conflicts with the brand? Have you ever had issues on where the app should go and had to address some sort of tug of war?

No, no exactly.

No, at all. None actually. The things that we do do again, largely because we have direct relationships with the partners if there's a feature going out.

So SMS was added into campaign monitor a few years back. And so they very keen on getting some kind of SMS from campaign monitor into the integration. So as soon as the API was available, we made it possible for our import wizard that used to push in email addresses to also push in SMS numbers. typically we are quite led in two ways on feature on roadmap. One is if we get a customer

ask for a feature. We will then evaluate to see whether it's technically possible, how easy and hard it is, like if it's an easy trivial change.

that won't impact the customer base globally, because we've obviously got lot of customers that will fit into the features. So we couldn't introduce a feature that may be any works of enterprise. It's half the respect because we have professional customers on there. So we do all these checks effectively. We use JIRA as our project management solution. So it's where our development tickets end up and our feature requests them there. And we basically use that to basically drive a roadmap on there. And if it kind of ticks muster like as in it's

Mm.

that would benefit everybody, doesn't take away from anybody, something we can deliver, something that's technically possible, it almost immediately goes to the development team in some form, and then we'll work on it and release it. And I would say we release almost once a week across the five products. And it could be...

Really trivial, like we had a customer that when they're on a screen, there wasn't something quite clear in a help in. And when we've got a ticket in from them, we've looked at it and we thought, you know, we could have done a bad job on that help in or we could have had a help link there. So we actually, the tiniest code change, would be we update the text in there just to make it a bit clearer, a bit easier, or maybe we push off to a specific FAQ. I cannot like, there was a thing where we had a recently to do with iconography.

Mm-hmm.

just to make something a little bit sharper on the page that you saw a particular icon and it was a contact icon or the lead icon. So someone could glance at it and say, ⁓ that list is linked to a contact or a lead. Literally just a matter of changing an abstract icon to the standard contact and lead icon just to make it pop on the page anymore. But that's typically how we develop it. It's either.

Mm-hmm.

Mm-hmm.

an upcoming change by the partner that we can build and improve the product, something that customers ask for. I guess the third last thing is, of course, our friends at Salesforce, whenever they innovate, like when they added invocal actions, we built invocal actions. Now they're obviously really heavy into agent force. So we've made a lot of our actions agent force ready so they can be used by agent force. And if they add features that we can make use of, even technically behind the scenes,

Things like flex cues never existed back in the day. They do now. We make use of them. Things like that.

Very cool. ⁓ I'm also curious ⁓ about, even though you're a lean team, how you've maybe benefited from ⁓ micro economies of scale in terms of development. since you're retaining the IP, ⁓ think, correct me if I'm wrong, but I believe all five of your applications essentially involve an integration with another brand. ⁓

have you been able to build kind of a proprietary foundation or framework that you can reuse across all these different apps? Or I know they each have their own API. They probably have their own limits and things like that. Are those unique enough that you have to have a bespoke ⁓ model with each of them?

Yeah, no, exactly. That's exactly right. So we are, as you absolutely said, limited by the API. So the engine essentially is different. And so the way that we put the visual layer above it will be impacted based on what the engine can do. So if isn't there in, say, campaign monitor or emerald or matching the email products.

Mm-hmm.

then of course the screen will be impacted on that. But largely, we have a very consistent look and feel. So when you install our app, we have an admin screen, which uses a very familiar style, which we've been using in the app, just to make it easy for not only ⁓ users, but also very much for SIs. And when we did the Mailchimp product, we had a number of SIs come and say, great. That screen is just like the one in CanPix Monitor, and that's how it works.

and the syncs there, like, I've almost got it because it's so similar, like in terms of the screen and the syncing. But then there's terminology changes. In Mailchimp, it's audiences, in Campaign Monitor, it's lists. In Emma, you have one audience. In Campaign Monitor and Mailchimp, you've got the possibility of having multiple audiences or lists. So there's lots of variances, and then we have to cater for that back into the system. I would say in Mailchimp, we've

Mm.

really embraced components. They are really, really cool. We can load things on the page really quickly. They can be placed anywhere on the page. So back in the day, we were very restricted with a related list. And then a little bit further on, we had Visualforce pages, which have their own limitations. But the component framework has meant that we can move things around. But again,

when you look at the components across the products, there's lots of similarities of DNAs there. I'd love to say it's easy as like, kind of like you do a new product to copy and paste, it's not that, but we've got the, what we think is probably the harder part, the visuals, the actual engine, we're pretty good at, but getting the right look and feel, you we've kind of got a format and a framework for that now.

Mm-hmm.

That's nice. I'm sure it also makes testing a little bit easier too across your different apps when something foundational like on the Salesforce side changes that requires testing of all apps, right? As long as your UI is as similar as possible, it probably makes those tests a little bit easier. Like when SLDS 2 came out, for instance, now you can test that across all of them a little bit easier.

Testing is very tricky. It's one of the things that is often overlooked in terms of the amount of time that you spend on it.

change because it might work say in an enterprise edition but it might not be a supported feature in professional or if you've got customers using the not-for-profit pack or

if they're working with flows or actions or triggers in a particular way. So a ton of work goes into testing and that kind of in two forms. Like we have incredible test class, like our test class are incredibly comprehensive and we have through JIRA a lot of automated testing as well. So when a release goes through, it goes through a ton of testing just programmatically. And then the feature is passed to the team here and then we unit test it. So we look at the feature

Does it work as expected? Does it not break anything? And then we have to look outside that. Is there any ancillary things that it might have updated? It could be as simple as maybe the change we've made has a visual impact. Maybe the scroll bar doesn't appear or the button overlaps or something. So we do a lot of testing largely because it's...

It's very tricky when you're working across so many different types of Salesforce instance. It's getting more varied. with like, you know, the old days, we just had a classic page layout. There was very little you could do now. You've got components, you can put them on different pages, you can put them in different form factors. It's very, very tricky, really tricky.

Hmm.

Sure, sure.

there's changes and there's a lot of, ⁓ I know there's a lot of things that are somewhat in limbo from ISC's perspective, right? Such as locker service versus the newer lightning web security. You need to make sure all your lighting components will work in both. You're on the UI side, you need to make sure it works in SLDS too, but still works in the regular lightning theme for folks that haven't moved on yet. So it's amazing you do so much testing. It sounds like Ross, you-

y'all probably do a lot more testing than most ISVs do, which I think is a good thing. That's an area where I think a lot of ISVs could improve. So it's cool to hear that you guys are focusing on that so much. ⁓ I wanted to ask too, so you mentioned multiple times how SIs are a great channel for y'all for entering into a new org. ⁓ Another avenue a lot of ISVs tend to focus on are Salesforce and their AEs and SEs.

And I'm curious specifically about alignment with Salesforce. how do AEs and SEs ⁓ kind of react to your model? Do they treat you as the ISV of record or do they prefer dealing with the large brand and they say like, you work with Dropbox, let me go pick up the phone and talk to them.

and or do they do they respect that you are the steward of the brand?

To be honest with you, when it comes to AIEs...

the last majority is, you they're very much obviously closing deals and that's what they're, you know, they're there to do. So we get quite a lot of inquiries or have had inquiries over the years from Salesforce and AEs saying, oh, you know, we have a customer, they're looking to purchase. But one of the red lines in the questionnaire that they did EQ is that it needs to have a Dropbox integration. You know, can you give us some information on it? Can you send us your demo? And so it's very, I would say reactive rather than proactive in the sense

Mm-hmm.

there's got to be something for them to reach out and contact us. The reality is if they did contact Dropbox, which I don't really remember a case them doing or any of the partners, to be honest, they'd probably be pushed straight back to us. Because we're kind of seen as the sales, we're almost seen as an extension of those companies in some form. So if they were asked a Salesforce question, if they knew it off the top of their head or it was just sending a link or an email, isn't there a support team know our products quite well from there? Oh, here's the support link or here's the contact form or.

Mm-hmm.

Yes, they do this. They can offer general questions. But typically, gets batted back to us straight away. So we might have more an SI, maybe reach out to MailChimp and say, hey, we're doing this. The customer's got this. What integration? And then those guys will immediately again bat it to us. That's tends to happen. I'd say we are.

Mm.

relatively, you know, we're very well priced in terms of like very low level pricing on there. So we're not like one of these large companies out there where they are going to be working on an incredibly large deal and they're going to be working with a partner and the deal to them is going to be worth a ton of money. That's not our space. Our space is working with small, medium, some larger enterprise, but tend to be at the small, medium level working with these products. And so it's much, much

⁓ more SI-led with the occasional, there's an AE that needs to close a deal, there's a box on the DDQ, they need to fill it, they'll contact us. So there's very little interaction with Salesforce on the AE side, it's just not really that much needed, if makes sense.

Interesting,

interesting. Another thing I wanted to ask is, what happens if in the future a brand ever wanted to insource the management of the app down the road? Do you all pre-negotiate kind of a, almost like a divorce clause in your agreements with these brands? Has that ever happened? How does that?

No, not really. So we don't have any kind of special clause or really agreement with the provider in that sense. And again, I think to be quite frank, there's just so much value in what we do. I cannot think of a good reason, being unbiased, why you would do that. Because to do what we do,

Mm-hmm.

You would need a team to do it. You would need a team. That team would need to stay active on the product.

They'd need to manage a Salesforce relationship. You'd need to cut, you know, deal with it sort of Salesforce's billing and PNR and all that kind of side of it, as well as the technical side on it. I can't see a strong enough case why a company would want to bring it in. Unless you were doing a bad job and the reviews weren't great and you know, they weren't happy with what you were doing, then I could kind of understand why they do that. But we work incredibly hard with the product to make it the best it possibly can be and invest in it. Because again, vicariously, that's how we get paid.

it works for them is that there's not like a fee out there that we're going to get regardless. know, we're monthly subscription system. You know, if a customer cancels next month because they're not happy or that directly impacts us, know, it kind of, you know, it doesn't just impact their providers. So we've got a vested need to keep the product as good as it can be. So thank God, you know, we haven't had any kind of divorce type thing. I don't think we ever will because it just doesn't, why would you do it?

Mm-hmm.

Yeah.

It wouldn't make sense on the customers either. Why would you insource it to a team? I can't think of a good reason.

Yeah. Well, when you describe it this way, it just makes so much sense, this whole model. ⁓ Like I said, though, I'd never heard of it before. I didn't know about this option. That said, my wife would be pretty keen to point out there are a great many things I don't know about. So ⁓ I'm curious, maybe this is more popular than I'm aware of. Are there other partners engaging in this model that you know of, or are you all the only ones, ⁓ as far as you're aware?

One, two.

No,

being in the industry.

You know, you talked a lot of people, a lot of people, very lucky. I've got some great friends in Salesforce industry. And, you know, one of the things that always kind of comes back is you guys are doing something really unique, you know, that we're doing this very lean, low cost model, working with some great partners, know, relatively small company in that sense. But, you know, the reviews are great. The customers are happy. The SIs are happy. So it's working.

I think often we get like, how are you able to do so? How many are you doing another product? Because when we've just added, we've re-added Eventbrite after doing mostly email.

Mm-hmm.

⁓ on and switching track to an event you were mentioning earlier, can you take some of the DNA? So for the email services, email is different, but the terminology and the understanding, you're sending information across, you're syncing data back, it's working with emails and campaigns. Across those products, there's quite a lot of similarities, even though it's different vendors. But events is a whole different space. It's a different object model, it's a different way of working. And that can be tricky.

getting up on it and it's like, well, you guys can take on that and we can, and we did. It's a lot of work. I'm not saying it isn't, but the model we have in the way that we develop and support products is almost our own internal blueprint. But it's taken us over a decade to get this kind of magic secret sauce type thing, know, this formula that works for us. But I haven't, to my knowledge, ⁓ ran into another partner that's working for like a big brand on their behalf. Typically,

It's either the brand or a third party that's not the official solution. They're basically just using the open APIs in there. again, there's a place for that, absolutely place for that. But we like a deep native integration and the official partnership. It gives the customer just such a rich experience.

Mm-hmm.

Well, I think it's really cool. I'm sure there might be some folks listening ⁓ that want to learn more about Beaufort 12's model, either for themselves or perhaps there's an SI listening and they want to reach out for your sixth app. If they were to do that, what's the best way for them to reach out to either you directly or learn more about Beaufort 12?

They can connect to me via LinkedIn or they can go to beaufort12.com We've got our site there which has got all of our products

and the contact form and don't be surprised if I answer the ticket, know, we all, you know, there's no kind of levels here. We all kind of work on the product. So I often respond to support tickets. very lucky that we've got, know, Matthew Aston, the other co-founder, incredible architect and, you know, quite well known in that respect. And Barbara Christensen, again, very well known, Salesforce MVP, is in our works with me on the client facing side. Again,

very knowledgeable in the higher ed and non-profit space. So there's a lot of SIs that work in that particular space. And again, through the connection of Barbara, we've had partners coming via Barbara in terms of working with us. So yeah, but I'd say our website or LinkedIn, whatever they prefer.

Great, well, I'll put those in the show notes. ⁓ Just want to reiterate, thank you so much for taking the time today, Ross. I loved the conversation and I'm sure listeners got a lot out of it. I know I did. So thank you again.

Pleasure, I really appreciate you inviting me on. Thank you very much.

Great, cheers.