Case Study: How Greggs revolutionised their CX

Carlos Doughty 0:08 Hello welcome everybody joining us today we are here for another fantastic MarTech web session. For anybody doesn't know me, I'm the founder and CEO here at MarTech Alliance and I will also be your moderator for the day. Today's session is going to take a deep dive on how grids revolutionise their customer experience a really fantastic session we've got lined up before we jump in, I want to say a very big thank you to story block for making this possible without them we couldn't find run an amazing educational sessions such as this. Now joining me today is Katie Adams, front end developer at Greg's. Katie welcome. Hello, thank you for having me. And also we have John Skitt's account executive at story block. John, welcome.

John Skitt 0:55 Thank you, Carlos. Great to be here. Hi, everybody.

Carlos Doughty 0:58 So I'm going to give everybody a couple of minutes to find their books and zoom seats, but a few things to shout out. So I won't do any spoilers and give too much away about what's going to be discussed. What we'll say is don't be shy. Do throw your questions in on the wait. We've got a fantastic chat between Katie and John. But also we will be doing a 15 minute q&a at the end. However, don't wait. If you have questions as different discussion points popping up. Jumping at the bottom of the stack the bottom of the screen you can see the q&a section. So don't be shy. Drop in there and we will pick out the best questions to the answers. Also a little reminder that we will be giving away some amazing breaks sausage rolls as part of this. There was somewhat of a lot of hype fair to say that Greg's has some amazing food but this wasn't girls assembled recognised here in the UK. I was trying to explain it funny enough. Somebody in Spain and I said sausage rolls in the UK are the equivalent. We'll get that in Spain was our best definition. But enough about sausage rolls. Let's talk CX so with that, I'm going to hand over to John and cating. Over to you too. Thank you so much.

John Skitt 2:09 Thanks. Thank you, Carlos. Thank you, everybody for joining the session today. And Katie I'm really looking forward to to getting into some details in and around Greg's your customer experience. For the benefit of ourselves and also our audience. I figured it might be good to run a quick, brief high level agenda first before we before we jump in to what we're planning on discussing today. It's the reasons why Greg's was looking to make a change the problems that had been identified and why they were important to change it at the time when decision was being made around the CMS content management system. And then from there, wide rates decided to go with headless technology. And also further on from that white Greg's Joe storyblocks as it as it CMS moving forward and then really looking forward to having a look at how storybook is being used within race. Towards the end of the presentation on the call tonight. Yes, sounds good. Excellent. So yeah, I know Katie, that from from our conversations that you weren't sort of super heavily involved at the early stages of the decision making process, but what are you able to share with us with regards to what was great to look into effect from from a change?

Katie Adams 3:39 Yeah, so like John says, I wasn't massively involved at the time. And that was credit to one of my colleagues, Josh force, who was essentially first boots on the ground. When the pandemic hits we had problems to solve as every other business edge. And that meant a lot of investment into our technology and things like our clicking collect site. So off the back of that we then started looking at what other areas we wanted to focus our attention on. And the brigstock co uk customer facing website was the big one, really. So the decision that we had to make them was the stack that we wanted to use. And by stack I mean, what sort of technologies did we want to have when we were producing this brand new website, one of which was content management system. We looked at a couple of different options because we kind of had our our framework of choice for coding and the website selected and that made the decision process around the content management system a little bit easier. Some content management systems just go hand in hand with with our framework really and storyblocks was one of them. So we did a couple of proofs of concepts, looking around and then the decision was made we were in quite a lucky position really where the balls in our court, we were able to assess all the best options and go back to the business and say hey, this is what we think. And these are the reasons why and Starbucks just sort of ticked a lot of those boxes for us really

John Skitt 5:12 awesome. And obviously as a member of the development team. There are a number of technical benefits from moving, headless and taking advantage of the enhanced interoperability of a headless CMS from a from a content team perspective. Are there any particular drivers that members of the marketing team members of the content team are really looking to achieve with with a change?

