B2B Portal Down on Christmas Jumper Day

Ask any decorated goods business that runs a B2B portal whether they've experienced a portal outage during Christmas jumper season and most of them will tell you yes. Some will tell you it happened more than once. And almost all of them will say they still don't have a proper fallback in place.

Why Peak Season Is Also Risk Season

The December period is the highest-volume trading window for a significant proportion of decorated goods businesses — Christmas jumpers, corporate gifts, charity fundraising. It's also the period when infrastructure is most at risk.

Peak traffic loads stress systems that handle average load without issue. Hosting providers often schedule maintenance windows in late November and December, before the period when their support teams are on reduced staffing. And the people inside your business who would normally manage a portal crisis may also be on reduced availability.

None of this is inevitable. It's a planning failure — specifically, a failure to think through what happens when the portal goes down at the worst possible moment.

What the Downtime Actually Costs

The direct cost is orders not placed. For a B2B portal processing £20,000 of orders per day during December, a 24-hour outage is £20,000 of revenue at risk — some of which will be recovered when the portal comes back, some of which won't because customers found another supplier or the deadline passed.

The indirect cost is relationship damage. A customer who can't order from you when they need to may forgive it once. If it happens twice, or if the communication during the outage is poor, they'll have a quiet conversation with another supplier.

The management cost is the team time consumed by a crisis that didn't have to be a crisis. Phone calls fielded, orders manually taken, emails responded to, escalations managed with the hosting provider — all while the normal pre-Christmas workload is still running.

Monitoring That Actually Works

Most portal monitoring is limited to uptime monitoring: is the server responding? That's not the same as "can a customer actually place an order."

A server can be running and returning responses while the checkout is broken, search is returning no results, or the payment gateway isn't connecting. Uptime monitoring misses all of those. You find out when a customer calls.

Synthetic transaction monitoring runs automated tests that simulate a real customer journey — search for a product, add to basket, proceed to checkout — at regular intervals. If any step fails, an alert fires. You find out at 3am when it breaks, not at 9am when the calls start.

This is not expensive to set up. Services that run synthetic monitoring cost a few hundred pounds a year. The monitoring itself takes a few hours to configure. The return on investment from catching one peak-season outage early is immediate.

The Fallback Process

Monitoring catches downtime early. A fallback process means it doesn't have to stop orders. The fallback needs three things:

1. A customer communication. An automated message to affected customers — or at minimum, a banner message on your homepage — that acknowledges the problem, provides a phone number or email for orders, and gives an estimated resolution time if known. Silence is worse than a clear message.
2. A temporary order mechanism. A simple order form, a phone number that goes to a staffed line, or an email address that goes directly to someone who can process it. Not "email info@" and hope. A defined channel with a defined owner.
3. A reconciliation process. When the portal recovers, the orders taken through the fallback mechanism need to be entered into the main system. This should be documented before it's needed — not figured out on the day.

Before Peak Season: The Checklist

Every decorated goods business running a B2B portal should run through this before the December period:

• Is synthetic transaction monitoring in place and alerting to the right people?
• Has the portal been load tested for peak traffic? (Not just average traffic.)
• Is there a documented fallback process for portal downtime?
• Does the hosting provider have a clear escalation path and SLA for critical issues?
• Have you confirmed the support staffing level at your hosting provider over the Christmas period?
• Is there someone with admin access to the portal available on call during peak trading?

None of this takes long to check. All of it is significantly easier to sort in October than on December 23rd.

Common Questions

How do you monitor beyond "is the server up?"

Synthetic transaction monitoring — automated tests that simulate a real customer journey at regular intervals. If the checkout fails at 3am, you find out at 3am, not when a customer calls at 9.

What should a fallback order process include?

Customer communication acknowledging the issue, a temporary order mechanism (phone or email with a defined owner), and a documented process for importing fallback orders when the portal recovers.

Why do portals go down during peak periods?

Peak traffic loads stress systems sized for average load. Hosting providers often schedule maintenance before the period. Support staffing is reduced. Load testing before peak season — not after — identifies capacity issues before customers do.