Odoo E-Commerce
A shop is not a website. It is an operations project with a storefront on the front of it.
Odoo Website + eCommerce builds with SEO, payment gateways, shipping, multi-language, multi-currency, abandoned cart, and headless front-ends.
The design is the visible part and the smallest part of the risk. What decides whether an Odoo shop works is the catalogue structure, whether the checkout survives a real card failure, whether stock shown online is the stock you have, and whether a customer who ordered at midnight gets a parcel without anybody re-keying anything. Those are operations questions, and they belong in the plan before anyone chooses a colour.
The advantage of running the shop inside Odoo is that the order, the stock, the invoice and the customer record are the same records the rest of the business already uses. There is no synchronisation to maintain and no argument about which system is right. That advantage disappears the moment the catalogue is structured for the warehouse rather than for the buyer, so the catalogue is where we start.
Where you already have a shop, the migration is treated as its own workstream. Existing URLs are mapped and redirected before launch, because a shop that ranks today and loses that on launch day has traded a working asset for a nicer layout.
What is included
- โ Odoo Website theme customization
- โ Multi-language & multi-currency
- โ Payment gateways & BNPL
- โ Shipping carrier integrations
- โ Abandoned cart recovery
- โ SEO metadata, sitemaps, schema
- โ Headless Odoo + Next.js/Astro
- โ PWA & mobile-first layouts
How the engagement runs
- 1
Catalogue and merchandising design
Structure the catalogue around how people buy, not how you store things.
- Decide what is a product and what is a variant, which is the decision everything else inherits
- Design categories and filters from the way customers search, not from the warehouse layout
- Plan the product page: what has to be there to answer a buyer's question without a phone call
- Sort out product data quality early, since thin descriptions and missing images are the usual bottleneck
You end up with: A catalogue structure and a product data specification your team can populate against.
- 2
Storefront build
Build a shop that is quick and that works on a phone.
- Theme and layout implemented against your brand, mobile first, since most traffic is
- Product, category, search and cart pages built with real data rather than placeholders
- Multi-language and multi-currency where the market needs it, including right-to-left handling
- Performance treated as a requirement: image handling, page weight and time to first render
You end up with: A working storefront on staging, populated with your real catalogue.
- 3
Checkout, payment and fulfilment
Make the money and the parcel work, including when they do not.
- Checkout kept short, with guest checkout unless there is a real reason to force an account
- Payment methods configured for the market, tested through the failure cases and not just the successes
- Shipping rules, rates and carrier handover configured so nobody re-keys an address
- Order flow through to picking, delivery and invoice, tested end to end as one path
- Stock visibility rules agreed: what shows as available, and what happens on the last unit
You end up with: A tested order path from a card payment to a picked parcel and a posted invoice.
- 4
Search visibility and migration
Launch without losing the traffic you already have.
- Metadata, structured data, sitemap and canonical handling set up properly
- Existing URLs mapped one by one and redirected, with the mapping reviewed before launch
- Redirects tested on staging, then verified again immediately after launch
- Analytics and conversion tracking working from the first hour, not added the following week
You end up with: A verified redirect map and tracking live at launch.
- 5
Launch and iteration
Trade, then improve on evidence.
- Soft launch to a limited audience where the business allows it
- Watch checkout completion, search behaviour and site errors in the first days
- Abandoned cart recovery and follow-up messaging enabled once the basics are steady
- A prioritised improvement backlog driven by what customers actually did, not by opinions
You end up with: A trading shop with tracking, a defect list cleared and an evidence-based backlog.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ Product data: descriptions, images, attributes and prices, or a decision to have that produced
- โ Brand assets and any design direction, since we implement design rather than invent a brand
- โ Merchant accounts with your payment provider and credentials for the carriers you use
- โ A decision on shipping rules and rates, which is a commercial call and not a technical one
- โ Access to the existing site and its analytics where you are replacing a shop
- โ Someone who will own the shop after launch: content, promotions and the order queue
Decisions you will be asked to make
Odoo storefront or a headless front-end
The Odoo storefront is faster to build and easier for your team to edit. A separate front-end gives more design freedom and better control of front-end performance, at the cost of a second codebase to maintain. Most businesses should start with the storefront and only move if there is a specific reason.
Product or variant
The decision that everything downstream inherits: filtering, stock, pricing, reporting and the URL structure. Getting it wrong is a re-platforming exercise later, so it is settled first and deliberately.
How stock is shown
Exact quantities, a simple in-stock indicator, or nothing at all. Each sets a different customer expectation and a different oversell risk. Decide it, and decide what happens to the last unit when two people want it.
Guest checkout or accounts
Forcing account creation costs conversions and gives you a customer record. Unless there is a real operational need for the account, guest checkout wins on the numbers.
Who owns the shop after launch
A shop needs weekly attention: content, prices, promotions, the order queue. Naming the owner before launch is what separates a shop that grows from one that is quietly abandoned in month four.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Launching without redirects
The most expensive mistake in any replatform, and it is invisible until the traffic drops. Existing URLs are mapped one by one, tested on staging and verified again straight after launch.
Catalogue structured for the warehouse
Categories that mirror your storage make products hard to find and filters useless. The structure follows how customers search, and the warehouse view is a separate concern.
Payment tested only on the success path
Declines, timeouts, abandoned redirects and duplicate submissions are what actually happen. Each one is tested, because an order stuck between paid and confirmed is a support call and a refund.
Fulfilment left until after launch
Orders arrive on day one. If picking, shipping and invoicing are not wired up, somebody re-keys everything by hand and the errors start immediately. The order path is tested end to end before launch.
Performance treated as a later optimisation
Heavy images and a slow first render cost conversions on mobile from the first day, and the fix is much harder once the page is built. Page weight is a requirement during the build.
Thin product data
Missing descriptions, single images and absent attributes hurt both conversion and search visibility. Data quality is scoped as a workstream with an owner, because it is a bigger job than anyone expects.
No owner after launch
A shop with nobody looking after it stops earning. The owner is named before launch, and if there is not one, that is worth knowing before the build rather than after.
Not included
Stated up front so the proposal has no soft edges.
- ร Product photography, copywriting and translated marketing content, unless separately scoped
- ร Advertising spend, campaign management and marketplace fees
- ร Payment provider and carrier account fees, and merchant onboarding
- ร Guaranteed search rankings or traffic outcomes
- ร Warehouse operations design beyond wiring the order path through the system
- ร Ongoing content and promotion management after launch, unless contracted
How this is priced
Scoped as a build plus the operational wiring, with catalogue data treated as its own workstream because it is usually the largest and the most underestimated. Migration from an existing shop is quoted separately, since the redirect mapping depends on how many URLs you already have.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
WT Theme eCommerce
eCommerce theme: brand-forward hero, category cards, featured products, why-us, reviews, newsletter, contact. Built for online stores, boutiques, multi-brand shops and retail brands. Optional website_sale integration.
Why here: Starting from a shop theme is cheaper than building layout structure from nothing, and it gives your team blocks they can edit later.
Theme/eCommerceWT Shopify Connector
Production-grade Odoo โ Shopify connector. Multi-store, two-way sync of orders/customers/products/inventory, webhook + scheduled updates, queue with retry/error visibility, fulfillment + tracking, returns/refunds, payouts, metafield mapping, abandoned-checkout recovery, KPI dashboard.
Why here: Where a storefront stays on Shopify and Odoo runs operations, a maintained connector avoids a bespoke sync.
Sales/CommerceGulf and South Asia Shipping Carriers
Aramex, SMSA, Naqel, Leopards and TCS shipping connector: rates, waybills, labels, cancellation and tracking, with a simulation mode and a full call log.
Why here: Rates, labels and tracking are the last mile of every shop launch, and doing them per carrier by hand does not scale.
Inventory/DeliveryMarketing Automation Campaigns
Drip campaigns over any Odoo model: an audience filter, a tree of timed steps, e-mails with open and click tracking, activities, server actions and tags.
Why here: Abandoned cart and follow-up sequences are where a shop earns back its build cost, once the basics are steady.
Marketing/Marketing AutomationPWA Mobile App + Real-Time Push Notifications
Install Odoo as a mobile app (PWA) and send real-time web push notifications to phones & desktops - branded app icon, one-click setup, reusable push API. No Enterprise, no app store.
Why here: Repeat purchase businesses get more from push than from another email campaign, and it avoids a separate app build.
ProductivityWT WhatsApp OTP - Signup Verification
Verify customer phone numbers via WhatsApp OTP during Odoo signup
Why here: Where sign-up fraud or bad phone data is a problem, verifying at registration is cheaper than cleaning the list later.
ToolsOnline Rental Store
Sell rentals through the website shop: a date range picker on the product page, availability checked on the server against bookings and against other visitors carts, period pricing, deposits and pickup and return dates in the portal.
Why here: Where the product is hired rather than sold, the shop needs date ranges and availability checks rather than a simple add to cart.
Website/WebsiteWhere we deliver this
Payment methods, carriers and buyer expectations differ by market. The country pages carry what applies where you sell.
Odoo E-Commerce: common questions
Should we use Odoo eCommerce or a dedicated platform?
If your stock, pricing, customers and invoicing already live in Odoo, running the shop there removes an integration and an argument about which system is right. A dedicated platform makes sense where the storefront experience is the product itself and the requirements go beyond what a built-in shop should be asked to do. It is a straight trade between one system and a better front end.
Can we keep our current design?
Usually yes, implemented as an Odoo theme. What is worth checking first is whether the current design converts. Rebuilding a layout nobody wanted to buy from is a cost with no return, and a launch is the cheapest moment to change it.
Will we lose our search rankings?
Not if the migration is done properly. Every existing URL is mapped and redirected, the mapping is reviewed before launch and verified again straight after. Skipping that step is the single most common reason a replatform loses traffic, and it is entirely avoidable.
Can we sell in multiple currencies and languages?
Yes, including right-to-left layouts. The work is more than translation: prices, tax treatment, shipping rules and content all vary by market, and it is much cheaper to design for that at the start than to add a second market to a shop built for one.
How does stock stay accurate?
It is the same stock record the rest of the business uses, so there is nothing to synchronise. What you decide is how it is presented: exact quantity, a simple availability indicator, or nothing. Each carries a different oversell risk, and the last-unit rule needs deciding either way.
What do you need from us to start?
Product data is the honest answer, and it is the thing that delays these projects most. Descriptions, images, attributes and prices for the catalogue you intend to launch with. Everything else can run in parallel. A shop cannot launch with an empty catalogue, however good the build is.
Read next
Odoo Integration
Connect Odoo with your stack and third-party APIs.
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Odoo Customization
Custom modules built to match your exact workflow.
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
POS Deployment
Retail / F&B / salon / clinic POS end-to-end.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.