Name: Peak season, every season: Building a repeatable BFCM playbook
Uploaded: 2026-09-29T16:16:18.315Z
Duration: 53 min 44 s
Description: Peak season, every season: Building a repeatable BFCM playbook

Transcript for "Peak season, every season: Building a repeatable BFCM playbook": Alright. Welcome everyone to peak season every season, building a repeatable Black Friday Cyber Monday playbook. So let's set the stage. It's Black Friday. Traffic to your client's store is higher than usual, yet orders have barely moved. Something is wrong, and every minute you spend hunting for it costs your client money during the biggest sales season of the year. Over the next hour, we're gonna take a look at how to prepare your client stores well in advance of Black Friday and Cyber Monday to prevent issues from this happening. By the time you leave, our goal is that you walk away with a repeatable playbook. You can run year after year to keep your client stores running during this peak season. I'm Jeff Golinski. I'll be your MC for today. I've been with Automatic for a little over twelve years building products like Jetpack and wordpress.com, and currently, I'm the product manager at Automatic for Agencies, helping your agency grow. So today, we're gonna break down the webinar into three parts. Part one is gonna cover what is ready ready actually mean. Have agencies thought through every angle of peak season from marketing to site prep? How do you decide which stores need thorough testing, and what does that look like? We'll have a discussion with both panelists and then a ten minute demo of the Pressable MCP. Part two is gonna cover peak season strategy and workflows, getting the the store itself around and the campaign around it ready, and how much of that work you can hand to an AI agent. We'll have another discussion and demo some workflows in the WooMCP. And then finally, the third part, we're gonna take your questions in a q and a. Just to note, in the top right of your screen, you're gonna see a chat dialogue and a QA dialogue. As we go through the webinar, drop your questions in there, and we'll get to them at the end. And just noting that this webinar is being recorded and will be sent to you after the show. So before we dive in, let's welcome our panelists. First, we've got Steven Sauter. Steven is a senior solutions engineer with more than fifteen years of experience building with WordPress. Prior to Pressable, he led an ecommerce agency with about a 150 clients. Next, we've got Brent McKinnon. Brent leads product marketing and developer advocacy at WOO where we spent about seven and a half years. A lot of his work is around connecting what the platform can do with what merchants, agencies, and developers need to run their business successfully. And then finally, doing our woo demo today is Brian Kords. Brian is a developer advocate in woo on with with WooCommerce and a WordPress contributor. Before that, he spent a decade working at woo, WordPress agencies and currently focuses on education to support agency workflows with WordPress and Woo. So let's start by looking at the weeks before the sale when there's an opportunity to discover and proactively fix potential problems. In October, clients generally start asking if their site is ready to handle their most important sales days of the year. Depending on who you ask, that could mean a ton of different things. So let's start there and determine what ready actually means before you go in and tell clients their site is good to go. So Brent, let's start with you. Our goal today is a playbook agencies can run every year. So the calendar. Let's focus on that. When should prep actually start for an ecommerce client, and what should be happening in each of those weeks? What's the point where it might be too late to fix something? Good question. I mean, we we run or historically have run Black Friday sales even at WooCommerce, so I've been around a a few of them. Honestly, I would start, like, eight or ten weeks out if you can. And I would start, not actually even thinking about the site right away. I'd start by agreeing on what the business wants from the sale. So, like, what will be on sale? How large will the discount be? How many visitors and orders should we expect? How much stock is available? And then in terms of fulfilling those orders, how many orders can the team pack and ship reasonably? Like, is the business ready for the sale? And then I would start looking at the site, checking the the site itself, hosting payments, any plugins or services that the store relies on in three or four weeks before the sale. I'd go through the whole experience as a customer. So every step that a customer would take to take advantage of the offer you're putting out. And then in the final two weeks, I would stop making changes, altogether. I would test everything again. I'd make sure everyone, at the agency side and on the client side knows what to watch, who will handle any problems that come up during the sale itself. And, realistically, given that sort of two week, shutdown time, I'd say if there's not enough time to test a specific change before it goes live, it's probably too late for that change. So I focus on keeping the checkout and the orders working above all else. Yeah. That's great. So is there anything that you find that agencies might forget about until it's too late? Is there, like, one thing that's often overlooked? I think it's running the complete test. It like, sometimes they'll they'll leave the the full flow too late. Like, someone needs to if they're gonna take advantage of the offer you're putting out, they need to see an email or an ad or see you on social. They need to click that. They need to visit the sale page. They need to add the product to their cart. They need to use the discount and pay and receive an email, and we need to make sure that the order reaches the people who will pack and ship it. And that's a whole flow that you need to make sure every step of it works along the way. And usually doing that full flow is when you find out that there might be problems between the marketing, the store, the payment provider, the team handling the order. It's also when you find out whether you have a plan in place if anything goes wrong at any of those steps. So you need to know who can pause the ad, who can fix the discount, who's gonna tell the customers about any of the delays or any problems. So running through a a live, look at what will this feel like end to end is something that people often leave too late, and it's where you can catch most of the problems. Solid. That's super helpful. So, Steven, you ran an ecommerce based agency, so I'm sure you've been on the side of this where the clients reaching out to you. And I'm sure they're a little nervous sometimes before the big season. Right? When you're looking at a whole book of client stores in early October, what do you check first? How do you decide which stores get a, like, a deep audit versus a lighter audit from the technical side of things? Yeah. That's a really good question. Your, your intro took me right back to, like, prepping for Black Friday for for many years because it really is kind of like that one event that can make or break, sales for a client. No stress. Right? That's not stressed at all. But when we would approach a large portfolio, you don't have time to do a deep dive into every single site. But, generally, where I would always start is with your gut. You've been working with these clients over time, over the year or years, and you kinda have an idea which sites are already problematic. So start creating a list just based on, like, your gut instinct. I think the second thing that's really important is diving into the metrics. So being on a hosting provider that provides those metrics like Pressable, we have a whole metrics tab that shows you CPU usage, what's happening in the database, and you can get a really good idea of how the site is currently performing and if there's any anomalies that you're seeing. And if you're seeing something where, like, as the site in its current state is already using a lot of its resources, that's probably something that you need to check into so you're gonna be able to handle that huge volume push. And then the other metric that I always think about is how many x growth of checkouts are you going to see over Black Friday? Like, are we talking one to two x? That's not that huge a change, but some stores see five, six, even 10 x the sales, and those are stores you really wanna dive in a lot deeper into. Solid. So let's, let's look at that checklist we're talking about here for the playbook. What belongs in that checklist that you can reuse every year versus versus something that might didn't need to be custom every year in terms of the site audits. Yeah. So, generally, I start by looking at the CPU usage and PHP worker usage. Always have that on my checklist to see what the site is actually doing. Caching metrics is incredibly important because when you're talking about a ecommerce site that's using WooCommerce, like, you can't really cache your cart. You can't cache your checkout. So if you can cache everything else, that frees up a lot of bandwidth for those carts and checkout pages to push people through at high volumes. So that's another metric that I always include on that checkout. And then, what Brent was saying is planning. Like, thinking through what's going to happen and make sure you have an idea of how you're going to handle situations as you arise. Because even all of your best planning, and you can have everything ready. Sometimes things just go sideways when, on a black fighter, a huge event like that. And having a plan for what you're going to do just takes a lot of stress off of you, lets the client know that you're being proactive. And so putting together that plan for how to handle those those edge cases, I always have that out of my checkup list. Yeah. Solid. Yeah. Preparation is really half the battle. Right? And the other half is what happens when something goes wrong at the worst possible moment. Hopefully, it doesn't happen, but it can. So, Steven, what do you think is, like, a good safety net for a store in Black Friday. from a safety net? perspective, like, one, a safety net has to be put in place before the thing happens, so you need to make sure that you have that safety net ready. From a hosting standpoint, especially, like, if you're on Pressable, and are a part of the automatic family, we help build a lot of that safety net for you. So, like, between, like, auto scaling or burst capacity on PrestaPull, where we'll ramp up the CPUs up to a hundred and ten and hundred and ten PHP workers. Like, we're ready to go to help handle any sort of edge cases that all of a sudden pop up. It's a failover server, so in case something happens to the server during that day, to Jetpack having, like, real time backups that can preserve orders. So in case, you know, you did push a new feature that maybe you shouldn't have pushed, you can roll it back. So having a partner that's there ready to go, and a support team behind it. So, you know, you're sitting there in front of your customer, but we're we have your back too in the support channel. So you're on, you know, Black Friday, something goes sideways. You can hop into support, ask us questions. We're right there ready to help you solve whatever is going on. But then having those just plans in place. Like, what would dictate you rolling a, backup to a backup? Like, what would cause that to happen? You wanna know that beforehand before trying to decide, should we do a backup or should we not? When should you make changes or alter things? Do you wanna push any code? Like, maybe there's a small bug. What that you could fix live. Like, is that something you wanna do or not? Having your team, and the team plan around that really just allows you to have that safety net so you're not ad hoc ing all of these things as things may be coming up. Awesome. So, Brent, similarly, for the store side version of things, what does that safety net look like for you? Steve made a good point. You've got Wu's customer support team ready to go as well, and we work well with Pressable's team. So if if anything goes wrong, you've got us. But one thing I would start with, if you're noticing, there's something going on with your orders or your payments on the day is going back to that chain of events and making sure you understand what's actually breaking. So the first thing you need to know is whether the customer is actually charged, whether. the store recorded the order correctly. So I would check the order in woo and compare it with the payment provider, look for orders that are stuck as pending or on hold, or failed. And then I would check whether the customer received an email from you, and whether the stock count changed. And you're looking for discrepancies along the way to figure out exactly what is actually breaking. If any of those systems don't agree, then I wouldn't go straight to, like, asking customers to pay again or restarting things, until you actually know what happened. And as far as, Steven's point about the safety net needs to be there before you start, some of that comes down to knowing who is gonna be around to investigate those things. Who can issue a refund? Who can fix an order? Who will contact customers? Who's gonna interface with who are pressable if you need support. It's more about having your your team ready to handle problems than than instituting a a bulletproof plan on the site then. Because things can go wrong, and when they do, you just wanna be ready to investigate what's breaking and how can we fix it. Solid. Super helpful. So let's dive into some fun stuff here. Next, Steven is gonna share a demo of some performance auditing on the hosting side of things. We're gonna take a look at measuring baseline performance, simulating some traffic spikes, identifying bottlenecks, and more using the Pressable MCP. So let's get into it. Hey. My name is Steven. I'm a senior solutions engineer here at Pressable, and what I wanna show you today is how you can make sure your sites are ready for Black Friday and Cyber Monday. Before I joined Pressable, I actually used to run an agency, and I can't tell you the amount of stress or sleepless nights that I had getting sites ready for Black Friday because that huge load that just all of a sudden shows up can wreak havoc on a site that is not ready to go. But through Pressable, Claude, and Pressable's MCP, you can streamline that and make it incredibly easy to figure out how your site is expected to perform as you're throwing a lot more traffic at it. So we're gonna be looking at the site here called Kibble Standard. And Kibble Standard is a dog food company. They are the gold standard of dog food. They have a bunch of different dog food products. They have a loyalty program called Good Boy Bucks, and we wanna make sure this site is ready to go for the traffic that we throw at it. You can see that we have a just a standard WooCommerce setup in the back end. With normal traffic, this site gets 10 checkouts per minute at its peak. But with Black Friday and Cyber Monday rolling around, we know from historical experience, we can see that go from 10 to 40. So four x what is normally happening. When I start diving into a site to make sure it is ready to go for Black Friday, where I like to start first is the metrics just to get a really high level overview of what's going on. First, diving into the traffic metrics just to see what's happening on the site, but things start getting a little bit more interesting as I get into the caching metrics. You can see from a cache standpoint, we have 1% of our requests being cached. That seems like a bad thing. It's actually not because almost all of our cash is being served from the edge. You can see here almost 70% is being served right at the edge. We have about a 21% bypass right now and 6% stale. Now this is about pretty typical for what I see for WooCommerce sites because there's so much traffic that can't be in can't be cached like the cart and the checkout page. The next thing that I like to look at is the CPU metrics to see what's happening from a PHP workers standpoint. This is one of my favorite charts to look at, seeing the max amount of PHP workers being used and the average amount of PHP workers used over time. You can see our plan right now has 10 PHP workers. Now the great thing about Pressable is we allow you to go into burst mode. So if you need more workers, we'll automatically give them to you. But a good rule of thumb is to use burst capacity for the unknown, for any traffic that comes that you weren't anticipating. Let's say something goes viral or gets picked up by a news source. That's what we wanna use burst capacity for. We wanna make sure that our site is sized correctly and can handle the traffic that we are planning at throwing at it. Alright. So let's dive into the Claude and try to calculate exactly what's going to happen to the site during Black Friday and Cyber Monday. So the first thing I like to do is ask Claude to grab all the stats and data and kinda make a chart for me so I understand where I need to start focusing my attention. So I told Claude to grab a PHP worker usage database stats, PHP errors, and that we are looking to see what's going to happen when we go from 10 checkouts per minute to 40 checkouts per minute. So Claude went out, crunched all the numbers through the pressable MCP, and gave us this great chart that we can quickly scan through. We can see that edge cache is exactly what we thought it would be, and even Claude picked up that that 20%, bypass is pretty standard for a WU site. It is picking a few concerning things here. It's, it seems like there is some issues with our workers, which we saw because we were hitting the cap. And so what Claude is telling us is that you're hitting the cap with a normal site. You're gonna about go into burst capacity. And if you increase that to 40 checkouts per minute, that's something we wanna check out a little bit more. Scrolling down, we see a couple critical things. This is really where I wanna focus. So it looks like one of the critical issues that it's identifying is with our cart. And it's taken a long time for our cart to load. So it looks like we're going from four to five and a half seconds, from this test that Claude ran. Looking through some of the details here, Claude has found that we have good boy currency, which is how we do our loyalty program. I mentioned that earlier. And that could be part of the reason of what's going on here because there's about 3,800,000 rows in the database, and it seems like that's probably causing some of that slowness. So that's something we'll wanna file away and check-in a lot more as we keep digging into this site. The next thing that I want Claude to do is run through our checkout process and see exactly how long it takes to go from a product page all the way through the checkout. So have Claude go out, and it's crunching those numbers, and it comes back, and we can see here that everything is looking pretty standard until we get to the add to cart all of a sudden. An add to cart request is taking three point five five seconds. That's longer than I think it really should take. That cart page is taking five seconds to load. The checkout page is only two point five seconds. So something is going on with this add to cart cart page thing, because that's holding consistent to what we saw earlier. Moving on, what I the next step that I wanna do is I wanna see what happens if we mathematically calculate the load of 40 checkouts per minute. So I'm gonna ask Claude to take all the information that we just gathered and create a chart for what it thinks the PHP workers are going to do when we throw 40 checkouts a minute at our site. So we get this really great graph here, which shows us something very interesting. So normally, with 10 checkouts per minute, we're underneath our 10 PHP worker plan size. When we increase that to 40, all of a sudden we are going way above that. It seems like the top request here is 24 PHP workers. And you can see here in the queue wait time that traffic is just queuing up and waiting for PHP workers to become free. So this means there's probably going to be an issue or there could potentially be an issue as we throw more and more traffic at this site. And like I said earlier, we wanna make sure we reserve that burst capacity for true burst moments that we don't know about. What I would love to do is figure out how we can take our current site and make it so we can operate underneath those 10 PHP workers. Now what we did was just a mathematical test. If we wanna dive even deeper, we can run an actual load test. And to do that, what I'm gonna do is ask Claude to spin up a staging site because I don't wanna throw a bunch of load on the live site right now, especially because we know there might be a problem with the site as to handle that amount of concurrent checkouts. There's a lot of load testing tools out there. Grafon is one of my favorite, but, you can connect it to the MCP, have Claude create a plan strategy, have it set it up for you, and then use the load testing tool and the Pressable MCP to get all the results you need to actually create a map of what would happen if you threw the real traffic at this site. So that's what we did. Claude is going out creating that plan for us, exactly what it's going to do, loading up and queuing up that load test for us, and then starting to execute that load test, and at the end, getting all of that data and putting it into a chart. And so what we have here is a really good, summary of what's going on. So we have our simulated traffic that we had ran earlier, and now we have actual measured points of what's happening with the PHP workers versus the simulated traffic. You can see that the actual measure points is worse than what our simulated traffic was. This is a good point to realize that our mathematical numbers are probably showing a better performance than what the real numbers will actually show, which means we really need to get this fixed. So now that we have a good understanding of how this plays out with the load and the extra traffic on this site, what we wanna do is start digging into the actual problem. So I'm asking Claude to dive in and see why is the cart taking so long to load, what's the bottleneck, and can you find and recommend some solutions to remove that bottleneck for us? Instantly, Cloud has realized there is some database query that is causing a problem, and so it starts diving into that and timing things to figure out exactly what that database query is causing. It then comes up with a hypothesis for if we didn't have that query. And you can see here that with that really bad query that it found, it's taking six point four seven seconds to load that cart page. Without it, it would only take one point three four, which means it would have huge impact on the number of people that could get through our cart, not alone just make the experience better and faster for our user. So then it dives into an analysis here and identifies that that good boy currency, that loyalty program, is actually causing the bottleneck. This is the query that's causing the problem. This is the table definition that it's querying, and it seems like it's running that query four to five times when it only probably needs to run that query once. Let's dive into the fixes and see what Claude recommended. Because we have the pressable MCP connected to our Claude, it could actually go into the code and recommend the fixes for us, and we could actually apply those fixes without even touching a line of code. So it's recommending that we create an index for our good boy currency table. And what that's gonna do is move the time it takes to load the cart from six point four seconds all the way down to one point three four seconds. That is going to have huge ramifications on the number of people that can get through our checkout in one time as well as just improving the user experience overall. That doesn't fix everything though. For fix number two, it's recommending a custom function here to make it so that that query does not get fired four to five times every time that cart gets loaded. And looking down into fix number three, this is incredibly smart. It's looking at if the user is logged in because Claude has determined that a loyalty program will require someone to be logged in, so it's not gonna be ran on an unlogged in request. This is one of the really powerful things about using MCP in Claude is that it can become incredibly smart on how it's reasoning through what you're actually intending to do. The next thing I want Claude to do is simulate that if we fix these problems, what implications is that going to have to the number of people that we can push through our checkout and PHP workers? What I like doing this first is because it lets me know is it worth actually fixing these problems? Is it something that I wanna spend time on? Is it something I want cloud just to go out and fix itself? So cloud goes out, reruns all of those numbers, and we come back with this really great chart showing us before the fix and after the fix. So before the fix, we are above our 10 worker ceiling in the burst mode the whole entire time, maxing out at 26 PHP workers. After the fix, we are generally below five PHP workers every once in a while spiking up to 10, but that queue of tasks waiting for a PHP worker goes down dramatically. Essentially, there is no queue if we fix the problem versus a queue that keeps stacking up over time if we leave this problem and don't do anything about it. So here you have a decision to make. Are you gonna take these recommendations? You can open your code editor and make those edits, or you can take advantage of the pressable MCP and its connection to Claude, and we can actually have Claude apply those changes automatically. Now since I'm on a staging site, I wanted to see what happened. And I had Claude automatically make those changes for me and run through a bunch of tests to make sure that everything still works, and it does. So I can just apply all those changes to the production site, or I can go through and verify them manually. It is up to you. Now that we know what the issue is and that we fixed the issue, the last thing is I wanna be really confident during Black Friday and Cyber Monday that the site is performing as expected and nothing is going sideways. What I like to do is build a dashboard for my site or my whole entire portfolio of sites to bubble up current status reports and any issues that might show up. So as you can see here, I've had Claude take all the information that we used and create a custom report so that we can see exactly what is going on. So we can see peak PHP workers, the checkout path, what the cache is doing. You can see customers rejected from the checkout. This is actually from the load test that we had completed. So I would expect this to be pretty much zero moving forward. We have the worker headroom that we can we can check check out responsiveness, edge cache mix, any PHP errors that might come up. And by sitting here on this dashboard, I can watch in real time as traffic is hitting their site, how our site is performing, and be able to intervene at any moment. Black Friday and Cyber Monday can be incredibly stressful, but by utilizing Pressable, Claude, and the MCP, you can make sure that your site is going to be stable no matter what you throw at it By starting with the metrics, by running Claude through a simulated checkout and traffic and load spikes, defining actual errors, having Claude fix those for us, and utilizing the MCP to create a live dashboard to monitor the site, I can be sure that that site is going to perform and do what it needs to do at its most critical moment. That means a lot less stress for me, a lot less hours that I have to log to make sure that my client sites are ready to go for Black Friday and Cyber Monday. Super impressive. I love me some good metrics. Thanks, Steven. So say a client tells you that they're expecting four, maybe eight times their normal traffic during the peak season. Like, before you run any load tests, how do you figure out whether their current hosting is actually gonna hold up or whether there's a signal somewhere to move on to a different host? Yeah. I think that's where, like, instead of, like, jumping to how do you do a real load test, which can take quite a bit of work in setting things up, just having Claude run some numbers against what you're currently experiencing. So one of the key things is that your hosting provider has to give you some good metrics to work with. It's really hard to anticipate what's going to happen without having metrics from your hosting provider. The one metric set that you can always get though is how the checkout flow runs. I think Brent talked about this earlier about testing that whole entire checkout flow. You can have your LLM run through that checkout flow and and time things and get somewhat of an idea of how much work it takes to push someone through that checkout flow. But without having those back end numbers, you don't have quite as much data for Claude to work with, but you can still kinda have an idea of what it might look like when you do four x, five x, six x, whatever that checkout volume is going to be. Awesome. So speaking of reliable hosts, before we move on, just one thing I need to note here. So everything that Steven has talked about and just ran through runs on Pressable. Right now, we're running a promo through the automatic for agencies. It's actually quite nice. As a new customer, if you don't own your Pressable yet, you can get up to six months of Pressable hosting for free. Conversely, if you're already a Pressable customer, you can upgrade your plan and also get up to six months free. This promo is running until October 13, and you can learn more about it in the automatic for agencies portal. Just a note, if you haven't signed up yet for automatic for agencies, the program is free and offers, like, a ton of benefits to help you grow your agency. The good news is through automatic for agencies, you can purchase directly and you can also refer to your clients. So if you refer a hosting plan to your clients, you still get to enjoy referral commissions where we actually pay you out on a quarterly basis. And you can learn more about that, at automatic.com/agencies. So let's dive into part two. We've taken a look at some of the prep work needed leading up to peak season. However, a store can pass all of these checkout tests and still have a rough Black Friday because the store itself has to be correctly built. Part two is gonna look at how peak season pulls you in two directions at once. There's the marketing side of things, your offer, your segments, cart recovery, whether anyone can find the sale at all, and then there's the technical side of things, checkout payments and background jobs that can fail. So let's dive into that. Brent, we'll start with you. Let's get specific around coupons, cart recovery, payment health, background jobs that people might not even look at until they fail. What's actually on your list before a big sale? If you only have, like, an hour with a store, what would you look at first? A real test order using the actual sale and the discount. So I would use the payment and the shipping options that most customers would choose. I would check the price, the discount, the tax and shipping settings, make sure the payment actually goes through. I would then look at the order in WooCommerce. I would look at the customer email as well, and I would then check the stock count. You wanna make sure that all of those things are doing what you expect them to do along the way. Then if for the rest of my my hour, I would look at recent orders for anything unusual. So I would look for, and the MCP can be helpful here too, the the WooCommerce MCP. I would look for things like sudden increases in failed payments or orders stuck waiting for payment. I'd compare those orders with the payment provider information itself, and I check whether any of the work that Wu runs in the background has failed. Like, none of those things are gonna prove that the whole store is ready, but it'll tell you whether customers can actually buy and whether the business can, like, see and handle those orders. That's very helpful. So, Steven, on your end, is there anything that Brent talked about in his workflow, audit that would show up as, like, a hosting symptom rather than a store specific issue? Yeah. I think what we're looking at is kind of our requests getting backed up, our PHP workers getting spiked. Like, bad code essentially shows up on the hosting side by taking a lot of hosting resources to get to execute. And I think some people's gut reaction is to, oh, let's just throw more resources at it. But, like, in reality, resources can only cover so much because as you have exponential traffic coming through, especially like a checkout, you have an exponential resource curve. And at some point in time, more resources does not fix your problem. So going through that flow, understanding how everything is working and is everything working correctly is a big part of that. If some let's say your payment processor has an error, that's a lot of extra resource and work that the server has to do to process that and know what to do versus a streamlined checkout flow that works every time, all the time. Awesome. So, Brent, a lot of what we talked about earlier is about checking and watching, going through these workflows across however many stores you might be managing. But let's talk about AI for a second. What work is an AI agent good at today, and what work flows can reliably be automated on the storefront? Steven's demo example is a good example if you sort of translate to the WooCommerce side. An agent is good at doing the same checks across a lot of stores at once. So, it can find failed tasks. It can find, old or missing data. It can find unusual order activity or payments problems, and other things that need attention, that are similar. For example, it it might depend actually what are you selling. If you're a subscriptions business, it can help you find things like, renewal tasks or potentially duplicate charges, things like that. So I would let an agent read information, run checks, watch for problems. You can also draft responses, to potential customer issues that might come up. That'll help anything to help you save time on the day. So those are all great uses of AI. I still think a person should approve changes to especially things like pricing or discounts or products, and plugins, permissions, things like that. But, an AI, agent is very helpful in running a bunch of checks at once across a large surface area and helping you prepare for what you might need to action if you notice. anything wrong. Let's pivot back to the actual human component of this. So, Steven, your demo took a look. You were using AI to kind of look at a lot of metrics, do an analysis, and all that. But what would you never let an AI agent do without a person signing off? Whether that's like a deploy, a restore, maybe a permissions change. Yeah. I think I think it kind of boils down to personal preference a little bit because some people are more comfortable and some people are less comfortable. But I can tell you where I draw the line. I don't like letting the AI do any code changes without me seeing what it's going to do and why it's going to do it. So that includes, like, a backup. That includes changing, you know, discounts or product pricing. Depending on what change it wants to make, sometimes I'll let it make that change. Although, a lot of times I go in and make it manually myself just to make sure I have all the i's dotted and t's crossed because the ramifications of something going sideways is pretty big. And I just wanna make sure that I'm on top of everything. So that's kind of where I draw the line and where I like to sit in a loop with AI. Well done. So I'd love to chat talk about checkout now. So, Brent, obviously, checkout is like the one page you can't cash, and it's the place where, you know, actual orders happen. Where do Woo payments and other payment providers fit into this? And, like, what what's the conversation that you would have, an agency would have, with a client around this and expectations? I mean, at the end of the day, you wanna be able to take payments, facilitate orders, and you're looking for, like, what can do that job for me based on where I am in the world, the types of, products I'm selling, and that sort of thing. So I'd start with the, whether the current payment setup works for the business, and its customers. Can the customers pay the way that they want? Does it work in the countries that the business is selling to? Can your team find a payment, issue a refund, handle the dispute? Can you get help? And can you understand what that's costing to you at the end of the day? Woo payments specifically is is worth considering if, a merchant wants to manage payments inside Woo and get support from Woo. But that doesn't mean that it's perfect for every merchant or that every merchant should switch. So the agency should, I compare the practical benefits of using something that's built into whoo like that with the cost and work involved with moving. And I definitely wouldn't replace a payment setup that's working just before, you know, the biggest sale of the year, unless there's a clear problem and enough time to test the new setup properly. But in the long run, Woo payments is a great option if you want a payment solution that's, like I said, built into WooCommerce, and that's built and supported by the same team that's sort of building the platform you're running your business on. Not to mention, Woo payments and, like, others, you know, payments partners that we work with, that's where Woo earns most of its revenue. So, that the revenue that we need to keep investing in the platform. So every store that's built using Woo payments or or one of our partners allows Woo to keep building for the future of open commerce. So, aside from the benefits to you and your business, it's it's a benefit to keep the platform building for the future. on. Steven, similarly, on the hosting side of things, what does what what do things look like when the checkout is starting to struggle during during a sales event? Yeah. I think, generally, the first thing you start noticing is that the checkout starts slowing down because you start building a backlog of PHP workers that have to execute against things. So that's kind of like the first alarm bell, that you see, and kind of when you're like, oh, shoot. Something's going on. We need to investigate this more. For sure. Alright, folks. So up next, we've got another demo for you. Brian Kords is gonna dive in and show you some helpful workflows using the WU MCP. Let's get it going. Let's talk about MCP in WordPress and WooCommerce. So in this demo, we're imagining that as an agency, we have a client that is getting prepared for Black Friday, Cyber Monday. There's a lot of things you have to do to prepare. Some of them are more hosting and server level things that you need to check and make sure everything's healthy there. But then there's a lot of stuff you need to do inside of WordPress, inside of WooCommerce to make sure a store is properly ready for Black Friday and Cyber Monday. We're gonna do all of this by asking an agent to tackle it by connecting to our live site through the WordPress MCP connection. The nice thing about the WordPress MCP connection is that a lot of plugins in the ecosystem and a lot of WooCommerce extensions are building capabilities that can actually work with it. So it's one connection to your WordPress site, but you'll see, abilities from WooCommerce, from WooCommerce extensions, from your form plugins, and your SEO plugins. And you can also build your own custom ones yourself, which is something that we're gonna look at. These abilities are really just PHP functions, and agents, that do coding for you are really good at writing WordPress PHP. So it's a really great opportunity for you to build these sort of custom tools that anybody with an MCP connection to the site can use, and you can kinda control the code. Or you can use some of the tools that come with WordPress and WooCommerce itself. So we're gonna jump over to chat g p t to see what sort of abilities we have on our store. So I've asked it to verify the connection and just make sure it's there. I won't go through the process of connecting to the MCP. You will need a URL of your store. You'll need, a username for an administrative or store manager user, and you'll need a application password, and you'll add that to codex. But it's also something where you can ask your agent to sort of help you set up, and they can usually configure that for you. So I've already connected the MCP. And in this case, it's gonna tell me that the MCP returns three tools, which doesn't sound like a lot, but those tools are very powerful. Number one, it can discover which abilities are on our site, and those abilities are those functions that all the plugins, have added or that you've added to the site. It can get specific ability info for one ability, and then it can actually execute it where it'll make a request that might be to read some data and get it back or it might be to change something on your site. So on this site, you can see here I have a list of tons of different abilities. I have some that I've custom coded just for this client, things that'll help me manage some content on the site and get access to things, ones that'll give me some data about my WooCommerce configuration and check a few things under the hood. I have some that come from WooCommerce, and I even snuck in some abilities that are coming in our WooCommerce AI plugin that's currently being beta tested. So I have a ton of different abilities throughout here. And then if I go down further, I can see that I have Jetpack forms, and it also gives me access, which is just one of the ways that you can get a lot of the data from your store, out into your AI agent pretty quickly and securely. So my first prompt is I'm letting it know that I'm preparing a Black Friday campaign, and it's gonna be a simple sweater that's 20 off with this coupon code. Those are the dates that I wanna run it. But then what I actually did is I asked it to prepare a readiness report for me. So I have a lot of questions here, and I think the prompt even goes a little further but gets cut off here. It's gonna check and make sure my abandoned cart recovery is working. It's gonna review all my orders and payments and make sure there's nothing wrong there. It's gonna check all that background processing work is are all the scheduled actions and action scheduler working correctly. It's gonna look for errors, plugins that need to be updated, all that sort of stuff. So this ran in the background while I was doing other work, and it came back with all of this. Overall status, oh, it told me that it's not ready for this campaign, and it reminds me that it used read only MCP abilities. It didn't change anything on my live store. So there's a few major blockers here just to give you the kind of examples of things that it can do with your store. Number one is I haven't made the coupon code yet, so we're gonna ask the agent to take care of that later for us. So that would be a pretty big campaign impact if I don't have a coupon code created. My abandoned cart recovery is not configured. So the store uses Automate Woo to handle some of the WooCommerce automations, and it looks like I don't have any automations turned on. So that's a big red flag. That's something that maybe I wouldn't have remembered to check manually. But as part of this automated process, it was able to check it for me and let me know. It also tells me that Woo payments is not connected. This is a staging site. So that's an error that I know is for sure because I am not accepting real payments on this staging site. But as it goes further, the site is does have a lot of real data that I wanted to use to give you an example. So it's able to pull, thirty day windows of orders and look at it and see what my failure rate is for orders. It also noticed that some of my analytics reports were maybe not up to date, so there may be some caching issues that I can dig into. That's, again, probably just the fact that this is a staging site. And so it gives me a lot of interesting information there. It also told me that I have a lot of orders on hold and pending and that I've probably need to make sure that I can actually handle the backlog of an increased Black Friday, Cyber Monday, sales surge. So that sort of information lives inside your store and is pretty useful, and AI can kinda pull those insights out by pulling them over the MCP. There's some background processing failure issues, again, probably because this is a staging store that I've spin up and spin down, and it was able to use a few different, tools to figure out if there's any sort of other areas that I need to look at. Overall, it gave me a few more things, some plugins that need to be enabled. Is my high performance order storage working? It noticed that I pointed it to a staging site. Can't sneak anything by the agent here. And then it gave me some healthy checks, things that are running, pages that are configured correctly, that sort of thing. So it gave me a final recommendation, and it gave me a list of things that I need to do. So we're gonna paste in another prompt here, and we're gonna see how far it can go. And so I'm gonna send it, and then I'm gonna read the prompt here. While it's working, it's gonna use the product and coupon data because I told it I which product I want and what the coupon is, so it should be able to create that information. It's also going to create a landing page for me, which is another thing that can save me a lot of time. And the way that I've asked it to do this is I'm using a block theme. I'm actually using the WooCommerce purple theme, which comes with a number of patterns to help you design and build your website. So I'm telling you, actually, go fetch patterns from the website, fetch some of these design elements that are really good designs built for the theme, and actually pull them down, add the content that I want, and then push it back up as a draft landing page that I can review. And so I know that it's gonna follow things like my brand guidelines and match the vibe of the site because it's not gonna just create a bunch of random HTML that I have to deal with. It's gonna use the design elements that come out of that pattern library. So I'm gonna have it build the campaign page and pull as much product real product details and have a call to action where they can add the coupon code and continue to purchase the product. So it worked for just a couple of minutes and was able to build it up as a draft page, and we're gonna take a look at it. It tells me the patterns that it used and pulled from my theme, and it reread everything. And some important notes here, it mentions that we have not yet created the coupon code. So luckily, the agent was able to sort of track our to dos and make sure that it reminds us that we're not quite done yet. And it also did not publish the page, so it didn't change anything. It didn't add the automation yet. So we can go in and add all that stuff later, or we can ask our agent to do it. But just to wrap up, let's take a look at what it built. And so here's the landing page that it started with. So you can see I'd probably change the, template page template so that I don't have to see the page title at the top, and it would just start with the hero. Maybe even for a landing page, I might choose a different template with no header because I really just wanna focus on sales. And then we can see it did a pretty good job of doing a hero section using some of the components from some of the other pages. Obviously, I need to come in and swap out some of the images, and and maybe I would work with a more complete brief of what the marketing copy is going to be. And I would probably have more of a narrative that I'd wanna sell, but at least I have a starting page to do. And so in the future, you can do this approach of draft me a page, and I'll fill it out later, or you could probably give your your agent a much more prescriptive marketing brief of what to fill out. But overall, it matches the design of the site and gets us in a good place to start. So this is kind of an overview just to show you some of the different things that you can do. You can use the MCP to pull information from your site, do these sort of readiness audits to check different settings. You can build custom abilities for your clients to be able to get data. You can pull sales data and compare it over time periods. The possibilities are pretty endless here with what you can do with an MCP and when you set it up to a site, whether you're an agency or whether you wanna create a more of a custom MCP that your clients can use where you can put a few more guardrails in place. And this is really just scratching the surface. Very impressive. I've recently started using the WooMCP on one of my personal ecommerce sites. I'm really psyched about it. So we've talked a little bit about Woo payments and Woo today. I just wanted to highlight that through the automatic for agencies program and woo payments, you're actually able to earn more recurring commission up to five basis points of the total payment volume that's flowing through both your new and existing client sites. So if that sounds interesting to you all, navigate to the WOO payment section of the automatic for agencies portal to learn more. This is a great passive income channel for you all to check out. And just as a bonus where things get really great is that pressable offer that I mentioned before. You can actually combine both of these. So with both of them, if you're purchasing pressable and using Woo payments, you're not only saving some money, but you're making some as well. So a great benefit for our agencies there. Next up, I'm gonna transition into the question and answer portion around out today's webinar. So let me head on over, starting with Mike Allen. I think, perhaps, Steven, this might be a great question for you. Is there a preferred way to push a backup over a site without overriding new orders? Yeah. That is a really good question because, you do not want to lose any orders, especially during an important events like Black Friday. So with Jetpack, Jetpack has real time backups, and the really cool thing is it also has persistent orders. So you can pick any point in time that or it's not a point in time. It's that anytime there's a change, there's a actual backup inside of Jetpack that you can restore, but it will also keep all of your orders. So if you have Jetpack enabled, which you get, for free on pressable via a for a, You can restore back to anytime there's ever been a change to your site, and it will it will keep all those orders around for you so you don't have to lose worry about losing any of those orders, which is a really powerful tool to have in your back pocket, especially as we talk about those safety nets. That's very helpful. The next question, I'm actually gonna combine two of them. So talking about both MCPs, really, can Kimmy and Quinn and Mistral AI do the same thing as Claude on either Pressable or WOOZ MCP? I. think it's the same answer good question both. MCs. Yeah. Go ahead, Steven. Go ahead, Brent. I was gonna say, I think it's the same answer for both. I think the answer is yes. The agents themselves wouldn't be the, pieces connecting, but whatever harness you're using would. So if you're using Kimiko or Quiniko or a a Mistral agent or some other agent harness, they'll manage the connection. And, both of these are built on MCP, which is just an open standard, so it's not limited to one AI company. So they can work with any of these agents or models as long as the app running, or the agent running the model supports the right type of MCP connection and the authentication that you need. And I've I've used, the WIMCP with a bunch of different harnesses and agents, and, the connection kinda works the same no matter where you start. And a good place to start, like Brian mentioned in the demo, is just ask the agent what it needs, give it what it needs, and be careful with the, you know, tokens that you're giving it and store those securely, but you should be able to use this with any agent. Very good. Another question in the chat. So I believe, Steven, in your demo, the store was hitting PHP worker caps under normal traffic before Black Friday, Cyber Monday even became a factor. How do we spot that they're already at the ceiling without, waiting for a spike? Yeah. That's a good question. That's where, being on a solid hosting provider that gives you the metrics that you need to understand what's going on from your site is incredibly important. If your hosting provider obscures those metrics, it's really hard to know. It's kind of a shot in the dark a little bit. But if you have those metrics like Unpressable where I can just click into the metrics and see exactly the CPU usage, the PHP worker usage, I can easily know where I'm at and how many resources I'm using. So either it's gonna, a, be a really easy thing or, b, be a really hard thing depending on how your hosting provider exposes those metrics to you. Awesome. Thank you. We've got a question from Carlos. Do those real time backups in Jetpack tax performance? And I can actually take that one. The Jetpack team has done a wonderful job over the past couple of years really streamlining Jetpack. So I don't believe it has any tax on performance, if that was the question. Alright. Up next, woo readiness report flagged analytics that looks stale. A pile of orders sitting on hold and background jobs that had failed. During a sale, how much should an agency trust the numbers and an admin? What do you cross check against? It's a good question because if if you're noticing that things like, orders are flat or or something looks off, The first thing you should check is whether those orders are actually flat or whether those, background jobs are are running because sometimes reports can be delayed. So I would go in and look at, in WooCommerce at the new order specifically, compare them against your payments provider in in that example. In most cases, you've got another source you can look at to compare. So if the payment provider shows the new payments but the woo report hasn't changed, the problem could actually be with your reporting. If the payment provider shows a charge but woo doesn't show the right order, you could check that connection before going back to the customer and and assuming that something's wrong. And if things like payments have stopped, you could look at what customers are doing. Like, are they viewing products? Are they adding them to the cart? Are they reaching checkout? Are orders getting stuck in pending or failed? You could place a test order using your your discount or a new payment method and shipping options. So you can see actually what the customer is seeing. So at any point along the way, there could be a reason that, you know, that one of those numbers look off, and it might not actually be a problem with that number. It might be something upstream. But that's probably a good place to start is looking back through the chain of events and seeing, is there another source I can look at to compare to see which side of these things are actually wrong? And then if it's that your reports are delayed, then if you're look working in real time like you are on a big sale day, you might wanna look at the the most fresh source of truth that's updating, immediately. Thanks, Brian. Appreciate that. So it looks like that's all we have in the q and a channel today. But if you all have further questions after you get this recording, let us know. We're happy to answer anything. So, Steven, Brent, thank you both so much. And thanks to Brian Kords for the demo, the WOO demo. And, of course, thank you to all of our participants who joined here today for giving us an hour ten weeks out from Black Friday. So next, just watch out for an email from us within the next couple of days. It's gonna have the full recording and some further resources to help you tailor and build your own reusable playbook. And, of course, every store you manage is different, and a good process will survive that. So thanks again for spending the hour with us, and good luck out there this season. Bye, folks.