Form enquiries
Contact, quote and callback forms creating Odoo leads with the message, the page it came from and the campaign that brought the visitor.
Most WordPress sites send their enquiries to an inbox, which is the quietest way to lose business. Nobody can say how many came in last month, which ones were answered, or which campaign they came from.
Connecting WordPress to Odoo turns that inbox into a pipeline. The same connection can carry portal logins, member records and content that sits alongside an Odoo shop.
Businesses running Odoo with OdooBots
Odoo WordPress integration turns site enquiries into CRM records and lets WordPress act as the public face of an Odoo-run business. Contact and quote forms create leads with their source and campaign attached, customers can reach an Odoo portal to see orders and invoices, member or subscriber records stay aligned, and content can sit alongside Odoo eCommerce where you want WordPress for the marketing and Odoo for the transactions.
If you also run WooCommerce, the shop side is a different piece of work with different rules — see Odoo WooCommerce integration. This page is about the site itself.
Six things can move between a WordPress site and Odoo, and the first one is usually the only one a business needs on day one.
Contact, quote and callback forms creating Odoo leads with the message, the page it came from and the campaign that brought the visitor.
New enquiries assigned by rule — by product interest, region or team — rather than by whoever happens to check the inbox.
A link from the site into the Odoo portal where a customer sees their own orders, invoices and support tickets.
Membership or subscriber records aligned between the site and Odoo, with matching so one person is not created twice.
WordPress for marketing pages and blog, Odoo for products and checkout, with navigation and branding kept consistent across both.
UTM parameters and referrer carried into the lead record, so marketing spend can be judged on enquiries rather than on clicks.
A visitor arrives from a campaign, reads a page and submits the enquiry form. A lead is created in Odoo with the message, the page, the campaign and the referrer. An assignment rule routes it to the right salesperson, who follows up from the CRM where the history is kept. The marketing team can then see which campaigns produce enquiries rather than only which produce traffic.
Portal access, member sync and content alongside an Odoo shop are each a further step, worth adding when there is a reason rather than all at once.
These are the decisions that are cheap to make now and painful to reverse once two systems have been exchanging records for a month.
Each plugin posts differently, so the mapping is built against your actual forms rather than a generic example.
Which form fields become which lead fields, including the ones that should go into the description rather than a column of their own.
How a repeat enquirer is matched on email or phone, so the pipeline does not fill with the same person four times.
Who gets a new lead, by product, region or round robin, decided before go-live so nothing sits unclaimed.
Which UTM and referrer values are stored, so marketing can be judged on enquiries rather than on traffic.
If customers get portal access, exactly what they can see, since this is a permission decision rather than a display one.
What stops bot submissions becoming leads, because an unfiltered form fills a CRM faster than a sales team can clear it.
We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a different tool, or tell you the connector will not reach.
Themes, plugins and content management remain where they are. Odoo should not try to run your site.
Fields added by a third-party plugin need their own mapping and are scoped as development.
The shop is a separate integration with its own rules. Treating it as part of the site connection is how scope goes wrong.
Each membership plugin has its own model of a member, so alignment with Odoo is per plugin rather than generic.
A slow or overloaded WordPress site produces failed submissions. Hosting problems appear as integration problems.
Running WordPress pages alongside an Odoo shop means two places to update branding. Worth choosing deliberately rather than drifting into.
Connecting WordPress to Odoo is less about the connector than about agreeing what is true where, and what happens when a record will not go through.
Understand which form plugin you use, how enquiries are handled today, whether customers need portal access and whether a shop is in scope.
Map each form field by field, agree duplicate matching, assignment rules and what attribution is captured, before anything is connected.
Connect WordPress to Odoo using the standard connector where one fits, and build only what the connector genuinely cannot reach. See Odoo customization.
Your records, in a test database, including the awkward ones — the cancelled order, the partial refund, the product that exists on one side only.
A queue for failed records with a named owner and an alert, because an integration nobody watches diverges quietly and the divergence is found at audit.
Cutover with a reconciliation on both sides, then hypercare, then ongoing support and AMC.
We do not publish one integration price, because the same connector costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.
We map every form against a real submission, including the spam, because an unfiltered connection fills a CRM faster than a sales team can empty it. Enquiries should arrive as a pipeline, not as a second inbox.
Product capabilities stated on this page are documented by Odoo. The mapping advice, failure handling and limitations come from our own integrations.
Tell us which form plugin you use and how enquiries are handled today. Those two answers shape the mapping, and the diagnosis call is free.