Katie Adams 5:44 Yeah, so with our original website, one way back when what we were finding was that content wasn't really updating very often if we did, it was via the agency who had developed a website for us, which meant that sometimes there was that delay. In that. You send it off email and say, hey, we'd like to put this picture on our website and they say, Great, yep, no problem. And you just kind of have to wait for that to happen with having our own CMS, specifically with story block as well. That process was sped up massively, content team could go in, change pictures on the fly, see how things look to work with the content that they have available to them. And you can preview it on the website. Really? That meant as well that they could go away to other members of the business and say, Hey, what do you think about this picture here? What do you think about this font style this colour? And really just just get hands on with the website and see what worked best for them? And it was, I want to say groundbreaking really, we've not really had such a hands on approach before and we've been trying to work as closely as we can with the content team to make sure that they're always happy if we can accommodate things and make sure that we are making the best use of the flexibility that the CMS has given us now that we've got it.

John Skitt 7:11 Very similar experience that we hear from from a number of our clients. One of the main benefits of moving headless is to provide the flexibility and freedom of choice to the development team. Whilst also ideally delivering best in class experience for your internal stakeholders, not least the content team who in other setups I hear words like nightmare or real pain to have very small update to make to the site. So it's really cool that that you guys have been able to bring that more in house and benefit from the flexibility in the enhanced workflow of having ownership and again, not to go too, into two technical level, and I think we've touched on it a little bit. But specifically with regards to it to a headless CMS. What sorts of benefits are you aware of that the team had identified? That that you would be able to enjoy as an organisation by looping in this direction?

Katie Adams 8:27 Yeah. So as a kind of high level definition of what Don means by headless a headless CMS means that the CMS can exist outside of anything else that's dependent on it. So for example, in this case, we're going to look at a UK website. And you've got the API sat in the middle between brigstock code at UK and the CMS. It's almost like a bouncer at the door of the CMS who gets to decide who gets what data, you know, who's allowed what and what comes back out the door. So by having that we had a really modular approach to our development, we knew that all the content, all of the media, which could be in one place, we didn't have to worry about that. And as devs we could just focus on the code side of things and that worked really nicely for us, as well as that it meant our content team could just focus on the CMS they didn't have to worry about tinkering with any code worried about what impact it was going to have. It was very separate, which aligns really nicely with the way that our development was going within RX as well. You know, the the pandemic kicked off the development of collect, which meant we had to take a really big look at how we wanted to develop things. And we had a couple of API's for managing our shops for managing transactions just as like examples and things have been changing since then. But we've kept that modular approach. So everything just exists in its own right, and we tap into it as needed. So the CMS just really nicely fit into the way that we were working already. We set up our website and then we'll just tapped into what content we needed. We tapped into the images that we wanted to pull out. And it made sense as well for our content team and that they weren't having to see code every time they wanted to make a change. It was it was less terrifying. nightmare for them.

John Skitt 10:26 Yeah, that's awesome. Thank you and we're seeing a lot of organisations move in this sort of Mac direction at the moment and that Mac acronym is micro services. Again, sorry for sounding too technical here but micro services API first cloud based SaaS and headless provide very high level of non technical perspective. The benefits to business really are being able to pick and choose exactly the type of service that you will need for your business case, and that they all communicate nicely and interact mostly via the API layer and deliver a great experience through to the reach of the end user. Take taking that next step and so great to realise that they wanted to have more control, more centralization over content activities, was already moving as an organisation in this modular microservices approach. And then for a headless CMS fits nicely in with that. Moving on to story what in particular, in terms of your awareness, what are the key features that that were identified that that helped to make that decision?

