Every custom order was a message thread and a spreadsheet row. Now both channels end as one order record.
- Client
- A direct-to-consumer gifting and accessories brand
- Scale
- Paying customers in 10 countries
- Engagement
- A storefront build, a payment gateway, then ongoing maintenance
The outcome in six lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| Staff time per message order2 | 15 to 20 minutes | 2 to 3 minutes, through the moduleThe before figure is the team's own estimate, not a timed study, and the weaker provenance governs the pair. | Measured |
| Message orders in the order system2 | no place to record them | 40 to 50% of tracked ordersA share of tracked orders, never of all orders. It shows message ordering becoming visible, not growing. | Measured |
| Confirming the design with a customer1 | 4 to 5 minutes of back-and-forth | chosen and priced on the product page | Described |
| Payment4 | a UPI screenshot, checked by a person | the bank's UPI gateway, verified on callback | Described |
| Booking the courier1 | by hand, in a separate step | docket, label and tracking from inside the order | Described |
| Lighthouse performance score5 | not measured on the old site | 93 desktop, 74 mobile home, 66 mobile category | Measured |
Three lines carry figures. The time per message order and the share of orders are read from the store's own records, which we maintain, and the time before the build is the team's own estimate. Three lines describe a change in how the store works that carries no number, and are marked so. Each links to its source.
The problem, in the client's terms
Orders came in as Instagram and WhatsApp messages. Each one meant four to five minutes of back-and-forth to confirm the design, a UPI payment screenshot, a row typed into a shared spreadsheet and a courier booked by hand. The customer could not see where the order was. The team put it at 15 to 20 minutes an order, often longer.
The brand had a website. It was a custom CodeIgniter build on shared hosting, and it crashed when follower traffic spiked. Its Core Web Vitals were poor and its payment integration did not work end to end. The old site's order table held no completed orders at handover.
None of this was a discipline problem. The customer's choices were never captured as data. They lived in a chat thread, so a person had to carry every size, colour and add-on from the conversation into the spreadsheet, the courier portal and the reply to "where is my order". Each copy was a chance to get it wrong.
- ConstraintThe brand grew on Instagram, so the checkout was built for a phone first.
- ConstraintCustomers who ordered by message would keep doing so, and turning them away was not an option.
- ConstraintThe founders had never run a WooCommerce admin.
- ConstraintThe bank's UPI gateway had no official SDK for WooCommerce at the time.
The architecture, before and after
Switch between the two. The order moved out of a chat thread and a spreadsheet into one WooCommerce record, and payment, shipping and reporting now read from that record.
- What hurt in this state
- Built in this engagement
Three decisions, and what we turned down
Five platforms were weighed for this brand: Shopify, Magento and Adobe Commerce, Zoho Commerce, a Node.js storefront and WooCommerce. That was our recommendation for this client's constraints at the time, not a ranking we apply to every build. Each decision below names what it replaced and what it cost.
WooCommerce on managed hosting, not a hosted platform or a custom storefront
Turned down
Shopify
It handles variants well and puts per-product customization in an app layer. On a product whose options multiply, that layer meets the variant system.
Turned down
A Node.js storefront
It gave full control of the configurator, and it also put the whole order pipeline, payments and shipping included, on us to build.
Chosen
WooCommerce on WordPress.com managed hosting
The brand owns its data. It is PHP, so custom plugins are straightforward. It takes no transaction fee of its own, and managed hosting covers security, speed and uptime.
What it cost: The founders had to learn a WooCommerce admin they had never run, on a live store, so the work continued as maintenance rather than closing at handover.
Write the bank's UPI gateway from scratch
Turned down
Adapt the community plugin
It targeted an older version of the bank's API, and no official SDK existed at the time.
Chosen
A WooCommerce gateway plugin written from scratch
It covers the payment request, the callback the bank sends back and a verification step that confirms a payment settled, then sandbox testing, live testing and the client's acceptance testing.
What it cost: Three to four weeks for one payment method, and the sandbox did not behave like production, so reconciling the two took time nobody had estimated.
Record message orders instead of turning them away
Turned down
Send every customer to the website
People who have bought by message carry on doing it, and telling them to use the website instead risks the sale.
Chosen
A back-order module on a store-manager account
Staff enter a message order straight into WooCommerce using the same customization fields a customer fills in on the site, so it gets the same record, packing slip, tracking and email updates as a web order.
What it cost: A message order paid by UPI outside the gateway needs its own clearly named payment method, or reporting confuses it with gateway-prepaid orders.
How it was delivered
The courier integration shipped with the storefront. The payment gateway and the back-order module came after launch, each as its own piece of work.
Platform evaluation
Five options weighed against the brand's customization needs, led by our project lead.
The storefront
A custom mobile-first theme, the customization plugin, the courier plugin, analytics and search setup.
The payment gateway
The bank's UPI gateway written from scratch over three to four weeks, separate from the original build.
The back-order module
A store-manager account so staff enter message orders through the same fields as the site.
Maintenance and reporting
The founders were still learning the admin, so the work carried on as maintenance. The Python reporting layer belongs to this stretch of the work.
Who did the work
- Project leadPlatform evaluation and architecture
- WooCommerce developerThe theme, the customization plugin and both custom plugins
- QA software engineerTesting across the build
- OngoingOne developer on maintenance
Who owns what now
There was no clean handover. We still maintain the store, and the founders run it day to day.
Results
What a message order costs the team now, and how the store performs on the devices its shoppers use.
- Staff enter a message order through the store-manager account in 2 to 3 minutes, with no spreadsheet row and no separate courier booking.
- Customers pick size, quantity, colours and add-ons on the product page, upload a reference photo and see the price as they choose.
- The person packing reads the customer's choices from the order record instead of a chat thread.
- The founders read numbers from a reporting layer that found a customer-grouping bug the dashboards did not show.
Staff time before the build was never timed, so the 15 to 20 minutes is the team's own estimate. Order-entry mistakes were not counted before or after, so no accuracy figure is claimed.
20 minutes
Before the build
2 to 3 minutes
After, through the module
Staff enter a message order into the same fields a customer uses, so nothing is confirmed twice or typed again.
| Option | Minutes of staff time. Both are the team's own estimates, not a timed study. The after bar uses 3, the high end of 2 to 3. |
|---|---|
| Before the build | 20 minutes |
| After, through the module | 2 to 3 minutes |
Source: Source note 2
93
Desktop
74
Mobile home page
66
Mobile category page
The two mobile scores are the open item, on the surface a brand grown on Instagram was built for.
| Option | Lighthouse performance, 0 to 100, measured by us. Largest contentful paint was 1.1 seconds on desktop and 3.5 seconds on the mobile home page. |
|---|---|
| Desktop | 93 |
| Mobile home page | 74 |
| Mobile category page | 66 |
Source: Source note 5
What it would be worth to you
We do not publish what an engagement costs. So this works from your side: the staff time your message orders take today, and what it would be at the module's pace.
Staff hours saved per month
Enter your message orders
- Staff hours per month, today
- Enter your message orders
- Staff cost saved per month
- Enter a staff cost
- Failed-delivery cost avoided per month
- Enter the cash-on-delivery figures
Time is the only benefit counted by default. Fewer retyping mistakes are real but unmeasured, so they are left out.
What went wrong, and what we would change
The gateway's reconciliation was never estimated
The bank had no official SDK and the community plugin targeted an older API, so three to four weeks went into one payment method. The sandbox did not behave like production, and reconciling the two took days nobody had estimated. Next time that risk goes into the estimate by name, and the callback path is tested with real transactions before go-live.
Mobile performance is still open
Desktop scores 93. The mobile home page scores 74 and a category page 66, held back by total blocking time on mobile. Layout shift is good everywhere. We publish the weak numbers next to the strong one, because mobile is the surface this checkout was built for.
The data was wrong in ways no dashboard showed
Our Python reporting layer found three problems the standard dashboards missed. A WooCommerce bug we hit at the time put one customer ID on thousands of guest orders. Instagram's in-app browser stripped the referrer, so that traffic read as direct. And UTM names were inconsistent, so one source read as several. We have not retested the bug against current WooCommerce versions.
Two kinds of UPI payment looked the same in reports
A message order paid by UPI outside the gateway was easy to confuse with a gateway-prepaid order. It needs its own clearly named payment method, or the prepaid numbers mix the two.
Will this work for your store?
It fits when
- Your customers' choices can be written as options: size, quantity, colour, add-ons, a reference photo.
- You want message orders and website orders to end as the same record, not to stop the messages.
- You are willing to own the admin afterwards, with help while you learn it.
- You need a payment method with no ready plugin, and can plan weeks for it.
Look elsewhere when
- The customization is a consultation, and you and the buyer arrive at the design together. A form cannot hold that.
- You want the messages to go away. Here they did not. They got a record.
- Your products have no per-order options. A standard theme and the stock checkout may be enough.
Check it on your own store this week
If a message order takes more than ten minutes and you cannot count how many you take, this case study is about you. Put the numbers into the calculator above.
- Time five message orders from the first reply to the courier being booked.
- Count how many orders in your system began as a message. If you cannot tell, that is the finding.
- Group last month's orders by customer ID and look for one ID on many guest orders.
- Compare Instagram traffic in your analytics with the messages you received. A stripped referrer reads as direct.
How it is built, by layer
- PlatformWooCommerce on WordPress.com managed hosting, a custom mobile-first theme
- CustomizationA purpose-built plugin for size, quantity, colours, add-ons, a reference photo and the price
- PaymentsThe bank's UPI gateway, written as a WooCommerce plugin from scratch
- ShippingA courier plugin for docket numbers, labels and tracking
- OrdersA back-order module on a store-manager account
- Search and analyticsGA4, Meta Pixel, Rank Math, product schema, a Merchant Center feed, an XML sitemap
- ReportingA Python layer over the WooCommerce REST API
How each figure was measured
- Staff time and steps for one message order before the build, from the brand's own order handling.
- Staff time per message order through the back-order module, and its share of tracked orders, from the store's order records.
- The site before: a custom PHP build on shared hosting that crashed on traffic spikes and never completed a payment.
- The payment gateway integration, written from scratch and tested in sandbox and live.
- Lighthouse on the live store: desktop, the mobile home page and a mobile category page.
- What was harder than planned, from the delivery team.
- The store's own order records: prepaid share, refunds, cancellations and countries with paying customers.
- The store's Search Console: impressions, clicks and average position.
- A co-founder of the brand, approved for this page.
- The delivery team and the platforms compared before choosing WooCommerce.
Tell us how long a message order takes you, and we will tell you if a module pays.
Send the minutes per order and how many arrive each month. A software engineer reads it and replies with an honest answer, including when a spreadsheet is still the better choice.