The Bookster Podcast: Working with Third Party Platforms

Transcript

Hello, I'm Simon and welcome back to the Bookster podcast from inside the SaaS holiday rental software company Bookster based in Edinburgh, Scotland.

Follow along as Bookster discuss their inner workings and their journey to where they are today.

Thank you for joining us and we hope you find these conversations insightful and ultimately helpful.

Minute 1

I'm joined today as always by CEO and co-founder of Booksteer, Robin Morris.

Robin, nice to see you again.

Nice to see you too.

Hello.

Thank you for your time this morning.

And again, today we are lucky to be joined by Adam Aron.

Adam, welcome back to the podcast.

Thank you for having me.

Thank you for your time.

Always nice to have a guest on the show.

Right.

Last time we were here, we talked about vertical integration.

You can go back and listen to that podcast if you'd like to.

Today, we're going to be talking about an interesting subject, which is third party integration.

Now, first of all, I guess, Robin, perhaps you could start by just outlining what you mean by third party integration.

Yeah, so what would be interesting to chat about is when we use third party services, whether it's technical services, software services or business level,

Minute 2

What are our experiences of them? What are the sort of red flags when working with third party companies? Green flags.

When have these relationships been really productive and worked really well? What are the kinds of things that seem to have worked really well for us? What are the things that haven't worked so well for us? And yeah, what's our, how do our users view those kinds of integrations as well or relationships? So it's sort of, carries on from the vertical integration chat as well but it's more about how do we manage these relationships with their third parties and when do they work so so i guess sort of taking a step back slightly basically somebody you know works with bookstare they have the bookstare uh system at their fingerprint uh finger fingers and

Minute 3

But it's early.

So they're using Bookster.

From their point of view, they can make bookings, they can make payments, etc.

But within Bookster, you're using third parties sometimes to make those bookings or payments work.

Yeah.

So we have relationships with lots of different companies for all sorts of different reasons.

Some of them, it's very obvious that or very transparent I suppose.

Sometimes it's more white labeled, sometimes we're using something in the background that nobody would ever really know that we're using but it's yeah how do we manage those relationships with these other companies that form allow us to build Bookster as a product.

So let's start then with maybe the first question and what is the sort of the positive side to using third-party products within your Booksters system? Well, so we have to because they some of them are absolute gatekeepers into for our clients.

So Booking.com, Airbnb, Verbo, other marketing channels for our clients.

We really without them,

Minute 4

Bookster would not be useful at all for them.

So we have to develop those relationships.

So we have to have technical integrations.

We have to speak to Airbnb, booking.com.

We have to understand what they would like us to do.

We have to try and do what we want to do.

So yeah, those are kind of essential.

Other companies that we work with maybe provide us with you know, sort of email marketing tool or we have a sort of...

Payment processing as well.

Payment processing, yes.

Like Stripe, you know, who we use a lot to help us with payment processing.

Yeah.

So it's...

And, you know, the ones that are positive are the ones that we've maintained and kept going for many years.

So, yeah, those are some examples.

Minute 5

From an end user's point of view also, positively, I would personally feel a little bit iffy if some company is saying they're doing the payment processing versus a trusted, well-known provider.

Stripe's pretty much the standard, if you will.

It's certainly one of the biggest payment processors.

If If you're saying you're taking care of all the privacy, all the encryption, all of that versus Stripe, I would rather Stripe did.

There's a certain amount of trust there, so you would almost want to shout, hey, we integrate with Stripe.

Minute 6

Right, yeah.

So peace of mind.

Yeah, peace of mind from your customer's point of view, yeah.

Yeah, yeah.

And so if you go on Bookster, I mean, is it...

I guess it's white labelling, which we'll come to, I guess, but it's kind of, does the customer...

For Stripe, I guess they do know it's Stripe that's taking your payments, etc.

But for other things like either a booking calendar or whatever else you use, is it clear that it's a third party you're using for that section? Or is it all under sort of, does it look like Bookster? As much as possible, I'd say it looks like Bookster.

It depends on the type of functionality you're talking about.

So if it's something...

like a payment processor, obviously not.

But if it's something like a booking calendar, there may be bits of it that we've taken frameworks for different coding stuff that the user doesn't care or they shouldn't.

I mean, I suppose what's interesting is when there's a business relationship between two companies, you know,