Katie Adams 11:38 Yeah, so the big one that we got scored on was the light previewer It was sort of we've always kind of had a lot of fun developing with story block and and it's about making sure that it's as fun for everyone as it is for us. And so when I went in and was told we're going to think about using story block, see what you can see what you can pull out, I think what I made was, this is really showing my colours like a dice selling website for like Dungeons and Dragons dice. But I remember demoing it sharing my screen and just changing things on the fly guy. Look at me if I can just change the title to be like hijack, and everyone was mind blown. So that was our biggest selling point. tripling on further from that. There was the just insane amount of customization we can do that defines a button is the god button. You go in and you can tell a component exactly what you want it to have. So when requests come in from different parts of the business saying, can we do X, Y and Zed we can kind of go away and think about how we want the CMS to feed into that. If we want different pictures showing different times of the day, where did we do that? Do we store that in the code?

Do we do that in the CMS or is it a little bit of both? You know, it might be the case that you just upload three pictures on the CMS and we pull those when necessary. Or we put all three pictures and we show them differently in the code. But from a content perspective, nothing changes. You're still uploading three pictures for morning, evening, afternoon, wherever you want. So there were a lot of different use cases and interesting business problems that we could solve just by having the flexibility to make these components whatever we wanted to make them really so content could go in they knew they could do the same thing that they normally do. Nothing would look any different and they could see those changes happening why on a preview of the website as they did them. Another big selling point for us was the releases plugin, which we've got to play around with a lot more since we've let the content team go wild on it. And it basically just sort of it's to do with our ways of working. It's been a big learning curve for all of us really but it means that the content team can go in and they can make content changes in isolation from live content on the website. So they can go in and kind of branch off what's already there, and then make their changes and merge them back in so they can test and preview and tinker with whatever they want really. And then when they're happy. It gets previewed by someone else it gets signed off and merge back in. And as we've started working more and more with that it's it's really really worked for us. news pages are sort of going live since we built that feature out and they just looked fab the more that they learn how to use the CMS and we learn more about what we can do with it.

The more exciting things are coming out on the news pages and things we're playing around with fun decorations on the page, different layouts almost trying to map what we can do from a code perspective and see what powers we can give them on the CMS as well. So you know, without necessarily teaching the content team how to write code without knowing it, they kind of are in if they use, like a grid on the page to lay stuff out there. They're using all the CMS we've set up in the code. So building that rapport building that relationship with content team, with our content teams, Nikhil, Nicole and Steph, shout out to those two building news pages basically every week yeah, that relationship is just ever growing. Yeah, those were the big three I think which some we found the beginning some we found as we've worked with it and learned how it goes.

John Skitt 15:48 That's awesome. I haven't heard the story about you going in and building a concept for so thank you for sharing. And with regards to it being a sort of a change in thought process or a changing approach or attitude. We speak with a lot of organisations and we can see that it's it's perhaps a little bit of a paradigm shift. That some some organisations perhaps might not realise the true potential that's available by way ahead looks not just to storyplot but moving in headless direction. One of the things that you guys have definitely identified is the interoperability that you need to be able to integrate different features and functions with with regards to story blocks, obviously the visual editor that we've got up here and I'm still trying to see if I can get up there for the trainers, but I've not got any just yet. The visual editor is obviously a great place are the plates that come content, team members benefit the best from from storybook as a headless cms. The Godfather might not necessarily be available to all content team members, but this is certainly a place where which enables the parallel I have work of, of your team and the developers in the content team to happen. So once this environment is defined, yeah, exactly. This is where the space that we've built the content team members to be able to come and do their work. See that preview in real time because it's connected to the front end of the actual website, although it's not necessarily published, and then work through those those customizable workflows with custom user roles to be able to align with with internal processes. But fundamentally, it can be that a content team member could come in, build something, push that all the way through, or all the way through the content team to publishing without not so much as a Slack message to them. Pretty much yeah.

John Skitt 18:00 And you mentioned that the new sites there. I mean, with regards to utilisation within rates at the moment, tell me a little bit more about some of the projects which which are very useful.

