How Stevensons' AI Personal Shopper Works

Last month James Harding, Stevensons' operations director, gave an interview to Retail Gazette about how a school uniform retailer with a century behind it is using technology to make back-to-school less stressful for families. It covered the why: parents want convenience across channels, uniform is a considered purchase where confidence matters, and technology should be useful rather than introduced for its own sake.

We've built and run the Stevensons platform since 2020. The interview, quite rightly, didn't get into what's underneath. This piece does - not the code, but the decisions, and what each one cost or saved. If you run marketing or technology for a retailer and someone has recently asked you "what's our AI plan?", this is the part I'd want you to read.

The headline is that the AI Personal Shopper went from proof of concept to live in under ten weeks. The more useful point is why. Bryn Jones, our Technical Director, led the build, and his summary is blunter than mine: "The AI was the easy part. Everything it relies on was already true."

The problem is 750 different problems

School uniform looks like a simple category from the outside and isn't. Stevensons works with more than 750 schools, and each one has its own list: what's compulsory, what's recommended, what's optional, which items only apply from Year 1, which change for the summer term, which house a child is in, and which items are exclusive to Stevensons rather than available anywhere. Layer on gender, sizing for children who grow between ordering and wearing, 30 branches offering fitting appointments, and a hard deadline in early September, and you have a purchase where a parent's biggest fear is buying the wrong thing.

That's the context for every decision below. The platform's job is to make the right thing easy to find and the wrong thing hard to buy.

Why this doesn't run on Shopify or Magento

It's the question I get asked most when I describe the platform, so it's worth being direct about.

When we started in late 2020, the site was a .NET application built around a bespoke in-house ERP. Stevensons were moving to NetSuite, which became the system of record for everything: products and their size and colour variants, schools, year groups, branches, shipping methods, tax and pricing. NetSuite pushes all of that into the site through an integration layer and polls it for orders. The website is the shop window; NetSuite is the business.

The reason an off-the-shelf platform doesn't fit is the shape of the data, and Bryn describes it better than I can: "The domain is school, to year group, to year grade, to product eligibility - with gender, compulsory status, recommended quantities and per-school pricing on top. Then 30 branches with fitting appointment slots, family and child profiles, a school staff portal, the pre-loved ledger and club shops for sports teams. None of that maps onto Shopify or Magento's product and customer model without fighting the platform."

The cost of fighting a platform never appears on a licence invoice. It appears as every feature for the next five years taking longer than it should, because the first job each time is working around what the platform assumes you are.

So the commerce platform is custom, built in Laravel, with Statamic handling content so the Stevensons team can edit pages without a developer. The replatform went live in January 2022, and existing customers were migrated without anyone having to reset a password. A second phase - new front end, search, family profiles, returns, pre-loved, promotions - went live in April 2024. Everything James described in the interview sits on that foundation.

An AI shopper that can only recommend what the school allows

The AI Personal Shopper is the headline, so it's worth being precise about what it is and isn't.

It is not a chatbot that has been shown the catalogue and asked to be helpful. Almost everything it says is constrained before the language model gets involved.

The rules come from two places. NetSuite already holds, for every school, product and year group, whether the item is compulsory, recommended or optional, how many a child needs, and whether it's exclusive to Stevensons. On top of that, Stevensons staff write two things in the admin for each year group and gender: a general rules note, and an ordered list of uniform steps - start with the blazer, choose either the kilt or the trousers, and so on - each of which can be pinned to particular year grades. A deterministic planner reads those steps, resolves them against the live catalogue, and builds the guided walkthrough. Two parents at the same school, in the same year, shopping for the same gender get the same set of steps. There's no model in that loop.

The model comes in for the conversation on top: the parent who asks "what do I need for a Year 3 girl?" or "which socks go with the shorts?" This is where most retail AI goes wrong, and it's the part Bryn was most deliberate about.

"It's grounded by retrieval, not free generation," he says. "Each school and year group has its own index, built from that school's live, priced, visible products, and gender is applied as a hard filter. The candidate pool is always 'things this school sells to this year group and this gender', and the model only chooses and groups within it. It can't recommend a product the school doesn't sell, because it never sees one."

Popular sizes come from purchase data aggregated nightly by school, year and gender. "What did I buy last time" comes from the customer's own order history.

Because the retrieval does the heavy lifting, the model itself can be small. Stevensons runs on OpenAI's gpt-5.4-nano, deliberately one of the smaller and cheaper models, which matters when your peak day is close to 10,000 sessions. Bryn's view: "The effort belongs in the data, not the model. A bigger model reasoning over a badly structured catalogue just gives you confident, expensive mistakes."

When it can't answer, it says so and shows nothing. It declines off-topic requests and steers back to uniform. Inputs are screened for prompt injection, responses are validated, and a response that fails validation is replaced with a plain message. If anything goes wrong, the parent sees an apology and the normal filtered product list, which is always there underneath. There's no hand-off from the assistant into a live agent, and nobody pretended otherwise; live chat, the stores and the pop-ups are where a parent goes when they want a person.

The part I'd push any vendor on is measurement. Every conversation is stored, customers can rate it with a thumbs up or down, and Stevensons staff can review any conversation. More usefully for the business, every basket and order line carries a flag saying whether it was added through the assistant and which conversation it came from, so the revenue it influences is measured directly rather than estimated.