Minute 7

We, yeah, like obviously software is built on software is built on software is built on software, basically.

So under, you know, you don't have to dig very far where before other people have written some stuff.

It eventually ends up as ones and zeros.

Yeah, that's kind of, you know, it's just part of writing software.

But when you have a business relationship with a company, it potentially involves support.

It potentially involves support.

their uptime or downtime.

So say we, let's say for example, we integrated with a channel manager, which we sort of do with Rentals United.

They offer lots of niche channels or maybe some other random channel manager.

We would have to push up all sorts of things out of Bookster.

They would have to push bookings and things back down to us.

And we would have to talk to them about when things go wrong,

Minute 8

So the client would ask us, you know, why is the price wrong on some random website? We would have to ask them.

We would say, we're sending you this price, looks right to us.

Then they might say, oh, we'll talk to this random channel about it.

We don't know whether they have talked to the random channel.

We don't know if they've just got the price wrong, but then they come back to us.

Then we go back to our client.

So In order for that relationship to work, you have to have a really good relationship with that third party because it's really totally mission critical.

Whereas, say, I don't know, there's other types of integrations that we've got.

Say if we're pulling in prices, pulling in dynamic prices, it doesn't really, it's much more of a one-way thing.

They give us the price and we use it.

That's it.

You know, there's...

Minute 9

there's less complication, as it were.

And certainly we have had in the past very difficult relationships with some third parties that have really broken down based on not being able to support, not understanding what they're doing, not getting stuff back from them quickly.

So I think if there's someone listening to this that's you know in their business whatever it happens to be they're going to rely on a third party to provide a mission critical part of what they do you know uptime super important there how well documented their api obviously is very important and how responsive they are to your questions which is a very difficult thing to understand but you know do they you know when you're first talking to them are they very responsive does their support seem to be

Minute 10

in the same time zone as you? Are they able to provide you answers to the sorts of questions you might want? Technical answers perhaps.

Also to make sure you're talking to the right part of their team.

Certainly initially when you're talking about integrating with somebody, you're likely to be talking to their sales team who are going to be putting a nice shine on whatever product they're selling.

You do, I would say, want to talk to the technical team quite early on in that process to make sure that actually what the sales team is saying rings true.

Because ultimately, when things do go wrong, and they will, because that's just how software works,

Minute 11

it's not so important that whether things go, go wrong or always, you know, work and it's, it's how they respond because ultimately it's, it, you're putting your brand and reputation out on the line.

When you're relying on a third party, it's still your responsibility to your customer to, you know, for that uptime.

And if you're not in control of that, you, You've got to trust the person or company that you're working with that they are going to respond in a way that's not detrimental to your reputation.

And I suppose if you can't find such a partner, it is definitely worth considering, right? Can we implement this stuff ourselves? Do we really need to be using this third party?

Minute 12

It might feel like a very short hop and a kind of quick way to solve a particular solution.

But you really do have to think hard about maybe this is a short term thing, or maybe we should just try and build this thing, maybe without the bells and whistles that this third party has.

But it will mean that we are in control of understanding when it goes wrong, what, you know, it'll be much easier to support.

etc.

The difficult part in that though is if the integration you're talking about is relying on a gatekeeper that you mentioned earlier.

That's different, yes.

You just don't have a choice really.

One thing, like some green flags for working with we talked about support etc.

So for example, them having a Slack channel or like a chat channel where you can get instant access to

Minute 13

someone that you know might give you the right answer, that's usually quite a good green flag, especially if those sort of chat channels are responsive if you ask a few questions and they do respond quite quickly.

That tends to be a bit of a green flag.

Any red flags, Adam, that you would say? If they're on Microsoft Teams? Yeah, that is a bit of a red flag.

Having, yeah, Different people in so time zones you mentioned.

Time zones can be a bit of a problem.

Badly documented APIs can be a bit of a red flag as well.

I would say also...

Sorry, I was just going to say what is an API for anyone listening? Application Programming Interface is it? It's just yeah where you write you so Bookster

Minute 14

might sit here and we might say, right, we want to, let's say, what would we want to do? We want to send them a booking for some reason.

In order to send them a booking, you would need to write to their, so you have to basically write to their API.

So it's the bit of their system that you program to.