Katie Adams 18:13 Yeah. So predominantly on a day to day basis. Our content team goes in posts news. You know, we've been working with them to try and give them as many components under their belt in their library, that they can go and wrap on a page as they see fit. So where we've had big announcements like the Primark collaboration, or, for example, like when we've gone with our fair trade relationship and how that's done, we've been trying to print out news articles and yeah, that was that I think that was the first big project or the first big website feature that we put out that we then started to work closely with the content team. Once we've got the kind of news landing page setup, where we just call the API and say, give us all the news and put that out, and then we start working out. What do they want on a news page? So like the previous examples of titles, what sort of descriptions we saw, how many minutes does it take to read? And, you know, we were figuring out what they wanted that schema to be. And then yeah, sort of, took it under their wing and flew with it. So yeah, on a day to day basis, they they'll go in, they'll create a news article, they'll put in all of their content, and then they'll go through the approval process. And we've actually now managed to get it to use web hooks so that it doesn't involve any dev effort at all for them to go in and release that content. Our site's statically generated, which means it's really, really fast. But it does have the downside of not constantly checking for updates, that's where the performance benefit comes from. So for those web hooks, what it means is when they hit Go Live when they hit publish this content, it tells the website that there's new content there, and that regenerates it and then the new content appears keeping everything really really quick. But it means now the content team aren't dependent on us. We get to go and do what we do best. We've also had our gift card journey on your gift card God go live recently. And as is the way we've gift cards, and seasonal events tend to have all sorts of content update. So we have our Mother's Day difficult creatives go live around Mother's Day just beforehand. And the content team went in went onto the landing page and updated some of the imagery there to showcase for new creatives to showcase all new gift cards that we had. They hit save and hit schedule and that went live everyone. So yeah, couple of different ways on the website that they're regularly changing stuff.

John Skitt 20:56 Now it's really cool and it sounds like as your organisation has become more comfortable with with story block as a headless cms. The freedom the independence of the developer and the content team has has grown to the point where content updates have been able to make be made in a perhaps previously unimaginable fashion. And to go back to the just Site, site generation aspect, within you know, broadly speaking within a Mac architecture like a headless setup, there's a number of different ways of approaching site generation. And this, again, gives developers the development team the flexibility to help meet the business use case you know if you're updated their web pages every couple of minutes, compared to on a daily basis. Perhaps there are different approaches that can be employed, but it's really cool to hear that you guys are able to benefit from static site generation. So you're able to deliver a really fast product to the user. But when updates are made by the content team, then that regeneration happens at that point. So there isn't that there isn't a delay between you're able to benefit from static site, regeneration, regeneration, but also, as soon as content updates are made, they are reflected in the website.

Katie Adams 22:21 Yeah, it's been a very nice sort of parallel, most experimental relationship that we've had. You know, we're still always playing with the CMS and figuring out what things are possible. You know, sometimes I'll get messages from the call going, Oh, can we do it this way? And I go, No, no, and then I'll go have a play and we'll have a look. Yeah, sometimes things go awry. And then we'll I'll get a message on TV saying can we just have a look into that? And yeah, it's it's been it's been a lot of fun. It's been a lot of fun trying to figure out the different quirks and things and how we will work with the product together.

John Skitt 22:55 Well, that's great to hear. I mean, the the change which is happening in and around web architecture at the moment, everything's moving in a more microservices headless direction. This is all designed to give organisations the flexibility and the independence that they need to deliver. With regards to storyblocks our one of our main aims and key desires is to to deliver that but also to deliver solution for content team members and development team members where they're not sort of incrementally working towards updates that they're able to work in parallel, or budget in harmony of microseconds.

Katie Adams 23:35 Yeah, it definitely does feel like that. We're sort of working on new projects and building new components as needed. We work in an agile fashion. So we get to kind of iterate on things and keep developing as we go. But you know, if I have to take 10 minutes out, to you know, help someone build a news page and play with a new component they've not seen before. It's this good feeling. Yeah. Works really well.

John Skitt 24:00 Very cool. It's been really interesting to learn more about how storybook is being implemented with within breaks as we're approaching sort of an opportunity for us to jump into a q&a specifically from a marketing perspective, what would you say the biggest benefits the greatest has achieved? From taking story apart from taking efforts together?

