[Music]
Jessica: Hey, everyone, and welcome to the third episode of Greyd Conversations. I’m Jessica,
and it’s my first time on the show together with Sandra and Jakob of the Greyd team.
Sandra: Hi.
Jakob: Hi.
Jessica: We’re going to talk about a super interesting topic today: Websites as a Service. This year WordCamp US was extended to have a showcase day included, and I had the honor to present a case which we are going to talk about in this episode as well.
Jakob: Yeah, I haven’t been there myself, but from what I’ve heard from people, they really enjoyed this, and I think that’s something that other WordCamps can kind of copy maybe.
Jessica: Yeah, absolutely. In my opinion, this should be something that WordCamps can implement more often, and it’s interesting to see what other people and agencies are actually building with WordPress. But maybe instead of waiting for the next WordCamp to offer a showcase day, we can also share our insights and experience here at Greyd Conversations. So let’s hop into today’s
topic with websites as a service. You two have, already been involved in building such cases together, right?
Sandra: Yeah, absolutely. Maybe we should start by discussing what website as a service actually is, because let’s be honest, it’s one of those buzz words that people use all the time without questioning anymore what it actually means.
Jessica: Yeah, sure. So what does it mean?
Sandra: Well, there are actually different forms of website as a service. What they all have in common is that it’s some ongoing service around websites. So from a provider’s perspective,
we’re talking about recurring revenue, which is also one of the reasons why it is so interesting. And regarding the services that are included, they actually vary. But on a very high level you could say that it’s about the creation and the maintenance of websites. So as opposed to a regular website project where the customer pays you and then you build a website, you have a go live and that’s it, here it’s about ongoing services. So for example, the hosting could be included or ongoing technical support, maintenance tasks like monitoring, backups, updates. Sometimes content management is included, SEO optimization, performance optimizations, all these kind of topics. And then most of the time you have a regular fee monthly, mostly, sometimes also yearly. And sometimes there’s an additional setup fee.
Jakob: But isn’t this what I think a lot of agencies have already done in some regards, like when it comes to retainers? You know, if you have a website project for price X and then afterwards you pay a retainer for the agency to do things like updates, backups. So, isn’t it?
Sandra: Yeah, kind of. I think that’s exactly the point where we need to differentiate between actual website as a service and regular agency business. I mean, technically speaking, this retainer business model is some sort of website as a service, but on a very, very low level. Because when the website creation itself is still a regular project, what is completely missing
here is the overall scaling, automation and streamlining of processes here. Because for each and every project you need the same resources again, you kind of start from scratch. So there’s no scaling. When we’re talking about actual website as a service, you want to do not a dozen website projects a year. You want to be able to do hundreds, maybe thousands of websites. And that’s what website a service is all about.
Jessica: Maybe we can look at some examples there.
Sandra: Yeah, absolutely, let’s do that. I mean, as we already said, there are different kinds of website as a service. I think what most people might have in mind when thinking about WaaS, is an agency or maybe also a freelancer offering website as a service to their customers. So, for example, they offer a bunch of website templates to choose from,
that may or may not be customized. And then all these additional services that I just named, like hosting, technical support and all that. So that’s one form of website as a service. But actually at Greyd we have come across several other website as a service businesses that customers of us built on WordPress with Greyd that are completely different. And I want to show two examples today. One is the franchise case, like the one that you, Jessica, presented at WordCamp US. When you have a franchise, you usually have the brand, the franchise,
and then you have a lot of franchisees. So the brand, the franchise, for example could be McDonald’s or in your example the fitness brand Mrs.Sporty. And then you have all the franchisees, which are the individual restaurants or fitness studios. And they pay a regular fee to the franchise for being able to use the brand, to get a product, or maybe also to get a website. And in the Mrs.Sporty case for example – a case that a customer of us, Forte Digital,
has built – each and every fitness studio received their own Mrs.Sporty website. And they are all connected in a way that Mrs.Sporty, the franchise, has full control over the branding and can make sure that the websites all have a similar structure and a similar layout, and they can integrate new franchises at any time. So that’s the one example. And the third one that I want to include today is another customer case we came across at Greyd. It’s a German enterprise, and they offer some form of website as a service within their partner program. So, they offer their partners individual landing pages that they build for them, they host and they maintain completely, including lead generation forms and all that. So the partner gets that website
that is fully managed, maintained and built by the enterprise and is also branded in the enterprise’s branding. And I think they also include some services like content management
and I think even ad spendings. So, these are other forms of website as a service.
Jessica: Cool. So, website as a service is not only a business model for web service providers, but also for larger companies and franchises, right?
Sandra: Yeah, absolutely. And since many of our listeners today may be agencies of freelancers: I mean, you can build such a website as a service business for yourself. But you can also make sure that you are able to build these cases for others, because this is a very
interesting opportunity for you as an agency to grow, to scale and to take on really big projects. Because I don’t know how many McDonald’s are there at least in Germany and in the world? And even if we’re not talking about these huge franchises, still, I mean, we’re currently in discussion with another franchise customer on such a case. And there it’s about more than 1,000 websites. And I mean, which agency is usually able to take on projects that contain several hundred or thousands of websites? It’s more or less most only the really big agencies, the Human Mades, Sydes. But if you manage to build such a scalable WaaS platform, then you are also able to take on these kind of projects as a small or mid-sized agency. It’s possible.
Jessica: Yeah, I think that’s very interesting. And maybe we should start about getting into how you build such a website. So now we got a bit of an overview what could be possible,
what we have seen with our Greyd customers building for websites. So, how can we do such a website as a service?
Jakob: Yeah, I think that’s probably the point where I come in. Again, as Sandra mentioned, from a technical perspective it really depends on what kind of WaaS you’re trying to build. And we can probably start on a high level and then get into the details and actually show examples. So for example, one of the cases Sandra described is kind of like an in-house website as a service where you really manage all the websites that could be a franchise case
or this partner Sandra described. So, how do you build this? So, first you have to consider hosting and stuff like this. So in this in-house case, multisite for example might be an option,
because you can host it on your own server and you can have control over everything
and ownership of everything as well. So multisite might be a feature that makes it really easy for you to just create new websites and maintain them all from one global source. If we’re talking more about the agency case, like you are deploying websites for external customers, there multisite is probably not the best feature to consider, because there are a lot of reasons. For example security or at the end of the day, especially ownership. So your client hosts on the hosting provider of their choice and need to own the site in some kind of way. So usually what we see with agencies is that a multisite approach, having all your client
projects on one instance, is not the approach they’re choosing. They might have a multisite for staging for, they stage every customer’s website. But when it comes to the actual hosting,
those are hosted on live hosting environments. And then you need to make sure, okay,
how can we connect these, too? How can we communicate to the sites? How can we maintain them, have the view of all the sites we are kind of maintaining. So this is the high level starting point of how you would set this up.
Sandra: Yeah. Maybe we we can start by summarizing what you need and then go through it step by step and then take a look at examples. I think Jakob, your also have some some stuff to show to our listeners. So in general when we are looking at website as a service, it’s all about automation, standardization and streamlining processes. By standardization I do not mean that each and every customer gets more or less the same website. There can of course be customizations. But if you want to be able to do those 1,000 website projects, then there needs to be some form of high, high level of standardization. And there are technical ways
which we’ll take a look at later to do that and even have individual results. So I think the first thing that’s really, really important if you want to be able to do that many websites in your system, is working with reusable assets and also with a component-based approach. Because this is one thing that enables you to standardize while still being able to have individual designs or individual content on a website. Maybe this is something that Jakob, we can start to show here.
Jakob: Yeah, I really like this. Like, standardization is probably like the base level where it all starts and from a standardized way of building things, you can go ahead and then customize everything. So, yeah, we can start on a really basic level. Let me share my screen real quick. So, there’s a lot of ways to approach this. Obviously you can choose a lot of different environments, a lot of different standardization features. And starting on a low level, you can just use what WordPress offers you. What the WordPress core offers you with FSE, for example. So for instance, take a look at the design presets. You can standardize this kind of website. Obviously this is the Greyd Theme. And this could be a template for your pages or posts. And you can go ahead and customize it based on a different style set. So what this could be: On one site it could look like this. On the other site it could look like this, on the next site it could look like this, and so on. So each and every site uses the same structure and the same elements, but the styling for example, changes from site to site. And you can now create website templates for e-commerce sites, for your blogs, for your pages. You can kind of create your blueprints and your templates for all the pages, and then just customize it on a site level by using the features WordPress core offers you. And this goes deeper as well. So I’m not only taking a look at the styles here, but take a look at patterns, for example. Obviously those are the standard patterns, but you can create your own set of patterns, patterns or just presets that your customer or you can easily insert in your page whenever you build a project. And if you take a look, these patterns in this case look bluish with this little pink color. And if I go ahead and take a look at how this looks for example, if I choose this orange color preset, all my patterns automatically adapt to the changes I’ve made. So and this showcase how just core features on a really high level can enable you to adjust templates and use the same structure for each and every project and maybe even then sync it, go ahead and reuse them. And they automatically adjust to the design you’re setting up on these different sites. So this is from a high level the first starting point where you could exploit features from WordPress core to achieve this standardization approach.
Sandra: I think you already indicated something interesting here, because I think what would be the next step now, it’s not just having the set of templates that you can copy and paste on each of your installations, but maybe also to synchronize them and connect them in a way that enables you, on the one hand, to roll out new templates to all the connected websites,
to all your customers, simultaneously. Or also maybe to make changes on existing templates on all connected sites. So for example, in the in the Mrs.Sporty case, imagine they have a rebranding or they reworked the website and they don’t want to do these changes on all other I think it’s 250 websites. They want to make the change on their master stage and then roll out this change to all the websites.
Jakob: Yeah, exactly. So, maybe we take a step back here first. So the requirement before you start this, is you need to have some system in place that enables you to centralize the management of all these assets on your website. So as I described, patterns or templates
could be assets of your website. But this goes deeper. Each and every post, each and every page, everything is an asset at the end of the day. Every image. And yeah. So how do we achieve this? How can we utilize a centralized management system across the pages? Let me share my screen again. So here we go. We might start off in the Hub. So this is Greyd.Hub. Obviously a lot of you probably know this. And the first one is you have a global overview
of all the sites that are in your network. And obviously I talked about multisites. This is a multisite in this case. But it doesn’t necessarily have to be a multisite. You can connect different sites to it as well. Different other multisites, single sites, other multisites and so on that are all connected to each other and have a global overview of all the things. And now you want to dig into how can I centralize my assets? How can I manage my assets from a global perspective? So therefore we take a look at this little page. So this is a page on this website. So just take a look at this website real quick. We will take a deeper look later on. So this is how this website looks. And this is a simple page on here. And this page pretty much only contains this little box. And this little box is built using a template which I call „image box“. And this image box is now synchronized. So this is in use on three different sites. You can see the sites here. And if I now make a change to this asset, it is automatically changed on each and every instance. So for example take a look at this site. You see pretty much the same instance, the same content. It has different content in here, but it’s the same design pretty much. And if I now go ahead and change for example, this and make it normal without the rounded corners, maybe make it wider and I save this. This automatically gets updated on
every instance it is used. So obviously it is changed here. You can now see this image is a bit larger. But at the same time it is changed on a different site. So this could be your client’s project. This could be your second site of a franchise network or your partner site. And it doesn’t change its content. So it’s pretty similar to what synced patterns and reusables are doing. It’s called Dynamic Templates within here. I think a lot of the listeners are used to it, by this time, but I can reuse this asset now to, for example, display posts as well. And I can reuse this here two times. And on this page I only build it like one time. And this pretty much a synchronized asset. So how can I achieve this? So for example, I take a look at this image
box page. And first of all, after I created it, I made it a global content. And as soon as it is
a global content, it appears in my Global Content section. So for example, if I go to this website again and I go into the backend and to Global Content, I can see this image box, this page image box is now appearing here. And I can now import it to my site. And if I import it, I want to keep both, because I already replaced one of this. I pretty much localized my own version of this and I can find it here, via my pages. So this little indicator, this green dot
box indicates that this is a linked post and it’s now synchronized to the to the overall page. And I can go ahead and make changes to the page on the root post. And then it automatically updates here. Or I can convert it to a static post and adjust it from here on. And this is how you can centralize your management. And this could not only be templates
or pages, but it could also be patterns, it could be WordPress templates, it could be an entire post type with all this post. And yeah, this is how you pretty much centralize your management. And one thing – I quickly want to mention this, but I want to show in here as well. If you want to reuse the assets across different websites that are hosted on your client’s hosting site, you can connect websites in here, so you can connect it to whatever site you want to connect it. Obviously, the plugin has to be active there, and then you can communicate between users and you can share content and you can yeah, pretty much sync
the entire website or parts of the website just by connecting the sites and enabling
Global Content.
Jessica: Yeah, I think it’s pretty impressive how powerful this features are. They can save you so much time if you have to create like a larger number of similar websites. So it would always be repetitive and you would have to, like, do it over and over again. Copy here,
paste there, change colors maybe. And with this it’s just a few simple clicks. And initially you have to configure this, but later on it just saves you so much time, because like you need to do one little change? Okay, do it on your source and then it, boom, is synchronized across all the websites that are connected. That’s pretty cool.
Jakob: Yeah. And I think that’s exactly what you talked about in your talk at WordCamp US. Let’s dive in this concrete example a little bit more. Yeah, of course. Because, I now described how you can achieve globalizing a template and globalizing a pattern and reusing it. But then again, if you really want to build… I mean, this example that I’ve just shared is pretty much just a template. It’s really not a proper use case that you would build in real life this way. So let’s share the actual case that we, were building together with Mrs.Sporty in this example. Because there are several different issues or problems, that we developed solutions for
in this case. So what we did is, we built these two sites essentially. So obviously they’re not the live sites, but they’re demo sites. And you can see these two sites are pretty similar content-wise. So the hero image is the same. Obviously the styles are really different. This has a different font, different colors, different button border radius and so on and so forth. But the essential content is the same. So „Discover the joy.“ – it’s the same that it says over here. But for example, the subline „Welcome to Elevate Fit Center“ is different in each occasion,
because each and every franchisee in this example has a different subline. And let’s take a look at how this first part is achieved. So obviously these two sites are connected. So if I update it here, it’s no surprise that it will be updated on both sites. And you can see the dynamic data already in here. Sandra talked a lot about standardization. And now we’re getting in the standardized elements. We’re getting dynamic data in here. So for example, a site title – which is obviously a default WordPress option – the site title of every website
that’s set on every WordPress site. So I can just select it in my dynamic tag by simply entering # and then select „Site Title.“ And therefore it is now displaying the current website title. And if I see here „CityLife Gym“ is the actual title of my website. And the same goes for this example as well. You can see the headline is not updated and „Elevate Fit Center“ is the title
of my actual site, and it’s the same with the website subtitle. So this is how you get different dynamic data in here. And that was really necessary when synchronizing content across 200 instances, 200+ instances, for this example, because you need to make sure that some of the content stays localized and website title, website subtitle is pretty much to the base of this. Then obviously the next section we discussed this already. The is built again using the same template. It just showcases how this template can be reused on different pages in different use cases. And you can again edit the template, edit the wireframe version of this and reuse it with different content. So the content in here, I can replace the image, I can replace the headline, I can not mess this up entirely. So I can not delete any elements in here. And I can not adjust the design. I can only do this inside the template, which is my wireframe component of this. So this changes the design. And this content is set individually on the page. And then one of the next issues we’ve had and we’ve solved is displaying posts. Obviously, whenever you’re displaying core post types, this is really easy. You can just display your post using the thumbnail image, using the post title and using like the description
excerpt of the certain post. But what if you need different posts? For example, what they needed was offered jobs, employees, a lot of different post types. And this is not default. So you again need to make sure that you standardize kind of the structure of the post type. And in this example we built the post type. And this is showcasing the post program in this example. And if I take a look at the program post type, this is just again a post type. Really simple. And I made this a global content post as well. And this is synchronized to my instances of this site as well. So what this makes sure is that each and every instance has the exact same structure of how this post is configured, how the meta fields are configured, and I can reuse the exact dynamic data types on each and every page. And in this example I synchronized the entire post type using all the posts. And on my „Elevate Fit Center“, if you take a look, you can see there’s a Kettlebell training here, which you cannot find on the root page, because I allowed my franchisees essentially to create their own programs, and they can easily go ahead, create a program, type in the title, and select some content, select an image and it will show up in the feed without changing the global synchronization of this program. So this is really valuable if you want your franchisees to be allowed to change programs locally or create their own programs, but also reuse what you offer to them. So the headmaster, for example. If we now create a new program and we call it „new global program“ for example, it automatically will be published to each and every instance that I synchronized this entire post. So if I now… Obviously I haven’t selected any contents and selected any images. So obviously, if we refresh it here, we can see our new global program showing up. Doesn’t look very well. And if I refresh it here as well, your new global program is showing up as well, but still preserving the Kettlebell training. So you can roll out new programs, new post to all of your sites, but still allowing your franchisees, if you want to,
to create local instances of this. And if we go a little bit further, this is the section where the employees of the different franchisees are displayed. And obviously this needs to be entirely local. Each and every franchisee, each and every store, has their own people working there,
and they’re never global in any case. So in that case, let’s go to the post type. Actually, in that case I created the post type as well – „Trainer“ and I made it global, but I’m not including individual posts in here. And what this allows me to do is ,again, the structure stays the same. So each and every trainer and each and every site has the same structure of meta fields like job description, quote and information. But the actual content, the actual posts, are completely local, completely individual. Just another solution of a problem or a use case you might run into.
And last but not least, we want to take a look at this bottom section: „How do you get in touch?“ If we’re taking a look at the live website, „how do you get in touch“ shows here the address and opening hours. And then obviously contact the contact form. And this is a bit tricky as well. So we took a look at the the core WordPress options like site title and site subtitle, which each and every WordPress instance, doesn’t matter how you build it, will have. But these options might not be default. Maybe the address, maybe the email could be like the admin email. And you can map this to WP options. But essentially, opening hours Monday
to Friday is certainly not a default WordPress option. So how do you do this? How do you still maintain that this information is in the same structure on each and every instance of your maybe thousands of sites? Again, we are pretty much building the same. We’re using the same feature again: post types. In this case we’re building franchise data as a post type. And we made it globally available. And this automatically creates an option set up where I can build with the same flow. I can create my meta fields, general information, address, email,
phone, whatever. And Monday to Friday. And each and every franchisee can go in here and edit the master franchise data. And this is something what non WordPress professionals can easily fill out. This is just basic custom fields. And I can fill in my address here. And then as an agency, I can just easily get it wherever I need to display it. So if type an address, you automatically get the suggestion of address. Or if I type in #Monday to Friday, which I named my option, then automatically Monday to Friday appears in the Editor. I can display it in a headline, paragraph, group, whatever I would like, and this will automatically refer to the option on each and every site. So this is another way. Essentially you’re customizing
not for one single site. You’re customizing not for a post basis, like a query loop. You’re
customizing for entire set of websites. And this is this. Those are some of the solutions
that we’ve built together, with our clients in these specific cases.
Yeah, I think that’s a really detailed overview of how you can achieve different solutions for these different problems where you really not only think about, how do I content and data not just based on a post, like the query loop for example does with post meta fields, but really on a site level. How does a site have different meta information than a different site, but still reusing content as it structures a lot of these links? Yeah, I hope, this explained a lot
of how you actually achieve standardizing your content and distributing it.
Jessica: Yeah. So I think it’s pretty interesting to see how you can manage your content both locally and globally. So like you have it in some source site and then you can push it to any site that is connected. But also, if you have the need, you can add any content in addition to what’s globally available to one specific site if needed. So, I think that’s also super valuable
if you think about that, because otherwise you would have to do, again, manual work or keep it up with like Excel sheets or something or any other project management tool you’re using. So instead of that you’re just streamlining it to it is possible to have everything in one go and add additions were needed. So yeah, I. Think that’s pretty cool.
Jakob: You summarized it really, really well during your talk at WordCamp US. where you talked about you have some contents that are global, for example the templates, the design resources, that like the head office needs to maintain in this franchise case. You have some of the contents that are local, like the address, the opening hours. This could be a local setup in this case. And then you have a mix of both like the offers, the programs I’ve showed you, where you have globally distributed types of content and structures, for example, but you still need to be able to customize things locally. So each and every website can have their own approach, their own data, their own sections pretty much displaying there.
Sandra: And I think what’s also interesting here is that this approach also enables people who don’t necessarily have WordPress experience to edit the contents themselves. So for example, in a franchise case, the franchisees who may not have anything to do with web design or stuff like that, they are able to edit the content of the websites themselves. And that’s not only applicable to the franchise case. For example, if you’re an agency and you have, I don’t know, specialized in websites for doctors, for example, and depending
on the level of content management you want to include in your website as a service model you may also have cases where you want the doctors themselves do certain changes on the website, like for example opening hours of a holiday or something like that. With these post types and this approach here, you enable them to do that by themselves. They have a really simple interface with just some fields to fill in. They can’t mess anything with the design. They don’t need to think about okay, how does that look like on mobile or something like that. It’s all standardized, but the contents can still be individual on each website.
Okay. I think we already covered some key elements of website as a service. Maybe that’s a good point to summarize what we’ve discussed so far. So, we defined that we need some kind of reusable assets and a component-based approach. And either we have templates and patterns that are static, that I can just reuse for certain websites. Or even better, have them in some kind of connected or even synchronized way. We also discussed that it’s important
to have all your websites manageable from one central place, and ideally in a set-up that also enables you to add new sites or delete sites with just a couple of clicks. And you might even want to think whether you can automate that as well. Because thinking again of this 1,000
websites case alone, even the step of setting up all these installations and installing your default set-up and the connections and all that – that takes a lot of time with thousands of websites. So maybe think about automating that as well. That’s for example what we might be doing in this 1,000 websites case. And I think the next step you have to look at is automating and standardizing and centralizing as much as possible all these let’s call it maintenance tasks, for example monitoring, updates, backups. And with updates I don’t mean auto-updates. That’s something we don’t recommend in general. I mean being able to do these updates from a central place for all your websites, for example. Maybe Jakob, could you share some ideas of… I mean, there are certain ways to actually achieve that. I think there are a lot of great tools out there, also are hosting providers with features like that. What are the possibilities that people have here?
Jakob: Yeah, really good question. Actually, we talked a lot about how you build the solutions. But once you’ve built a website, now you kind of need to maintain it in some kind of way. WordPress comes up with updates, plugins come up with updates, your clients will see the need to update some elements. So in general, one of the recommendations we have is, use a solution to centralize your update management. So, WP Umbrella for example is something we highly recommend. We really like the tool which kind of automates and centralizes your monitoring pretty much. So it does your updates, backups and everything for you. But obviously a lot of the hosters do similar tasks as well. And that brings me up to the next. Hosting plays a really central role,
especially in the we build thousands of websites franchise case. Because if you want to build thousands of websites, you need to take care of hosting. You need to ensure things like a load balancer, maybe, containerization. You might take a look at database sharding, if you really want to build it on a multisite in this scale. There are other things to consider as well. But essentially you need to make sure if you build it
on one multisite or several multisites and you will have a lot of visitors on your sites and they’re all kind of requesting the same content in some kind of way in the same installation. So, yeah, hosting plays a place a role. And also, I would always suggest, if you’re having for a lower entrance barrier, not go in with thousands of websites, multisite is a really neat approach, because you can really easily create a new website and you can really easily handle updating all your sites at once. Because it’s essentially the same WordPress installation. Obviously, I talked about a bit of load balancing, but this becomes easier. And if you have a hosting provider and you want to build each and every site as a single WordPress installation, which improves the security, you need to make sure that you can update it in some way. Because otherwise you probably have hundreds of websites at some point that you need to go to each and every site to click on update. And this is something you might not want to be doing. We tackled a lot of these things using weekly scripts, obviously, using containerized websites. For example, Insta WP comes up, other hosting solutions as well. But those are just on a very high level. The things you need to consider in some kind of way. But it really, again, depends on what you want to build and how large it is essentially, and what your entry level is and what your skills are in this, this particular field.
Jessica: Yeah, cool. I would like to take a closer look on our franchise example again. Until now we have talked about synchronizing assets and structures, like managing content both globally and locally, and so on. And assuming the websites are all kind of the same. What if we do have like a franchise case with all the franchises, but there are differences in their offers? Not just like what you showed with the individual programs, but with differences like some fitness studios offer a bar and some don’t.
Jakob: Yeah. This this is a really interesting question. First of all, what this essentially needs is a conditional approach, kind of. You probably are aware of conditions on a page level or post level. So for example, what you can do using whatever conditional tool you might want to use, for example conditional content – a feature or block that we provide – is for example, if this post has the meta option or taxonomy, for example the taxonomy „news“, then display your news header and news hero section. And if it has the taxonomy „general“, then display a different hero image. So this is a condition that you create on a post level. And now you need to take care of this on a site level. So essentially, you treat a site as a post. So a site might have a site option, a WP option, like we showed with Monday to Friday opening hours. We showed this example. So maybe a site now has pretty much the option to be a new site or a block site or this is the franchise package with my premium package that I’ve sold them. And this is the franchise case with my medium package or my basic package that I’ve sold them. So now I need to be able to create different contents for different kind of sites, and they need to be delivered to different sites based on these conditions. And this is where a new feature, that we’re currently building, comes into place. We actually provided customers with these features. Well, this is what we call „clusters“. So essentially… I want to show it a little bit, but I don’t want to dive into it. Let me share my screen. So essentially what you want to do: Now we’ve taken a look at Global Content and we’ve taken a look at clusters. So what for example I want to do is, I created a little test post type, just in this example. So essentially, what I want to do, I want to synchronize content to several sites. So I selected a couple of sites. And my network could be from different multisites in here. And essentially I selected five sites. So to these five sites I will be sending some content to. Then I now need to configure what types of content I want to send to the sites. And for example I select my destination. This is my root page and I select this post type and now I can create conditions. So for example I can filter them by taxonomies or limit the number of posts or filter by date. And what this does for you is, for example you can create all the German sites of your network and they only get the posts with the country „Germany“ here for example. Then you create another cluster where you say, okay, now all my Austrian sites, and they need to get all the posts with the country „Austria“ for example. And you can build conditions and make sure that your posts are distributed to each and every destination based on a condition. And then, what you’re doing is pretty much the same on the master site, for example. So in this case, this is my root page, everything is routed here. And now I can go ahead and just create different posts, different contents, and link them to categories, to countries, to tags. And based on these linking to different properties, pretty much those will be distributed to this cluster
and will be distributed to that cluster. And so you can manage conditions on a global site-wide level
and not only on a, on a post-wide level. And this comes with a lot of features. Like for example, posts can be reviewed before they’re distributed to each and every site. Just quickly showing this without getting too deep into this. So for example I have reviews in here where I can approve that my test posts are going live. I can revert them as well. Ad then I can take a look at how and where are they’re distributed. So you can see all the posts. This test 3 post that I’ve just reviewed, is distributed to all those destinations. I can see the an overview of this. So just to dive into what we’ve built there, because now you don’t only want to look at posts and conditionalized templates, but you also want to look at sites and kind of show contents based on site properties, which is a totally different level that nobody else really tackles right now.
Sandra: And you could also apply this to your website as a service offer itself. So for example, if you’re not talking about a franchise case, but again, on the agency case, for example, you offer optional services
like, I don’t know, additional monthly sets of templates. And this is an optional offer in your website a service. And you could for example build clusters with all the sites that this service and then roll out the new templates just to these websites. And then have other clusters with all the clients that don’t have that service.
Jakob: Yeah, perfect example. Yes.
Jessica: Yeah, that’s pretty cool. It gives you like, more inspiration to dig into. Like, what could I potentially offer with a website as a service model? Like what? Now you can like create kind of packages and then sell them to different tiers or something like that. Before we wrap up, do you have any other tips that should be considered when building a website as a service, like anything that maybe should be given a thought?
Sandra: Yeah. Actually, I’d like to include two more things that you should consider. Depending on the website
as a service model we’re talking about, whether it’s an inter-company, in-house website as a service business
or this agency case where we have lots of customers. You may also want to think about how to automate as much as possible the entire selling and invoicing process. So for example, you would maybe you want to think about being able to sell your website as a service on a website. So, I have either a shop solution or something subscription-based, like Chargebee for example. Or maybe even a form with a direct checkout opportunity. And then you also have to make sure that all the invoicing processes and everything money-
related is automated as much as possible. Because if we are having lots of customers, that’s something
you definitely shouldn’t underestimate. Especially if we’re talking about selling the services internationally and you have all these tax issues. Jakob, I think you know what I am talking about, because you’re the one having to deal with all that on a technical level for us. So that’s one thing I’d like to add.
And the second one is, if you’re thinking about which tech stack you’re using. I mean, we’ve talked about different solutions, different tools today. My recommendation would be to really think hard about what solutions you build your website as a service on. I mean, you know, our approach and also our recommendation for all people doing business on WordPress is staying as close as possible to WordPress core or to go with solutions working really close to the core. Because imagine creating this flourishing website as a service business with thousands of customers and websites, and then after 2 or 3 years
the page builder you’ve used for it goes out of service. What happens to your business then? So this is something I also would like for you to have in mind and to consider.
And before we wrap up, I’d like to include one more topic in today’s conversation. Because what we haven’t
actually talked about yet is pricing. Other than that it’s a revenue-based approach. And I’d like to share
my screen this time. Because if you manage to create this scalable and highly automated and standardized WaaS platform, what also comes out of that is that you will be able to offer your website services at very attractive costs. Because let me show you what happens here. I have a chart here and you can see that, with regular website projects, with the more websites that are included in such a project, obviously the higher the price gets. So if we have a project with 300 websites, 600, 1,000, whatever, the price increases more or less linearly. There’s a linear curve here.
Jakob: Yeah, because you have to build the sites, right? You have to build each and every site.
Sandra: Yeah, exactly. I mean, for each and every website you need the same resources, you have to set-up everything and all that. I mean, there may be some some reductions at some place, because you can bulk edit stuff or there may be some streamlining opportunities. But it’s more or less a linear curve. When you have a synchronized, an automated platform instead, you may have some higher initial cost because the entire setup is a little bit more complex than in a regular project. But then… I mean, obviously there’s still an increase. The more websites that are included, the higher the cost get. But the curve is way lower than in this approach. And it might even become a little bit more clearer if you take a look at it from a cost per website perspective. Because as Jakob said, with a regular approach the cost per website is more or less the same for each and every website. Because you have the same resources, you kind of have to start from scratch. There might be some savings, because you can reuse some elements and copy & paste stuff. But at some point the price per website more or less always stays the same. If you have this synchronized approach, then what happens is that the first free few websites, they might be a little bit more expensive, because you have all this initial setup, going on. But then you will be able to offer your website at a really attractive packaging price. And for you it doesn’t really make a difference anymore if it’s 300 or 600 websites, because you have all this automation, streamlining and standardization going on. So that was something I wanted to include here.
Jakob: Yeah, I like it.
Jessica: That was some super interesting insights on the pricing side as well. I think this is something we might not talk too much about, because pricing, money is not the greatest thing to talk about. But it was a very interesting. Do you want to wrap up a bit on what we have covered in today’s episode?
Sandra: Yeah. Happy to do that. So what did we discuss today? We discussed that there are very different
forms of website as a service. So it’s not just the case agency offers website templates to customers. There are also lots of interesting cases like franchises, partner websites, whatever, so also inter-company websites. So, if you as an agency think about WaaS, not only consider building a WaaS for yourself, but also think about how you can build these cases for others, because that offers you really interesting ways to grow your agency
and to take on really big projects. Then we discussed, what do we need for a website as a service? Which is, I’m going to repeat myself, it’s a lot about automation, standardization, streamlining processes. We talked about making assets reusable, maybe even connecting them with each other, synchronizing them with each other. We talked about having a central place from where you can manage all your websites centrally,
including all the maintenance tasks like monitoring, backups, all these updates and stuff like that. We talked a little about the different setup possibilities like multisite, not multisite, what to consider here in the hosting. And we also talked about how this approach not only changes the way you build these websites, but also enables to create a completely new offer, to offer your websites at a very attractive price.
Jessica: Cool. Thank you both, Sandra and Jakob. That was a super interesting conversation we had here about websites as a service. I hope everyone listening got some new insights today. Let us know in the comments if you have any further questions or just want to share your feedback on websites as a service. And before we wrap up, in the next episode, we will have another guest: Agency owner Rosanne van Staalduinen of Buro Staal. In this episode we will talk with Rosanne about a topic many agencies have on top of their mind: Shall I switch to Full Site Editing? We talk about the When and How and Rosanne can share some of her insights doing exactly that overnight. So tune in to the next episode to listen what her reason
was and what she learned. Bye.
Jakob: Bye.
Sandra: Bye.
[Music]
Key Takeaways
Website-as-a-Service (WaaS) umfasst in der Regel die Erstellung von Website(s) sowie fortlaufende Dienstleistungen wie Hosting, Wartung, technischer Support, Backups, Updates, Performance Optimierung, Content Management usw.
Es gibt verschiedene Formen von WaaS-Geschäftsmodellen. Agenturen können nicht nur selbst WaaS anbieten, sondern solche Modelle auch für Kunden aufbauen. Beispielhafte Kundenfälle sind unternehmensinterne WaaS (z.B. Franchises) oder WaaS als Teil von Partnerprogrammen.
In der Regel gibt es eine laufende Gebühr, manchmal auch eine separate Set-up Gebühr.
Der Schlüssel zu einem erfolgreichen WaaS-Geschäft ist die Automatisierung, Standardisierung und Verschlankung von Prozessen. Auf diese Weise ist es möglich, Tausende von Websites zu einem sehr attraktiven Preis pro Website anzubieten.
Für Agenturen bietet dies die Chance, Großprojekte zu übernehmen, die normalerweise nur sehr große Agenturen durchführen können.
Empfehlungen für den Aufbau eines WaaS:
Arbeite mit wiederverwendbaren Elementen und einem komponentenbasierten Ansatz (z.B. Patterns, Full Site Editing & Dynamic Templates)
Ermögliche die zentrale Verwaltung aller Websites (z. B. mit Multisites und Website-Management-Lösungen)
Verbinde die Websites auf eine Weise, die es dir ermöglicht, Änderungen oder neue Elemente auf einer beliebigen Anzahl von Websites gleichzeitig einzuführen (z. B. mit Global Content)
Ermögliche sowohl lokales als auch zentrales Content Management
Automatisiere und zentralisiere Backups und andere Wartungsaufgaben (z. B. mit Tools wie WP Umbrella, über deinen Hoster, etc.)
Finde eine Lösung, um Updates deiner Websites zu zentralisieren (z. B. über Multisite, containerisierte Website-Lösungen,
o.ä.)Skalierbares Hosting ist unerlässlich
Das Set-up hängt stark von der Art und Größe deines WaaS-Systems ab
Automatisiere am besten auch den Verkaufs- und Rechnungsstellungsprozess
Links
- WCUS Showcase Day Präsentation zum Fitness Franchise Case
- Informationen zu Greyd.Hub
- Informationen zu Global Content
- Informationen zu Dynamic Templates