So you send the data to that other system.

Would you say there's usually a level of abstraction in that? You don't know how their system works behind the scenes.

You're just relying on a consistent structure and way of formatting data that you're sending back and forth.

Yeah, they're providing you with a format here.

This is how you need to do it to talk to us.

And what they do behind the scenes is sort of their business.

They might be, say, accounting people.

Minute 15

application, whatever.

Right.

So you need to give them financial details.

So a booking comes in and you say, right here, I'm going to pass you the price of this booking or something, but you need some way of doing that.

You need to say in a logical way.

And you do that via the API.

Right.

Um, So I mean, the other question, I guess we had a bit of a discussion before we hit the record button.

And, you know, we've talked about, you know, even an Apple computer, not everything is made by Apple, but people don't actually care.

They just see it's an Apple computer.

Do people care in your view that you have these third party, you know, providers or they just care of the Bookster product and they don't care actually what's underneath the hood of the Bookster product?

Minute 16

Adam, do you want to answer that or do you want me to? On the whole, I would say our customers probably don't care on the whole, as long as it works, as long as it's doing the job.

From a support perspective, you've got to kind of take it on the chin that the people getting in touch, it's usually not to say, hey, it's going great.

It's usually people that have a problem and they want you to sort that problem so those people might care but most of the time people aren't getting in touch with you.

If it's working, if you're not hearing anything, as scary as that sounds, it's actually probably a good thing.

Yeah, I don't think they do care really, broadly is the answer really.

So they care about functionality usually.

So there are some people that care.

Minute 17

There's a small number that care, but most people are more interested in their vacation rental business.

They're interested in getting more bookings, pricing their property.

How do I deal with guests making payments, balance payments, damage deposit payments? How can my cleaners see the bookings? That's what they care about, really.

They don't want us to say, oh, they don't want us fobbing off a problem on another company.

So they really don't want us to say, oh, well, the reason this isn't working is because of Jim's widgets.com are down.

Because that's a horrible answer to give in support.

And that's when they do care about it.

But, and we shouldn't ever give that answer really.

Because basically you're sort of saying...

If Jim's widgets are behaving correctly, then they don't really know that Jim's widgets are providing us with a service that's helping people get bookings or whatever.

So ideally, they don't care.

Ideally, most of the time, they don't...

Whether they know or not is neither here nor there, really.

I don't care whether they know or not.

It's more that what is...

Minute 18

what they're dealing with is something coherent, something that works for them.

They log into Bookster, they can use all these different things together and it works.

But yeah, we have to track when we're dealing with these companies, we have to assess all of those sorts of things.

How likely is it there to go down? How likely is it that they're to work? How do we test it? How do we test their API? How do we test their support? How do we

Minute 19

assess their suitability to be used in our platform.

All that stuff is hard.

So I guess that does lead on to the next question, I guess, is that who is it you i mean how do you find these people to work with how do you uh have you in the in the course of bookster changed these providers that you work with um you know how does that actual process work i mean you come in on a monday and you think i need a new calendar manager or something do you ever think that or are you just sticking with who you have because it works um well we so we have in the past had uh real problems with some of our providers or Yes.

So usually if things are going wrong, you know, like they're down or the support is really bad, we might be forced to implement something ourselves or we might be forced to use a different company.

Usually once you've chosen a company, you obviously have to put quite a lot of technical effort into integrating.

So it is quite a pain to change.

Minute 20

Would you say from a technical point of view though, Robin, that we do write software and would advise writing your software in a way that's as modular as possible? So if there is a problem with a provider, swapping out that provider wouldn't be as big an issue.

To keep it as modular and separate internally as possible, so that you're not suddenly swapping something out and breaking a whole bunch of other things.

That, okay, this provider is providing this functionality on our platform.

If they fail, we can quickly gather our resources and take that out and put another provider in there or write our own implementation.

Minute 21

So I'd say, yeah, the approach to architecting your product would depend on you making it as modular as possible.

Yeah, that would definitely be the goal, definitely.

Which probably means trying not to utilize companies that have some amazing different way of working or some USP thing that they provide that our clients might come to rely on.

So you want to keep the USP bit inside Bookster, but...