Katie Adams 24:29 It's a tricky one. Because in truth, I'm not a marketer, and I couldn't go through I don't think all of the advantages but from a purely personal selfish respect, the improvement to our way of working and I've never developed in a way like this before before sort of our panel. It allowed us to focus our time in the most efficient way possible. You know, we are confident when a component is finished, that it can be used on the website that we don't really have to touch that component again, unless they want something new. So the experience overall on the website, I think feels quite fluid and feels quite nice. Everything's developed based on working branded components that can just get walked on a page as required really. So it's meant that our development process can be purely focused on making the website the best thing it can be. Obviously, there's the massive advantage of our website looks a lot better now than it used to be. We get control over what content goes out on it. How often that content updates. as well. So for again, the gift card example the fact that we were able to really push the gift card, the Mother's Day gift card designs, but is it feels a bit more focused a bit more targeted. So hopefully the conversions I don't know the data but hopefully the conversions on the back of that reflect that. And working with data in general you know, we're able to see what sort of impact the new journeys the new designs for things have. Yeah, and then as well as that we get to have this content silo as it were the singular source of truth. For all our content, it's huge into our new Greg's app, as well. There's elements of the content that are stored on the storage block, but just via the magic of API, the app is able to tap into it and if that content updates it's the same across the board, our branding just becomes a lot stronger. You know, we're not having to change things in three places within the space of 24 hours because something's changed. You know, we change it once in the datasource on story block and it updates across the board and that's very nice as well. Yeah, the

John Skitt 27:01 omni channel delivery is certainly one of the big drivers, I think for for headless. But it's it sounds like, you know, moving forward, and thank you for bringing up the app because that was one thing I wanted to mention. Sounds like you know, short term or initially, Greg has been able to benefit from deploying storybook as a headless CMS in terms of freeing up the content team and freeing up the development teams to focus on important stuff rather than just pestering each other. right the way through to to accomplish. So that's really, really cool and obviously there are there an enhancement to both internally and externally by going through that in terms of the future. Having that one source of truth having a CMS which can act as the only CMS for an organisation it sounds like you guys are already moving along the path to make that long term reality and it's great to hear that that content on the app is being delivered from from storage locker at the moment, and obviously moving forward. Another key benefit of moving into headless direction is that content which is built stored and managed within storybook can go anywhere, but Greg's desires into the future.

Katie Adams 28:20 Yeah, very much so. And it's been nice sharing that with wider parts of the business as well who maybe haven't had a chance to interact with it as well. When they come forward and they've got ideas for things. If we want to go away and tinker on on the CMS and then share something they come to your why you did that in an hour. It's a It's really impressive. And it just it speaks merit to the to the software that's been built up really. John Skitt 28:44 Yeah. And you know, this is this is the head that's gone from the headless content is still stored and organised in in a nice, clean, efficient way and managed in a clean and comfortable way, especially with storage locker, and our visual editor but then it can go wherever which again, I think, I think for organisations who are very used to some of the older CMS solutions out there, understanding that that content can now genuinely go to different places without being you know, a patch or a workaround in place which doesn't really hit the mark with a headless solution, that there are a whole new world of possibilities with regards to how content can be developed. That delivered from that one, one central repository. Yeah, yeah, definitely. Awesome. Well, I think that was all of the questions that that I had KTN and again, it's been really great to learn more about how you guys are using storybook and what the plans are for the future. So call us. If you're if you're already happy to come back to you and we can perhaps cover some questions.

Carlos Doughty 29:55 Then. Mostly of this, listening very carefully, just taking notes for myself. I know something about martech but certainly really interesting to find out more and especially sort of bringing to life what you've been doing at grips. I've got a lot of questions myself, but actually, I'm obviously not gonna be greedy. They've been firing in across the board. So let me jump in. Frozen your way. First of all, Nick was asking, Can you give an estimate of some hard metrics to describe improvement you saw what surprised you most?

Katie Adams 30:31 That is a really good question. I think the answer is no. Because I don't know that off the top of my head. Yeah, I really wish I had a better answer to that. I really do

