The scenario
The store sells cat food and litter almost exclusively, with a small line of dog food kept mostly for existing customers who asked for it. Orders lean heavily toward the twelve-kilo food bag and the large litter carton, both of which sit above the point where a courier can simply leave a parcel by the door on a normal next-day run. KNET, Tabby and cash on delivery all sit at checkout, and the founder had built the store as a side project that grew into the main job within its first year.
The traffic was doing its part. Search ads on specific brand names and a steady stream of Instagram and Snapchat content brought in a consistent flow of cat owners who already knew roughly what they wanted. What nobody had built was a checkout that understood the difference between a light accessory order and a heavy, scheduled one, and a product page that knew what to do when the exact brand someone searched for was not currently on the shelf.
- Monthly revenue band
- pending client sign-off
- Average order value
- pending client sign-off
- Fulfilment
- Own stock, contracted courier for standard items, own van for scheduled heavy-item runs
- Team
- Founder and one part-time driver for heavy-item deliveries
The site sold light accessories fine. The bags were another story
The account looked healthy on the surface: strong click-through on brand-name search ads, a loyal Instagram following built on cat photos rather than product shots, and a product page that held attention well for a category nobody finds glamorous. The number nobody had split out was how differently a cart converted depending on whether it held a small toy or a twelve-kilo bag, because the standard analytics view blended both into one conversion rate.
Split that way, the picture changed. Light-item carts converted close to what the founder expected. Heavy-bag carts, which carried most of the store's actual revenue, fell away hard at a specific point: the courier's standard next-day slot could not take a bag over a certain weight, and the site had no way to offer the scheduled delivery day this actually required until the customer had already reached the final checkout screen and been told to call the store directly. Session recordings on out-of-stock product pages showed a second leak: a customer whose preferred brand was unavailable clicked a plain "notify me" button and never came back, when the store had a comparable item sitting one click away the whole time.
Neither problem was an advertising problem, and a bigger budget would only have sent more of the wrong kind of visitor into the same two gaps. The site had been built for the item that is easy to ship, not the one that actually pays the bills.
What we did — the pages and offers we tested
The losers are here on purpose. A test with only winners was never a test.
A delivery-day picker for any bag over five kilos
Winner"Pick your delivery day" shown on the product page for every heavy bag, not just at checkout
- Format:
- Product page module, single-variable test against the control
The store already knew which items needed a scheduled van run; it just told the customer at the worst possible moment. Moving the delivery-day picker up to the product page, before the cart, let a customer commit to a plan she could actually keep, instead of discovering at the final screen that her order needed a phone call.
An in-stock substitute shown on the out-of-stock page
Winner"This one is out today. Here is the closest one we have in stock."
- Format:
- Product page module replacing a plain notify-me button
The creative-testing work on this same account had already shown that cat owners accept a confident substitute better than they accept silence. Putting that same judgement directly on the product page, rather than only in an ad, kept far more of that traffic from bouncing to a pet shop in Rai or Shuwaikh the moment a search led to an empty shelf.
A food-and-litter bundle at one delivery fee
Winner"Restock both together. One delivery fee, one scheduled day."
- Format:
- Cart page bundle offer, single-variable test
Food and litter run out on different schedules for most households, which had always meant two separate deliveries and two separate fees. Bundling them into one scheduled drop raised the average order value and, just as importantly, cut the number of heavy-item van runs per customer per month, which mattered directly to the driver's capacity.
A same-day promise extended to heavy bags
Lost"Order by noon, get it today" applied to every product including the twelve-kilo bag
- Format:
- Sitewide banner and checkout badge, single-variable test
A tempting promise that the one-driver operation could not actually keep at volume, and it is worth publishing because the failure was measurable rather than a guess: failed and delayed heavy-item deliveries rose during the test window, and the review comments that followed were sharper than any the store had seen from an honestly scheduled delivery. A promise the operation cannot fill converts once and costs a repeat customer.
Mandatory account creation before checkout
Lost"Create an account to continue" placed before the guest checkout option
- Format:
- Checkout entry step, single-variable test against a guest-first control
Meant to build a customer database for future WhatsApp reminders, it instead cost first-time orders from cash-on-delivery buyers who had never bought from the store and were not willing to register before they trusted it. The database is worth having, but it has to be built after the first order, not as a toll before it.
What we did — the optimizations, in order
Read the funnel by product weight, not just by device
We split every funnel step by whether the cart contained a heavy scheduled item, in addition to the usual split by device and language.
Why: A blended conversion rate had been hiding a healthy light-item funnel sitting on top of a heavy-bag funnel that leaked badly, and averaging the two told the founder the site was performing fine. Splitting by weight is what turned a vague sense of missed orders into one specific, fixable moment.
Sit through recordings on out-of-stock pages
We watched recorded sessions on the product pages that went out of stock most often, tracking what a customer actually did in the seconds after seeing an unavailable brand.
Why: A stockout looks like one lost sale in a spreadsheet. In a recording it looked like a customer clicking notify-me and immediately opening a new tab to search a competitor by name, which is a completely different and more urgent problem than the number alone suggests.
Fix the floor: speed, badges, and a real weight rule
Compressed product images, put KNET, Tabby and cash-on-delivery badges on the product page, and coded the actual weight threshold the courier uses into the site so it knows which items need a scheduled driver run before the customer ever adds one to the cart.
Why: None of this depended on which page test won or lost, which is why it came first. A site that did not know its own weight rule was silently promising a delivery method it could not deliver on every single heavy order, regardless of how good the ad that brought the visitor was.
Test the delivery-day picker, the substitute module and the bundle separately
Each of the three fixes ran as its own single-variable test against the existing page, with the audience, the ad and the price held identical throughout.
Why: Running the picker and the substitute module together would have made it impossible to say which one actually moved checkout completion. Testing them apart is the only reason the store can now say with confidence that both mattered, and roughly how much each one contributed.
Rebuild checkout around the scheduled delivery, not the next-day default
The delivery-day field moved earlier in the flow, the cash-on-delivery fee for heavy items shown before the final click, and a WhatsApp link added for anyone who wants to confirm a specific time window with a person rather than a form.
Why: A checkout built around the assumption that every item ships the same way is what forced heavy-bag customers into a phone call in the first place. Building the schedule into the flow itself removes the one step that was quietly training the store's best customers to call instead of check out online.
Time the review request after the bag has actually been used for a week
The review request moved from delivery day to roughly a week later, once a customer has had time to see how her cat took to the food or the litter rather than only confirm the parcel arrived intact.
Why: A review asked for on delivery day is a review about the driver, not the product, and the reviews that came back a week later were longer, more specific, and more useful to the next cat owner deciding between two brands. This is operational timing, not a claim about what the product does.
Keep a weekly test log, including the driver's capacity
Every test, its hypothesis, its result and its decision went into one shared log, alongside a simple weekly count of scheduled heavy-item runs the one driver could actually complete.
Why: A page test that increases heavy-item orders faster than the driver can deliver them is not a win; it is a new bottleneck wearing the name of a good result. Watching capacity alongside conversion is what stopped the same-day promise test from being read as a success before the delivery data caught up with it.
What changed
The table above carries the figures once the client signs them off, and the pattern worth flagging now is that checkout completion moved specifically for heavy-bag carts, which is exactly the segment the fixes targeted, while the light-item funnel stayed roughly where it already was. That is the shape you want from a fix aimed at one gap rather than a sitewide change that moves everything a little.
The substitute module mattered in a way the founder had not expected: it did not just save an out-of-stock visit, it noticeably reduced the number of customers who never returned after one stockout. Add-to-cart rate on affected pages held up close to a normally stocked page once a confident alternative sat one click away.
The two losing tests were worth running even though they lost. The same-day promise confirmed that this category's real constraint is delivery capacity, not customer patience, and the mandatory account test confirmed that trust in this store is still built order by order, not demanded up front. Both findings changed the sequence of what gets fixed next.
What we would do next
First, extend the delivery-day picker to the WhatsApp order flow the store still runs by hand for repeat customers who reorder by message rather than through the site, so the same scheduling logic covers every channel.
Second, add a second part-time driver before the indoor summer months, when litter and food consumption both rise and the single-driver capacity that this engagement was careful not to outrun becomes the next real ceiling.