keep them you know you can utilize the more generic stuff on the outside from a third party maybe that's one way of looking at it yeah and what uh i mean without giving i guess names away i mean have you had an experience with a provider that hasn't been positive and you've had to make changes because of their service to you just the government just well adam do you want to talk about one or

Minute 22

I mean, there was a while back.

It was ancient history now.

We did have a provider at one point that promised the earth and the sun and did not deliver.

And it was a truly awful experience for us, for our clients.

Yeah.

I mean, things like we mentioned earlier about like having a point of contact, it felt like the point of contact with this provider, you'd contact their support and then they would contact someone else and then they would get an answer from someone else.

And that, you know, like maybe they were using third party providers as well.

It really felt broken.

And we we

Minute 23

had to recover from that.

We lost clients as well.

Yeah, we lost clients.

It was not a good experience in any shape or form.

And it's like, I almost wish we had never touched them.

But it was a good experience.

We now, you know, we have a lot more.

Yeah, it is, you know, and it's important to have those learning experiences, but it's important to survive them as well.

So, you know, I'd be wary of people promising the earth.

Yeah, so those guys who, you know, are going to remain nameless.

They had a technical team in Europe somewhere.

Minute 24

We're based in Edinburgh, so their technical team was relatively close to us, but their support team, I think, was in Mexico or something.

So we would ask their support team in Mexico who would wake up later on.

How's your time zoning, Simon? So they would wake up at like 1 o'clock, 2 o'clock in the afternoon.

Yeah.

they would get our support ticket and think about it then at like six o'clock in the evening our time they would send it to their technical team in france who were who had obviously left the office and then they would get up the next morning and they would send a reply to mexico but they're in bed so yeah these are like these are mission critical problems we get a response three days later or something or whatever two days later someone's saying oh could you give us more details

Minute 25

Now that is horrific because our client in the meantime, our clients.

Has left.

Has left.

Have left.

Yeah, they've literally just gone, well, you know.

So that was horrible.

We've also had some other experiences with some, let's just say payment providers of some description where it's been very difficult to understand.

We're trying to get them.

to get any sort of visibility in what's happening, what stage our clients are at and being onboarded.

They've got all sorts of products that they've sold over the years.

It all seems a bit chaotic.

So we've had that where someone says, oh, yes, the bank have told us or the payment provider maybe have told us that they integrate with you.

Minute 26

And then you go and ask them and they're like, oh, yes, we use this, which doesn't it's something else that we've integrated with.

Then they pass it to another department and then you don't really know what's going on.

The transparency is poor.

The support is poor, they don't know who they have or have not integrated with or got, whether it works.

They've got all sorts of APIs that they've been using over the years.

The product you're integrating with has been abandoned as well as...

Bought out five times by five different people.

Bought by someone else and bought by someone else and bought by someone else.

And they don't really know what they've got.

So, yeah, I think then our client is sitting, waiting...

saying, when can I take payments? Because that's totally mission critical.

You can't work with Bookster without being able to do that.

So yeah, it becomes.

Sounds like a very frustrating situation.

Yeah, possible.

For everyone.

And stressful for you guys.

I think maybe a Bookster ice cream van would be a better option for you guys.

Just nice and simple.

It's a good idea.

Go to the park, sell some ice cream.

Minute 27

Good, right.

Well, let's...

I think we probably should wrap up.

We're now almost half an hour there.

That has been interesting today.

Thank you for being so candid with your views there.

We didn't name anybody, so I think we're okay.

We're not going to get sued, so we're all right.

But certainly there's some...

some stresses there I can tell.

Right.

I should just mention before we stop that we do have our sister podcast, which is Smashing Your Holiday Rental Goals.

And you can find that online by searching that title.

If you have any questions for this podcast, please email them into podcast at bookstorhq.com.

And we will try and answer them in future episodes.

Minute 28

Thank you both for your time this morning.

Adam, it's good to see you again on the podcast.

Thank you.

And we'll hopefully see you again soon.

Robin, thank you again for your time as well.

I think maybe one of our next episodes will be a sort of debrief on a sort of conference thing you're going to soon.

Yeah.

So that'll be quite interesting.

What's the name of the conference you're attending? Well, we're just going to do an ASSC event.

next week in Glasgow so that's one to have a chat about yeah absolutely that would be interesting so we'll do that but for now thank you very much for your time thank you for listening and until we meet again goodbye bye