Carlos Doughty 30:44 it. What surprised you most from the projects?

Katie Adams 30:47 Or? Pretty good question. I think

John Skitt 30:51 he's given you a moment to think if you like he and I'm going to use one of the standard answers from one of my favourite colleagues, a developer relations engineer here. And the answer would be that would be somewhat if not entirely dependent on how the platform is implemented in the front end. So I'm not trying to dodge the question here. At all. But how how we're headless system is set up. For instance, using static site generation really has a huge impact on on the end product. What I will say is we get lots and lots of organisations, especially universities at the moment who are coming to us because they want to deliver best in class, best speed sights. And by going with a headless solution, you can achieve that, but it is also dependent on how that system is implemented in the front end. So there's some lift music for you, Katie. I

Katie Adams 31:44 hope that's helped. Yeah, thanks. I guess what surprised me most was just how many options there were for things. We were using storyblocks. Not relatively, or not massively early on. But certainly for a v1 product. There was a lot of different options for things so one of the features that we had that we didn't play with initially. And then when we came to try and solve the problem, just tick every single box was data sources. Something really just as simple as key value pairs. We just need to store a list of things somewhere in the CMS that we can tap into and so we were looking around like Oh, do we build a service to store it in our like back end? And then just playing around with data sources and just going now I think that'll do to be honest and then realising you could then plug that into components and have that feed into some of the things that happen there. And it just, it really reinforced that single central source of truth idea in that once it's in the CMS don't have to replicate anything. We've just redone a little bit of work around our colours for our brand. So we had a nice colour palette. What we were doing was duplicating all the hex codes for that colour palette on a component by component basis. And a bit of work that my colleague Scott did recently was to put all of those hex values in a data source and then just tell each component to look at that data source and it just simplify things massively and it was just something that when we first started playing around with it, we had no idea existed and then we just got to playing with it and experimented with it and it was really nice thing to find was just that there's quite a lot of things there that do solve problems. You know, they have thought about things quite a lot. It would seem that concept

Carlos Doughty 33:35 of a single source of truth really rings true. I mean, you've worked and you've said, it sounds like there's just such a return on time. And sometimes we underestimate that value. And I think the big thing I got from it even saying today has been about that kind of empowerment is that you enable people to work better move faster, bring ideas to life. So I suppose it then enables teams to work better, more collaboratively, you know, the content team can move with speed. And they're not pulling developers away from what would be something perhaps quite easy for them to do but not empowering. And I think yeah, it's really valuable. We've got more questions here, though. Here's another one for you. Where did you go when you were looking to find out about swapping a headless CMS with traditional CMS? So I think this is really a question around kind of, sort of in the education piece when you were trying to understand the differences between the different types of technology.

Katie Adams 34:31 Yeah, so a really small bit of background about me when I first joined Greg's I was a very fresh face just straight out of uni. So I've just graduated, which meant my knowledge of headless CMS was what had written the textbook. So my only real experience with CMS at that point have been WordPress. For anyone who's used WordPress, they know it's really powerful, really good, that the learning curve can be quite steep. It's sometimes a little bit bloated. Sometimes it's almost just trying to do too much at once as well. And that's neither a good thing or a bad thing. It's just that's just how powerful it is. So when we were going for headless, I think what we were thinking was simplicity first, and then we can iterate on it and see what else we needed to do. So in terms of the basic needs, it was, can we get content from it, obviously, how do we develop with it? So with story block, it was all based on the idea of blocks or components, everything in isolation, and as already mentioned, that fit with our kind of modular approach and then we were looking more into the image service and how powerful that was the impact that that would have on site speed and performance was really good as well. And then just how, what's the word that I want? I'm not sure but just how good the API was really, and how flexible it was that we could tap into different parts of it and kind of get specific bits of information out there was a lot of flexibility there for us, which I think is the biggest perk of a headless CMS is because it's designed to sit without knowing anything else. About anything else that you're developing. It's very flexible, because it has to be.

