MarTech WebSesh: How Greggs Revolutionised Their CX

Greggs is much more than their pastries. I know, it's hard to believe. But (sausage) roll with me here. 

In fact, along with Storyblok, the bakery chain has reimagined its CX and optimised its workflows, all with the power of a CMS.

So, if you were lucky enough to catch our WebSesh with Katie Adams and John Skitt, number one, enjoy your sausage roll, and two, you'll have heard all about the details in and around Gregg's customer experience. If you missed it, you're still in luck. We're jumping into a recap, right now.

Why Gregg's Decided to Go With Headless Technology

The main question is this: what was Greggs looking to effect from a change? 

When the Pandemic hit, we has problems to solve as every other business did. That meant a lot of investment into our technology...like our click and collect site"

- Katie Adams, Frontend Developer, Greggs

As a result, the company started looking at what other areas they wanted to focus their attention on. And what is simultaneously interactive, brand-focused, and socially distanced? A well-crafted website, of course. So, the customer-facing click-and-collect website became a priority for the team. 

This meant a few decisions had to be made regarding the stack, I.e. the technologies they needed to utilise when producing this brand new website, one important piece being the content management system. 

The team looked at a couple of different options, as they had their framework of choice for coding, and the website selected already. So, this made the decision process around the CMS a little bit easier. Some content management systems just went hand-in-hand with their framework - and Storyblok's was one of them. 

As a member of a development team, there are a number of technical benefits from moving to headless, and the ability to take advance of the enhanced interoperability of a headless CMS. 

Katie and her team found that, on the original website, a convoluted process was slowing everyone down. They found that content wasn't updating very often, and when it did, it was via the agency that had developed their website. This meant that there were frequent, and annoying, delays. 

sss

This is where Storyblok's CMS stepped in. This process was sped up massively, as the content team could go in, change pictures on the fly, and see how things look and how they work with the content already available to them.  

One of the main benefits of moving headless is to provide the flexibility and freedom of choice to the development team"

John Skitt, Account Executive, Storyblok

A CMS saves any team the headache of a bloated creative process. A content team is able to take the creative aspect into their own hands, not having to go through multiple teams to make decisions. Plus, this also takes a weight from the shoulders of the dev team, letting them go back to what they know best.

 

In other setups, I hear words like "nightmare" or "real pain" to have very small updates to make to the site. So it's really cool that you guys have been able to bring that more in house and benefit from the flexibility in the enhanced workflow of having ownership

John

But just a quick diversion. Let's make like a bad best man's speech, and start with some definitions. 

"A headless CMS purely means that the CMS can exist outside anything else that is dependant on it," says Katie. 

You've got the API sat in the middle between the Greggs.co.uk site 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. 

MarTech WebSesh: How Greggs Revolutionised Their CX

So, by having a really modular approach to their development, Greggs knew that all the content, all of the media, could sit in one place. It also meant all the media could sit in one place, and the devs could stop worrying and get on with the code side of things. 

It also worked in a similar way on the other side; the content team could just focus on the CMS. They didn't have to worry about tinkering with any code. Everything could be very separate, which aligned perfectly with how Greggs' development was going. 

This allowed the team to tap into everything as it was needed, which meant the CMS fit nicely into how they were working already. This meant that when they set up the website, they could access the content as, and when, it was required. So, luckily for the right-brained content team, they could avoid seeing code every time they wanted to make a change. "It was less terrifying," said Katie.

Why Greggs Chose Storyblok

"The big one that we were sold on was the live previewer," Katie notes. 

The big selling point for a CMS is often its ability to provide flexibility, ownership, and ease of use for a team. So, this is where the live previewer came in. 

"We've always had a lot of fun developing with Storyblok, and it's about making sure that it's as fun for everyone, as it is for us.

(…) There was just an insane amount of customisation we can do"

Katie

For example, the team could go in, and tell a component exactly what it needs to have. So, when a request comes in from another team, or another part of the business, they have the ability to go away and think about how they want the CMS to feed into the plan.

So, if they want different pictures, showing different times of the day, they can ask: "where did we do that? Do we store that in the code? Do we do that in the CMS or is it a bit of both? Then, it might be that the team uploads three pictures on the CMS, and pull the assets as necessary. 

But from a content perspective, not much changes. Which is what we like to hear. The team is still uploading three pictures for the three times of day. Many interesting problems and different use cases can be solved by just having the flexibility to make these components accessible, utilisable, and easily available.

Another selling point for the bakery franchise was the release plugin, which their content team utilised to full effect. It meant that they had the chance to make content changes in isolation from live content on the site. 

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"

-  John

How is Storyblok Being Used Within Greggs?

So, we better start with what a day-to-day looks like for Greggs. The content team goes in to post news, for which they need a bunch of assets to choose from and put on the page as they see fit. Then they'll create the news article, put in all the content they need, and go through the approval process. 

So where we've had big announcements like the Primark collaboration…we've been trying to put out news articles, and 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.

Webhooks have been another revelation for Greggs. This means it doesn't involve any dev effort at all for the content team to release, well, content. "Our site's statically generated, which means it's really, really fast," says Katie. "But it does have the downside of not constantly checking for updates, that's where the performance benefit comes from."

So, when the team hits go live, when they publish the content, the webhooks tell the website that there is new content available, and regenerate, so the new content appears. This keeps the whole process clean and speedy. It also means the content team aren't dependent on the devs.

Using a CMS, specifically Storyblok's CMS, meant Greggs gained a number of different benefits. But one stands out in particular. Both teams get to concentrate on the things they do best, and concentrate on doing them at the highest level, with the lowest amount of friction.