The proof of concept started on 27 April 2026 and it launched on 2 July, in time for peak. It's live with a first group of pilot schools, and because the indexing is per school, extending it is a rollout rather than a rebuild. Under ten weeks from first commit to live - not because anyone rushed, but because the rules, the catalogue and the customer data were already structured, priced and trustworthy.

Pre-loved, run by the schools themselves

Selling second-hand uniform through a retailer's website has an obvious problem: who holds the stock, who grades it, and who ships it? Every answer that put the burden on Stevensons' warehouse or on a school office would have killed it.

The design we settled on is quantity-based. A pre-loved item is the same product as the new one, not a separate listing. A school's staff have a login under My Account that shows each of their products with available, allocated and on-hand counts, and two buttons: add stock and remove stock, with a quantity. No condition grades, no photographs, no per-garment listings. Underneath it is a ledger - stock received, allocated, collected, rejected, adjusted - and availability is simply the sum. As Bryn puts it: "Count the blazers, enter a number. That's the whole administrative job for a school."

For parents, the product page shows "3 pre-loved available for £X each" beside the new price. The price is the retail price minus a per-school discount, 50% by default. New and pre-loved can go in the same basket, and the parent pays for both through the normal checkout.

What happens next is the interesting part. Paying creates an allocation against the school's stock that the school then confirms. Staff accept or reject each line in their portal, and either action is pushed into NetSuite so the order record is right. Pre-loved items are collected from the school regardless of the delivery option chosen - checkout, the confirmation page and the email all say so - and Stevensons never ships them. The school's share of the revenue is reported in the platform and settled outside it.

The first version went live in April 2024 and taught us what schools actually needed, which turned out to be a much stricter allocation model, correct VAT handling and firm out-of-stock enforcement. We reworked it through the summer of 2025 and it launched properly that September with a small number of pilot schools.

Returns where the RMA exists before the customer closes the tab

Children grow, sizing online is hard, and back-to-school returns arrive in a wave. James was clear in the interview that the returns process had to be as straightforward as possible. Our version of straightforward was to remove every step where the customer waits for someone else.

A parent starts a return from My Account, or as a guest with their email, postcode and order reference, which the site looks up in NetSuite. Reason codes come from NetSuite and can be switched off per product. When they submit, the following happens in the time it takes the page to load: the Return Authorisation is created in NetSuite and comes back with an RMA number; the return is saved against that number; a Royal Mail shipment is created; and the NetSuite record is updated with the shipment and tracking details and marked as booked. If NetSuite refuses - say the item has already been returned - no return is created and the parent is told to contact customer services. There's no half-created state and nothing to reconcile later.

Then the parent chooses. Drop-off calls Royal Mail's printerless label service and emails a QR code to show at the Post Office. Collection runs a short form that validates the address, fetches available slots from Royal Mail's collection API, and books a collection for the chosen date and time window, confirmed by email. Tracking events from Royal Mail flow back onto the RMA automatically. Refunds are issued in NetSuite and a daily job reconciles statuses back to the site. If a parent orders an exchange within 24 hours, they're reminded that return postage is subsidised.

The first version, in July 2024, was a link to Royal Mail's hosted returns portal. The full integration was built between February and May 2025. I asked Bryn how unusual it is. "Uncommon rather than unique. Most mid-market UK retailers use a hosted returns portal or batch their RMAs, and Royal Mail's collection API isn't something many have wired in directly. The point isn't novelty. It's that the RMA exists in the ERP before the customer has closed the tab."

Built for a peak that arrives on a fixed date

Christmas is retail's peak; Stevensons' is August, and it doesn't move. In sessions, August is roughly eight times December. The busiest day this year was 24 August, with 9,763 sessions, and the platform's uptime over the last 30 days is 99.95% with an average response time of 157 milliseconds.

Underneath: Laravel Forge on AWS in London, a production server rebuilt in November 2025 with zero-downtime deploys, Redis for caching and queues, Meilisearch for search, and Cloudflare in front. The NetSuite integration runs on its own queue, so a slow ERP response can never hold up the shop. Stock levels refresh every two hours. "None of it is exotic," Bryn says. "It's boring on purpose. September doesn't give you a second chance."

Six years, not one project

James's LinkedIn post talked about 36 months of investment in the website, and that's right if you count from the redesign that began in late 2023. The full engagement is nearer six years:

• Nov 2020 – Jan 2022: replatform, NetSuite integration, fitting appointments, checkout.
• Jul 2022 – Apr 2024: phase 2 - new front end, search, family profiles, returns, pre-loved, promotions, sizing tool.
• 2024 – early 2026: guest checkout, year-group uniform lists, the full Royal Mail returns integration, the pre-loved rework, Find Your School, peak performance work and a new production server.
• Apr – Jul 2026: the AI Personal Shopper.

That sequence is the argument, and it's the one I'd make to any board weighing up an AI budget. The assistant landed in ten weeks because it arrived last. Bryn again: "The requirement data was already in NetSuite, the catalogue was already per school and per year group, the customer history was clean, and the attribution plumbing already existed in the basket. If we'd tried to build this in 2022, we'd have spent most of the time discovering the data underneath it wasn't ready."

What's next

James said in his post that this is just the start, and he's right. But the order matters. Get the data right, make the boring parts reliable, and the clever parts become small.

If you're being asked for an AI plan and the first question on the table is "which model", I'd gently suggest it's the wrong first question.