Carlos Doughty 36:22 And that sort of leads into another question here, which is does any of this increase the risk of having a headless CMS in using an API between the two? So I suppose I think the question here is pointing out with that greater flexibility that you end up exposing some level of risk. And then

John Skitt 36:40 I'm happy to jump in here again, just just at the beginning. But the content delivery API is one way it's it's we don't like so if anything, it's more secure than perhaps other systems.

Katie Adams 36:55 Yeah, and pretty much to echo what John said all of our sensitive data we store within Gregg's and we apply all the necessary security to that anyway, so it's, it's just nice fluff that we're getting out really nice. Pretty pictures and good content for the sake of a marketing,

Carlos Doughty 37:15 which might also answer another question. That was a question here around. I've lost the exact question, but it was around kind of user management and access levels. Am I right in assuming given? I suppose you might have somebody with full access to really play perhaps on the developer side and then somebody were sort of more limited, just making sure they stay on brand.

John Skitt 37:34 Yeah, exactly. So they've got a defined schema, but it's a great one, but you don't you don't want to give everyone access to that because they can go in and do some of that you probably don't want them to do so. There's very granular controls with regards to user permissions. We support a lot of organisations who have lots of different international sites. And it's it's possible using the controls to be able to lock someone down to just be able to edit blog posts in French for instance, and so there's a lot of control around around user permissions within this system.

Katie Adams 38:08 We emphasise on the previous question as well, that was another area that impressed me was just how picky I could be with what people could do. And when we were playing around with that it was almost too entertaining to just lock my colleagues out of storyblocks and you can't do that anymore.

John Skitt 38:24 And always surprises me how much colleagues on the product team thought like, What would our clients want? Do they want them to be able to edit one field box or one field within one component like what what possible use case could come about from from that but but there it is.

Katie Adams 38:41 I mean, we had an exact use case for that, in fact, where we need to apply a very specific CSS class to an item in our footer. So it was easy done within store but we just added a field to that component to say put your CSS classes here. But just to mitigate the risk of the content team looking at it and panicking essentially, we decided that we didn't want them to be able to see it. I was like, I'm wondering if I can just go in and lock that down. And lo and behold, I was able to go in change the security role for all of our content team and hide that feels from them specifically. And I was like that is that is mad but wonderful.

Carlos Doughty 39:23 It sounds like there's a balance there between the enablement and the risk, right. And so you want flexibility for people to move with speed impact, but within sort of a constraint when safeguards especially from a branding perspective, I dare say, brands, especially when they're making specific changes is you don't want somebody going. Let me just go for the I'm sure this is the closest colour.

Katie Adams 39:44 It's quite good for guiding our ways of working as well. Because if we had a content team that was saying like 50 people big we could have sort of 10 people with slightly elevated powers go ahead and approve content. And the other 40 could only have the permission to make that content ready for approval. So they couldn't actually hit the button to release their content. They'd have to put it through one of those 10 Super people first. So it's been kind of good to be able to think about that going forward. Should we get someone else in content we can, you know, mitigate that risk with them accidentally putting something live and not meaning to

Carlos Doughty 40:23 talk about it sounds really powerful.

John Skitt 40:25 When it very much echoes our philosophy as an organisation you know, we want to provide a solution. We don't want to dictate a solution. So we want to we build in as much flexibility as possible so that client organisations are able to align the CMS to to the workflows that they want.

Carlos Doughty 40:43 Right, we've got a just switching gears slightly. We've got another question here. From different for sure. This story drop appropriate for companies without in house developer resource?

Katie Adams 40:53 Whoa, that's a good question. Speaking coming from a company who does have in house developer resource, I'm not entirely sure. I think it possibly wouldn't be but maybe Johnson best equipped to answer that?

John Skitt 41:08 Yeah, I mean, the quick answer is no. Definitely don't want to have people go away with a misunderstanding here that as a non developer, you can go in and use storybook it's it's not a page builder. It's not a monolithic CMS. However, it's been designed to be as flexible as possible. So you will need some development support in setting up the visual editor for instance, and providing those initial set of components from there on out. It should be a very low debt. requirement, but again, this is based on how you want to edit change components moving forward and how much change you've seen in the structure at the same time. So yeah, quick answer. No, we will need filament support, but how much is very much dependent on how you want to implement it using system

Carlos Doughty 42:01 and the understood, and to your point there, you could also just have development support upfront, set things in place, start using it and then lean into perhaps external developers as needed. John Skitt 42:12 Yeah, we've got an awesome partner network, so we'd always be happy to connect people with an implementation partner.

Carlos Doughty 42:18 Fantastic. Another great question. Yeah. Is it possible to do kind of geo targeting, in our in our use case? Due to different regulatory requirements? We're not allowed to show specific sections of the website in some countries.

John Skitt 42:34 Yeah, I can. I can grab that one. So we've got essentially three levels of localization within within the platform. And those are pretty much aligned to a large amount of use cases. We've worked with organisations who do have that high regulatory compliance in different territories. We've got what we've termed a space level localization, which, which can really help with that, too, depending on how different your international sites need to look and feel. We've got the solution which are two lines.

Carlos Doughty 43:10 So I think it's a we got slightly more technical question is from Jenny, I'm interested in how a microservices architecture affects the tracking. Does the use of different services mean that there's a risk of losing the structure of tracking insights?

Katie Adams 43:26 So if by tracking you mean something, like Google Analytics, I don't believe so. We've got a fair few number of colleagues at Greg's to monitor our Google Analytics and Google Tag Manager, things like that. It's just implemented pretty much in a similar way to any other static site, really, on Greg's and just choose what events to track same as you would elsewhere. The only caveat that I could possibly think of would just be with, you know, where you'd pop it in your code is entirely dependent on the framework that you choose. We went with you as our framework because storyblocks and viewport really listening to each other. So you know, once the project was set up, in terms of Google Tag Manager analytics, nothing was really different, or at the very least, it wasn't impacted by our CMS choice. No, I think that's fair. It's not done. Yeah, yeah. I

John Skitt 44:19 mean, from a from a very, very high level. microservices architecture of micro architecture. It doesn't impinge on on any any tracking or tracking at all. But that tracking and tagging will need to be set up in the architecture in the way that the organisation needs. It's something to be mindful of, but it's not something that will be negatively impacted by moving in this direction

Carlos Doughty 44:41 and the third and final question, I think Katie touched on this already. I'm gonna say, John, you might get this question quite a lot. So I'm going to fire this over to you, which is could you describe the sort of the key advantages or freaky advantages of WordPress versus kind of a headless CMS like storybook?

John Skitt 45:00 Yeah, sure. So I think being able to deliver content to all of the places that you need it to go as an organisation from one place is is a huge benefit of, of headless in general, usually within headless, we've got things like Visual Editor, and other other coffee features. So just broadly speaking, from from monolith to headless, that centralization of content activities, the future grouping. So, as Katie mentioned, our API's are very modern. And we always want to make sure that we're providing our clients with a solution in which they can plug into new channels moving forward so that whenever they want to launch an app or content on a wearable or via Alexa, that they don't need to be the CMS minutes. You've already got one. And then I think the last one specifically to story blocks is you can provide content editors with a similar experience that they may have with a monolithic system in terms of the visual editor. series, we see it. So it's something familiar. But behind this visual editor, you've got a very, very important headless system, which developers love and it's future proof.

Carlos Doughty 46:23 That's the Thank you. And that is all we have time for today. Katie, John very big, thank you for taking the time. I've learned a hell of a lot I'm sure everyone else has to. And I also want to say a big thank you again to storyplot for making this possible. Please do support us by supporting them. The team over there will be in contact. And if we run out of time, I didn't get to answer your question. Don't worry. So the storyblocks follow up with me directly. Thank you so much. A real pleasure.

John Skitt 46:54 Thank you, Carlos. Thank you, Katie. Thank you, everyone.

Katie Adams 46:57 Yeah, thanks. Everyone. Thanks, Carlos. Thanks, John.: