WooCommerce Request a Quote - WordPress Plugin

How to Set Up WooCommerce Request a Quote for a Store That Sells Through Price Requests

WooCommerce Request a Quote is not meant to turn a standard online store into a simple contact form. Its value lies elsewhere: it adds a controlled quote-request workflow to WooCommerce, where the administrator decides which products, categories, brands, and customer groups should see the request button, when the price should be hidden, what customer data should be collected, and at what point an approved quote should be turned into a cart or order.

This guide walks through the practical setup steps after installation: which rules to create first, how to build the quote form, how to configure the quote basket, emails, PDF, reCAPTCHA, popup mode, statuses, page builder compatibility, and final testing. Instead of repeating the plugin's short product description, this guide shows how to use WooCommerce Request a Quote in a real store: for a B2B catalog, wholesale buyers, products with custom configurations, and orders where the price depends on quantity, shipping terms, or manual approval.

One important limitation should be clear from the start: this guide does not cover purchasing the extension, entering license keys, or obtaining the paid version. It is focused on configuring a product that is already installed. Wherever an exact feature depends on the version, theme, WooCommerce setup, or the set of active extensions, it is best to test it on a site copy and verify it against the developer's documentation.

What Problem This Plugin Solves in a WooCommerce Store

A standard WooCommerce cart works well when the price is known in advance, the product can be purchased immediately, and all payment and shipping terms fit a typical checkout flow. A price request is useful when the customer is not ready to pay yet, and the seller needs to collect the quote contents, quantity, contact details, comments, and sometimes even the buyer's proposed price. WooCommerce Request a Quote adds a separate quote basket, a submission form, and an internal quote-handling workflow in the admin panel.

The clearest example is a wholesale store. A guest may see regular prices and a buy button, a retail customer continues shopping as usual, while a Wholesale or B2B role can get a quote button, a hidden price, or both at once. In the plugin rules, you can tie button visibility to products, categories, brands, stock status, and user roles. That lets you avoid breaking the entire catalog just to support one customer group.

The second common case is personalized products. If the cost depends on material, configuration, volume, lead time, or delivery terms, it makes sense for the buyer to submit a quote request with details. The plugin supports custom form fields: text, email, number, file, date, dropdown, multi-select, checkbox, radio buttons, and a terms consent field. So the form can collect more than just a name and phone number - it can gather the details a manager actually needs to prepare an offer.

The third use case is a catalog without public pricing. In these stores, the price may be hidden for guests or specific roles, and the standard buy button is replaced with a quote button. This should not be done without a reason: if a product can be purchased online without friction, forcing a quote request slows down the sale. But for complex B2B orders, industrial equipment, custom furniture, print jobs, spare-parts bundles, medical supplies, or large-volume purchases, that flow is often more intuitive than a standard cart.

Practical check: before you start configuring anything, write down one specific workflow: who comes to the site, which product they choose, whether they see the price, which button they click, which fields they fill out, who receives the email, and what happens after approval. If you cannot describe the flow as a single chain, do not apply plugin rules to the entire catalog yet.

Who WooCommerce Request a Quote Is For, and When It Is Unnecessary

The plugin is a strong fit for stores where pricing or offer availability depends on context. The site owner gets more than just a form - they get a controlled quote system: the customer adds multiple products to a quote basket, changes quantities, may enter a proposed price, submits their details, and the manager sees the quote in the admin panel, changes its status, adds products, adjusts pricing, adds shipping costs, attaches a PDF, and converts the approved quote into an order or cart.

These situations are especially well suited to it:

• B2B and wholesale sales. Different user roles can see different buying paths: a standard cart, a quote request, a hidden price, or a button that sends them to registration.
• Catalogs with negotiated pricing. The product can be shown publicly, while the price is replaced with text such as "Price on request" and the inquiry is collected through a form.
• Orders with custom configurations. The form can include extra fields, a file upload, a date, a text description, and other data needed for pricing.
• Stores where a manager manually confirms terms. Statuses, emails, and internal notes help move the quote from the first inquiry to an approved offer.
• Sites with multiple sales channels. The plugin can work alongside the regular cart without disabling direct purchase for every visitor.

You should not install the plugin just because "a quote request looks more professional." If the store has a simple catalog, fixed prices, straightforward shipping, and a relatively low average order value, the standard cart usually gets users to checkout faster. A quote request adds extra steps for the customer and more work for the manager. It pays off when negotiation is genuinely needed.

There are also technical situations that require caution. If the theme or page builder heavily changes the standard Add to Cart output, hiding the price or replacing the button may require additional settings in the page builder compatibility section. If the store uses many fields, personalization options, and files, check in advance which data is correctly carried into the quote, email, PDF, and order. The developer states compatibility with WooCommerce Product Add-Ons, but with one limitation: the file upload field is not transferred into the quote.

What to Check Before Installation and First Activation

This preparation is not just a formality. The plugin affects price visibility, buy button behavior, user roles, WooCommerce emails, and sometimes the path from quote to order. A mistake in the rules can make the quote button disappear where you need it, or replace purchasing on important products where it should not. Start with a site copy, or at least with one test product and a separate test category.

Platform, Theme, and WooCommerce

The WooCommerce Marketplace page for the extension lists the WordPress, WooCommerce, and PHP requirements, along with marketplace quality-check results. This article does not lock in version numbers because they become outdated quickly, but before installation, you should compare the current requirements on the product page and in the changelog. If your server, WordPress, or WooCommerce version is significantly behind, update the staging copy first, test the theme, and only then move changes to the live site.

The theme should use WooCommerce hooks correctly to output the price and buy button. If the product card is built with a page builder that replaces standard elements with its own widgets, enable compatibility through the plugin settings and test the output separately on the product page, store archive, and category page.

Products and Standard Price

The developer documentation specifically warns that if the Add to Quote button does not appear, you need to check not just the rule but also the product's regular price. The product must have a price filled in for the button to work. If you want to hide the price, use the Hide Price setting in the rule rather than leaving the price field empty. For a product that should only be shown as a quote request, you can use a technical placeholder price and hide it through plugin rules, but that approach should be tested on the product page, in the catalog, in emails, and during conversion to an order.

User Roles and Test Accounts

If you are setting up a B2B workflow, create test accounts in advance for a customer role, a wholesale role, and a guest view. Do not test the rules only from an admin account. An administrator or shop manager may have permissions and visibility that do not match the real customer experience.

Emails and Notification Delivery

The plugin sends notifications to both the administrator and the customer for different quote statuses. But if core WooCommerce emails or the site's mail delivery are not working, quote emails will fail too. Before configuring statuses, send a test WooCommerce email, verify that the sender address uses the site domain, and set up SMTP or a mail service if the store has already had email delivery issues.

Cache and Dynamic Elements

The quote basket, mini basket, and product button depend on the user role, session state, and selected products. Full-page caching, aggressive JavaScript optimization, and WooCommerce fragment caching can show a guest the wrong button state or fail to update the mini basket counter. For testing, temporarily disable optimization, then add exclusions for the quote page, cart fragments, and the theme's dynamic elements.

Installation and Initial Testing Without Risking Sales

Installation works like any other WooCommerce extension: upload the ZIP file through Plugins - Add New - Upload Plugin, install it, and activate it. After activation, a Request a Quote section appears in the WooCommerce menu with the main areas: All Quotes, Quote Rules, Quote Fields, and Settings. The Addify documentation may describe the structure in more detail, but the practical order is the same: first display rules, then form fields, then global settings, and finally quote processing.

The first rollout should be limited to a single product. Do not hide prices across the entire catalog until you have tested the full flow on one product. Pick a product where requesting a quote makes sense, fill in its regular price, place it in a separate category, and create a rule only for that category or that specific product.

Minimum Activation Sequence

1. Open WooCommerce - Request a Quote - Quote Rules and create a new rule.
2. Give it a clear internal title, such as B2B quote test, so it is not confused with production rules.
3. Select one product or one test category, not the full catalog.
4. Decide who should see the button: guests, all registered users, or a specific role.
5. Choose the buy button behavior: replace Add to Cart, keep both buttons, or replace purchase with a custom linked button.
6. Save the rule with Publish or Update.
7. Open the product as a guest and as a test user, add it to the quote basket, and submit the form.

Then check three places: the product page, the quote basket page, and the quote list in the admin panel. If the result is wrong in any one of them, do not expand the rule to the whole catalog. Fix that specific step first: product, role, rule, price, quote page, or email.

Quick takeaway: the first test is successful if the right user sees the quote button on the selected product, the wrong user still sees the standard buying flow, the form submits correctly, the quote appears in All Quotes, and at least the administrator receives the email.

Display Rules: Product, Role, Price, and Button in One Workflow

The strongest part of WooCommerce Request a Quote is not the button itself, but the rules. They let you define exactly where the store should behave like a quote-based catalog and where it should remain a standard WooCommerce store. A rule can apply to all products, selected products, categories, brands, out-of-stock items, and user roles. If you use multiple rules, apply priority so overlapping conditions do not produce unpredictable behavior.

How to Think About a Rule

It helps to read a rule like a sentence: "For these users, on these products, show this buying option." If that sentence becomes too long, split it into two rules. For example, a separate guest rule can replace purchasing with a button that leads to registration, while a wholesale rule can hide the price and show the quote button. Do not force every role and product into one universal rule if the behavior is different.

Rule Inputs

• User. Guest, all registered users, or specific roles such as Customer, Wholesale, B2B, and Retailer.
• Product scope. All products, selected products, categories, brands, or out-of-stock products if that behavior is needed.
• Price behavior. Show the standard price, hide it, or replace it with text.
• Button behavior. Replace Add to Cart, keep regular purchase alongside the quote button, or show a custom linked button.

Expected Outcome

On the front end, the customer should see only the path you intended. For retail, that might be the regular buy button. For a wholesaler, it may be a quote button next to the purchase button. For a guest, it may be a custom button that goes to registration. For products that require custom pricing, it may be a hidden price and a quote request instead of purchase.

When to Hide the Price and When to Keep It Visible

Hiding the price is useful when a public price gets in the way of a negotiated sales workflow: the price depends on quantity, region, technical specification, or customer status. But a hidden price can reduce trust when the customer expects a quick purchase. So do not enable Hide Price as a default site-wide mode. It is better to create separate rules for categories where the price truly needs manual calculation.

If a customer can buy the product without negotiation, keep the price and the normal cart, and use the quote button as an additional path. That works well for stores where a retail customer buys one item, while a wholesale buyer requests terms for a larger quantity. In the Hide Add to Cart Button setting, choose the mode that matches that approach: button replacement, two buttons, or a custom linked button.

How to Restrict Access to Registered Users Only

The Addify documentation suggests a practical pattern: create one rule for guests that replaces purchase with a custom button leading to the login or registration page, then configure a second rule for registered roles and show them the quote button. That way, a guest cannot enter the quote form without an account, while a signed-in buyer sees the intended workflow right away.

Be sure to test this in a private browser window. If you test only from the admin area, you may miss the fact that a guest sees the wrong button, the link points to the wrong page, or the cache is serving an outdated product layout.

Quote Basket, Mini Basket, and Submission Page

The quote basket works as a separate container for products the customer wants to request pricing for. They can add several products, change quantities, remove items, and then submit the form. On the product page or in the menu, you can show a mini quote basket so the user can see what has already been added. This is especially useful for B2B catalogs, where the customer builds a list of items instead of submitting a separate form for each product.

Mini Basket in the Menu

In the general settings, you can choose which menu the mini basket should attach to. The Addify documentation also mentions the [addify-mini-quote] shortcode for displaying the mini basket. Use it where the theme does not provide a convenient menu location or where you want the counter inside a dedicated block. If the store uses a custom header builder, test the built-in menu placement first, and only then decide whether you need the shortcode.

The mini basket should answer one simple customer question: "How many products have I already added to the quote, and where can I view the list?" If it appears in an awkward position, overlaps the mobile menu, or does not update after a product is added, check the cache, JavaScript optimization, and theme compatibility.

Quote Page and Form Layout

The quote basket page shows the selected products and the submission form. The plugin lets you choose a one-column or two-column layout, configure the table header color, and customize the submit button text and color. Do not turn the page into a long questionnaire with dozens of fields. The more complex the form, the more likely the customer is to abandon it or submit incomplete information.

For a typical B2B request, name, company, email, phone, country or region, a comment, and one field for requirements are usually enough. Add a file field only when the manager truly cannot evaluate the request without it: a drawing, mockup, specification, or SKU list. Keep compatibility in mind: if Product Add-Ons are used, the documentation says the Product Add-Ons file upload field does not transfer into the quote.

Popup Quote Submission

In newer versions of the plugin, the rules can enable quote submission through a popup window. This is useful when you want to keep the user on the current page: they add a product, see the quote contents, enter their details, and submit the request without leaving the page. This mode should be tested especially carefully on mobile devices, because a long form inside a popup can become awkward to use.

If you have many required fields, a two-column page is often better than a popup. If there are only a few fields and the request is simple, a popup shortens the path. Judge this by completion, not aesthetics: the user should be able to see the products, understand which fields are required, submit the form, and receive a clear success message.

Configuring the Quote Form: Which Fields the Manager Actually Needs

The quote form is often where marketing and operations start pulling in different directions. Marketing wants a short form, the manager asks for more details, accounting needs a company name, logistics wants a region, and production wants a file or a description. WooCommerce Request a Quote lets you add many field types and sort them, but that does not mean every field should be shown to every buyer.

Core Fields

Start with the fields you cannot respond without: name, email, phone, company, and comment. If the store has international or region-specific shipping conditions, add country or city. If pricing depends on timing, add a date. If a specification is required, add a file field or a text field with guidance, but do not make file upload mandatory for every category.

When creating a field, define the internal Title, technical Field Name, visible Field Label, field type, placeholder, width, sort order, and whether it is required. The Field Name is used as the data key, so it should be meaningful and should not be changed after launch. The visible label should make sense to the customer, not just to the manager.

How to Avoid Breaking the Form with Required Fields

Too many required fields reduce the number of submissions. Only contact details and the information that is truly necessary for pricing should be mandatory. If a field is helpful but not essential, leave it optional and explain in the hint why it helps. For example, "Preferred delivery date" can be optional, while the email field should stay required.

A practical field set for different types of requests

Use case	Fields usually needed	What to check after submission
B2B product volume request	Company, email, phone, region, comment, desired volume	The manager sees the item quantity, user role, and contact details for follow-up.
Custom configuration	Project description, file, date, comment, contact	The file or description appears in the quote and is not lost in the email.
Catalog without public pricing	Name, email, phone, company, country	The customer does not see a price, but clearly understands how to request a quote.

After configuring the form, submit a test quote and open it in All Quotes. Check not only the email, but also the quote record itself: the fields should be clearly displayed, and the manager should be able to see exactly what the customer requested. If an important parameter appears only in the email and not in the admin panel, the workflow becomes fragile.

Price, Proposed Price, Taxes, and Converting a Quote into an Order

In a simple request flow, the customer asks for a price and the manager replies manually. In a more advanced setup, the plugin can show the standard price, let the customer enter a proposed price, calculate totals, show tax, and convert an approved quote into an order or cart. These settings should be enabled deliberately, because they affect not only the form but also the customer's expectations.

Standard Price and Proposed Price

The Quote Attributes settings control whether the standard price and totals are shown in the quote basket, the customer's account area, and emails. The same section can enable the proposed price and its total. If the user can enter a desired price, the manager should understand that it is not the final amount, but the starting point for negotiation. The labels in the form and emails should make that distinction clear.

For stores with public pricing, it can make sense to show the standard price and provide a proposed price field: the customer sees the base cost but can request volume terms. For stores with hidden pricing, standard prices are better hidden through rules and in the quote basket so the customer does not see technical placeholder values. After changing this setting, test the product page, quote basket, customer email, admin email, and PDF.

Converting to Cart and Order

The plugin supports different paths after approval: the administrator can convert a quote to an order, and in newer versions there is also a quote-to-cart flow with a link for the customer. The Addify documentation lists statuses such as Pending, In Process, Accepted, Converted to Cart, Converted to Order, Declined, and Cancelled. Do not treat statuses as decorative labels. Each status should correspond to a real manager action and a customer-facing email.

If the quote becomes an order, verify the price, quantity, tax, shipping, and payment method. The Addify changelog mentions features related to conversion to cart, hiding certain payment methods during quote conversion, and adding shipping cost as Shipping Fee. That is why a real store needs the entire flow tested, not just the conversion button.

When to Enable Customer Conversion

Customer-side conversion is useful when the manager has approved the terms and the buyer should finish checkout on their own. Enable this only after emails and statuses have been configured. The customer should receive a clear message, sign in or use the provided link, see the approved quote, and understand exactly what they are paying for.

When Manual Conversion Is Safer

If the quote requires a manual stock check, custom shipping, nonstandard tax handling, or a separate contract, administrator-side conversion is safer. The manager records the terms first, then converts the quote into an order and sends the customer the email. That workflow is slower, but it reduces the risk of pricing errors.

Best Post-Install Settings: What to Enable First and What to Test Later

After activating the plugin, it is easy to fall into a trap: open every tab, enable every feature, and end up with a complex system that is hard to test. WooCommerce Request a Quote works better with a different order. First build the minimum working quote workflow, then add features that shorten the customer path or help the manager, and only after that turn on advanced modes such as PDF, popup submission, REST API, and hidden payment methods.

Base Layer: Rules, Form, and Quote Page

The first layer should handle the appearance of the button and successful quote submission. That includes Quote Rules, Quote Fields, and the basic quote page settings. At this stage, you do not need to enable proposed price, PDF, complex email flows, or multiple statuses right away. What matters is a stable chain: the right user sees the button, adds a product, submits the form, and the manager sees the quote in the admin panel.

A typical starting setup looks like this: one rule for one category, 4 to 6 form fields, one admin email, one customer email, and a standard quote page instead of a popup. If that path works, you can expand the workflow. If it does not, the number of moving parts stays low and the issue is easier to find.

Usability Layer: Mini Basket, Ajax, and Redirect

Once the core flow has been verified, you can configure what happens after the click. The plugin's general settings include Ajax add-to-quote on the product page and catalog, redirect to the quote page after adding a product, redirect to a custom page, or showing a message without redirecting. The best choice depends on the length of the request flow.

If the request is simple and the customer adds one product, redirecting to the quote page helps preserve momentum. If the customer is collecting multiple products, it is usually better to keep them in the catalog, show a success message, and display the mini basket. If you enable redirect too early, the customer has to keep going back to the catalog, which gets in the way of building a multi-item quote.

How to Check Ajax Without Technical Debugging

Open a category, add a product to the quote basket, and look for three signs: does the success message appear, does the mini basket counter change, and is the product duplicated after a page refresh? Then repeat the check on the product page and under another user role. If one workflow works and another does not, the issue may not be Ajax itself at all, but a specific theme template.

Trust Layer: Messages, CAPTCHA, and Submission Confirmation

The user should understand what happened after the click. The custom messages settings let you change the message shown when a product is added to the quote basket, the quote basket link text, and the message shown after form submission. Do not settle for an abstract Success. Give the user a clear outcome instead: their quote request was received, a manager will follow up, and the list of added products is available at the link.

Google reCAPTCHA V2 makes sense if the form is open to guests or the site receives automated submissions. But add CAPTCHA only after verifying that the standard form works correctly. That way, if submission fails, you will know it is related to the keys, domain, or CAPTCHA rendering rather than the form fields or plugin rules.

Advanced Layer: PDF, Offered Price, Hidden Payment Methods, and REST API

PDF, proposed pricing, conversion to cart, hidden payment methods, and REST API are not useful for every store. Each one should be enabled for a specific reason. PDF matters when the offer is forwarded internally or attached to a procurement process. Offered price matters when customers truly suggest their own price or provide a budget. Hiding payment methods matters when orders created from quotes should not be payable through all standard gateways. REST API matters when quotes are sent to an external system.

Before enabling any of these, ask three questions: who will use the outcome, where will it appear, and how will it be tested? If you do not have clear answers, the feature is unnecessary for now. The plugin offers a lot of flexibility, but a strong configuration is not the one with the most switches enabled - it is the one with a short, testable workflow.

Recommended feature rollout after installation

Stage	What to configure	When to move on
Core	One rule, selected products, main form fields, admin email	A test quote appears in the admin panel and the email is delivered.
Front-end path	Mini basket, Ajax, redirect or success message after adding	The customer understands where the product list is and how to submit the form.
Operations	Statuses, customer emails, PDF, internal notes	The manager can process the quote without an external spreadsheet or manual emails.
Integrations	REST API, CRM, complex pricing connections, hidden payment methods	The full workflow has been tested with a quote that uses real products.

How Managers Work with Quotes in the Admin Panel

For the customer, the plugin starts with a button. For the sales team, it starts with the All Quotes list. That is where you see whether the form has become a manageable workflow or is still just another stream of unstructured inquiries. A good setup should answer the manager's basic questions: who submitted the quote, which products the customer wants, what quantity is needed, what price they proposed, what the current status is, and what the next action should be.

How to Read a Quote Record

Inside the quote, the manager sees the customer details, products, quantities, descriptions, standard and proposed price if those columns are enabled, plus any custom form fields you created. If the manager has to open the email, then the product, then a separate spreadsheet with comments, the form was designed poorly. The information needed for pricing should appear directly in the quote details.

Test the quote record with a real example: a product with a long title, a variation, multiple products, quantity greater than one, a comment, a file, a proposed price, and a customer company. If any of that information is displayed poorly, it is better to fix the field label, field order, or form layout before launch.

Statuses as a Workflow, Not Decoration

Statuses are only useful if each one has a clear meaning. For example, Pending means the quote was received but not reviewed yet. In Process means the manager is clarifying price or availability. Accepted means the terms are approved and the customer can move to payment or order placement. Declined and Cancelled help keep outdated quotes out of the active work queue.

If the team is small, do not overcomplicate statuses. Three or four stages that everyone interprets the same way are usually enough. The more statuses you add, the greater the risk that managers will use them differently and customer emails will go out at the wrong time.

Internal Notes and Customer Comments

The plugin supports notes, and they are useful for tracking negotiation history. Keep manager-only notes separate from messages intended for the customer. An internal note can capture cost details, inventory limits, supplier agreements, or the reason for rejection. A customer-facing message should stay polished and should not expose internal discussion.

The check is simple: add an internal note and make sure the customer does not receive it by email. Then add a message that is supposed to go to the customer and verify the email. This is essential if multiple managers work with the same quotes.

When to Create a Quote on the Customer's Behalf

The Addify documentation describes the option to create a quote from the admin panel. This is useful when the customer reaches out by phone or email and the manager wants to keep the request inside the same system. But that flow should be clearly separated from standard online submissions. The internal title, status, and comment should make it obvious that the quote was created by a staff member, not by the customer.

After creating a quote on behalf of a customer, check the email: the recipient should understand why they received the offer, which products it includes, and what they need to do next. If the customer did not create an account, do not send a link that requires login until you have verified access.

Safe Customizations Without Editing Plugin Files

With request-a-quote plugins, there is always a temptation to "quickly tweak the button," "slightly rewrite the email," or "send the quote to an external system." The main rule is simple: do not edit WooCommerce, theme, or plugin files directly. Those changes will be lost on update and can break the quote flow at the worst possible time. Use settings, a child theme, documented template overrides, and carefully controlled external integrations.

Renaming the Button and Text Through Settings

The safest customization is text-based. Rules include Custom Button Label, and the message settings control the success text, form submission text, and quote basket link text. Start there, not with CSS or PHP. Very often what looks like "bad UI" is really just unclear wording, and can be fixed with labels such as "Request Pricing," "Added to Quote," or "View Quote List."

Check the text in three places: the product page, the category page, and the post-click message. If the button looks correct on the product page but breaks in the catalog, that is a template issue, not a wording issue. Do not make global styling changes until you know exactly where the element is rendered.

Email Templates Through the Theme

If you need to change the structure of an email, use the override path documented by the developer and keep the copied template in the theme. Before making changes, capture the "before" version of the email, edit the staging copy, and send test emails for different statuses. After a plugin update, compare the comments in the original template with your copy, because the developer may have added new data or adjusted the layout.

Safe limit: changing the order of email blocks, adding explanatory text, or removing an unnecessary line is fine. Rewriting the quote data retrieval logic without documentation and testing is not. If you need a different data set, first check whether the issue can be solved through form settings and quote fields.

Button Styling Without Invented Selectors

The Addify product page and plugin settings mention button color controls. Use those first. If you need the button to match the theme more closely, do not paste CSS copied from someone else's site: class names may differ in your version and theme. Open your browser's developer tools, find the actual button selector used on your site, and add CSS through the child theme or through Appearance - Customize - Additional CSS, if your theme uses that area.

After changing CSS, test the hover state, mobile layout, the product page, the category page, and variable products. Rollback should be easy: remove one CSS snippet and clear the cache. If fixing the button requires too many !important rules, it is better to go back to the plugin settings or the theme template, because that CSS will be hard to maintain.

Sending Data to a CRM Through REST API

If the business workflow requires a CRM, use the REST API only as a controlled integration. Create a separate WordPress user with minimal permissions, generate WooCommerce REST API keys in WooCommerce - Settings - Advanced - REST API, use HTTPS, and send only the data you actually need. In testing, verify quote list retrieval, reading a single quote, and updating status if that action is truly required.

Do not store keys in public JavaScript, do not place them on public pages, and do not send them to unverified services. If the integration stops working, revoke the key first and create a new one with fewer permissions, then investigate the bug in the integration code.

Emails, PDF, and Statuses: How Not to Lose a Quote After Submission

Once the form is submitted, the real work begins. The plugin can send notifications to the administrator and the customer for different statuses, attach a PDF, and configure email themes and message text. If this layer is ignored, the customer may not understand that the request was received, and the manager may miss a new quote or send an email with the wrong wording.

Which Emails to Enable First

The minimum set is an admin notification for a new quote and a customer email confirming receipt. Then add emails for Accepted, Declined, Canceled, Converted to Order, or similar statuses that are actually used in your process. Do not enable every email at once if the manager does not yet have a clear rule for when to change each status.

In Request a Quote - Settings - Emails, check the admin or manager recipient addresses, whether PDF is enabled for the administrator and customer, the email subject, heading, and additional message. If you have multiple emails, make the wording distinct: the email confirming receipt should not sound the same as the one confirming an approved offer.

PDF as a Commercial Offer

A PDF is useful when the customer needs to forward the offer inside their company or attach it to a procurement process. In the PDF settings, you can define a logo, company name, address, layout, color scheme, border, terms, and whether the customer can download the PDF from their account area. Test the PDF using a real quote with multiple products, long titles, quantities, proposed pricing, and shipping.

Safe Email Template Adjustments

The Addify documentation shows the email template path inside the plugin and provides an example of a theme override: a template file can be copied to the theme folder at yourtheme/woocommerce/addify/rfq/emails/customer-info.php. That is better than editing the file inside the plugin, because an extension update may overwrite your changes.

Source templates:
plugins/woocommerce-request-a-quote/includes/emails/templates

Example theme override:
yourtheme/woocommerce/addify/rfq/emails/customer-info.php

Use template overrides only for small structural edits that cannot be handled through settings. Before changing anything, save a copy of the file, test the email with a sample quote, and after extension updates compare the template against the new version. If the team does not have a developer, it is safer to stay within the email theme settings, the additional message field, and the PDF options.

Compatibility with the Theme, Page Builders, and Other Extensions

The plugin changes elements that the theme and other extensions may also modify: the price, the buy button, the product card, the cart, emails, the customer account area, WooCommerce fragments, and sometimes PDF output. That is why compatibility should not be checked in the abstract, but by specific site areas.

Elementor, Divi, and Nonstandard Button Hooks

The Addify documentation explicitly states that page builders sometimes remove the standard Add to Cart hook and replace it with their own output. In that case, hiding the price, replacing the button, or adding the quote button may fail. To address that, the settings include a page builder compatibility section where you can try alternative methods and keep the one that works with your theme.

Test at least three surfaces: the single product page, the category page, and a product block created by the builder. If the button appears in one place and disappears in another, the rule may not be the real issue. Very often the cause is that different templates render the button in different ways.

WooCommerce Product Add-Ons and Personalization

Compatibility with WooCommerce Product Add-Ons is documented, but with one limitation: the file upload field does not transfer into the quote. This is critical for products where the uploaded file is the main source material: printing, engraving, or manufacturing from a drawing. If the manager needs that file, add a separate file field to the WooCommerce Request a Quote form and verify where it appears after submission.

Price Calculator and Configurable Products Builder

The WooCommerce Marketplace page lists compatibility with Price Calculator for WooCommerce and Configurable Products Builder. For those combinations, it is important to understand the boundary of responsibility. The calculator or configurator helps assemble the product parameters, while WooCommerce Request a Quote handles quote submission, processing, emails, and conversion to an order. Do not promise customers automatic perfect pricing until you have tested a specific product, quantity, variations, taxes, and data transfer into the quote.

Cache, Optimization, and User Role

If a rule depends on user role, the cache must not serve the same HTML to every visitor. If the mini basket updates through JavaScript, script optimization must not break the product-added event. If price hiding does not apply in a specific template, check whether the product card is being cached or whether the price is rendered through a custom theme block.

Fallback test: temporarily disable JavaScript minification, script combining, and full-page caching for the test category. If the button and mini basket work after that, re-enable optimization one setting at a time and isolate the conflict.

Practical Example: A B2B Category with Quote Requests Instead of Direct Purchase

Below is an example you can adapt for a wholesale store. The goal: for the "Wholesale equipment" category, show a quote button to wholesale buyers, hide the price, collect company details, and give the manager a way to review the quote. Retail customers, meanwhile, should keep their normal buying flow on other products.

Goal

The wholesale customer enters the category, adds multiple products to the quote basket, enters quantity and comments, and submits the request. The manager receives the email, opens the quote, reviews the products and proposed price, changes the status, adds shipping cost if needed, sends the customer a PDF, and after approval converts the quote into an order or cart.

Preparation

• Create a test category and add 2 to 3 products with a regular price filled in.
• Create a test user with the role that should use quote requests, such as Wholesale or B2B.
• Verify that the standard WooCommerce cart works without errors on a test product.
• Make sure WooCommerce emails are being sent and are not landing in spam.

Setup Steps

1. Open WooCommerce - Request a Quote - Quote Rules and create a new rule.
2. Name the rule so its purpose is obvious to the manager, for example Wholesale quote category.
3. Enable it for the selected category and choose the test category.
4. In Quote for User Roles, select the wholesale customer role. If the rule should also work for guests, create a separate rule instead of mixing it with the B2B role.
5. Enable Hide Price if the price should not be visible to that role, and set the replacement text.
6. In Hide Add to Cart Button, choose either quote button replacement or the two-button mode if direct purchase should remain available.
7. In the Custom Button Label field, enter a short label such as Request a Quote.
8. Go to Quote Fields and add the fields "Company," "Phone," "Project details," and, if needed, a specification file field.
9. In Settings, configure the mini basket in the menu, Ajax add-to-quote, and the redirect after quote submission.
10. In Emails, enable the admin email for a new quote and the customer email confirming receipt.

Checking the Outcome

Open the site as a guest, as a retail customer, and as a wholesale buyer. For each state, check the product page, the category page, and the quote page. The wholesale buyer should see the intended button and hidden price, the guest should see whatever flow you defined in a separate rule, and the retail customer should not lose direct purchase where quote requests are not needed.

After submitting a quote, open All Quotes. Check the products, quantities, form fields, status, admin email, customer email, and PDF if it is enabled. Then change the status to In Process or Accepted, send the notification, and verify that the customer receives the correct email.

A Common Pitfall That Breaks This Flow

If the button does not appear, do not start changing every setting at once. Walk through the chain: the product has a regular price, the rule is published, the correct product or category is selected, the user role matches, the cache has been cleared, the theme renders the standard WooCommerce button block, and page builder compatibility is enabled if needed. This order saves time and keeps troubleshooting from turning into random switching of settings.

How to Test the Full Setup

Testing should mimic the real path of both the customer and the manager, not just confirm that the button is visible. For WooCommerce Request a Quote, you need to go through the full cycle: product - quote basket - form - email - quote in the admin panel - status - PDF - conversion to order or cart.

Testing the Front End

• Product page. Check the price, button, quantity, variations, post-click behavior, and the add-success message.
• Category and shop pages. Make sure the button appears or is hidden according to the same rules used on the product page.
• Mini basket. Add several products and confirm that the counter, product list, and link to the quote page update correctly.
• Quote page. Change quantity, remove a product, fill out the form, submit the request, and verify the success message.
• Mobile view. Check the popup window, product table, and form fields at a narrow screen width.

Testing the Admin Panel

In All Quotes, make sure the quote has a clear title or number and includes the contact details, products, quantities, and standard and proposed price if those are enabled. Then change the status, add an internal note, and confirm that the note is not sent to the customer if it is meant to stay private. If there is a customer-facing note, test the email as well.

Testing Email and PDF

Send a test quote to an address that actually receives store emails. Check the subject, sender, heading, product list, pricing, PDF attachment, and links. If the email does not arrive, verify core WooCommerce emails first. The Addify documentation recommends exactly that order: disable the extension, test the WooCommerce new-account email, and only then investigate quote emails.

Testing Conversion to Order

If conversion to order or cart is enabled, create a quote with multiple products and a proposed price. Convert it to an order and check the line items, total amount, tax, shipping, order status, and available payment methods. If the settings hide some payment methods when converting a quote to cart, confirm that the customer sees only the allowed options.

Practical Combinations: When the Plugin Works Better with Other Systems

WooCommerce Request a Quote often works best not by itself, but alongside user roles, product personalization forms, price calculation, email delivery, and the store's internal sales process. It is important not to label every combination an official integration. Something is only an official integration if the developer or documentation explicitly says so. Everything else is a practical setup that should be tested on a site copy.

User Roles and Separate Registration for Wholesale Buyers

If the store serves both retail and B2B customers, use roles as the rule boundary. For example, a standard Customer buys directly, while Wholesale submits a quote. Wholesale registration can be a separate process: apply for the role, get manually approved, then gain access to the quote rules. The main friction point is caching and automatic role assignment after registration. The test is simple: after approval, a new user should see the correct button without manual cache clearing.

Product Add-Ons for Product Parameters

If a product has extra options, first verify which Product Add-Ons data is passed into the quote. The developer confirms compatibility, but with a limitation for the file upload field. For files, use a separate Request a Quote form field or another confirmed method. The rollback path is simple: disable the file field in the quote form and temporarily go back to receiving specifications through a comment or email until a stable workflow has been verified.

SMTP or a Mail Service for Notification Delivery

The plugin may generate the email correctly, but it does not control the reputation of your mail domain. If the store gets leads through quote requests, email delivery becomes part of the sales workflow. Use a sender address on your own domain, test core WooCommerce emails, and connect SMTP or a transactional email service if messages are being lost. After that, test every status, not just the new quote notification.

CRM or External System Through REST API

The Addify documentation describes REST API endpoints for rules and quotes based on WooCommerce REST API v3. That can be useful if quotes need to be sent to a CRM or an internal system. This kind of setup requires a developer: you need WooCommerce REST API keys, HTTPS, the correct access permissions, and validation of which quote fields are actually available. Do not expose keys more broadly than the integration requires, and do not send secrets to third-party tools without control.

Troubleshooting Common Issues

Problems with request-a-quote plugins usually happen at the intersection of rules, theme behavior, roles, email delivery, and caching. The list below is not a generic catch-all checklist - it is a practical map of symptoms that are specific to this type of WooCommerce setup.

The Add to Quote button does not appear on the product

Symptom: the rule exists, but the customer sees only the standard buy button or does not see the quote button at all. Possible causes: the rule is not published, the wrong product or category is selected, the user role does not match, the product price is empty, the theme outputs the button through a nonstandard hook, or the cache is serving an outdated product page.

What to check: open the product in the admin panel and confirm that the regular price is filled in. Then review the rule in Quote Rules, the test user's role, and the product category. Clear the cache and open the page in a private window. If the product page is built with Elementor, Divi, or a theme with a custom template, enable the available page builder compatibility settings and test the alternative methods.

How to fix it: first narrow the rule down to one product and one role. If the button appears, expand the scope gradually. If it still does not appear even for a single product, temporarily switch to a standard theme or a default product template on a staging copy so you can separate a plugin issue from a theme issue.

The price is hidden in the wrong places

Symptom: the price disappears for retail customers or, on the other hand, stays visible for the B2B role. The cause is almost always overlapping rules, role logic, caching, or a custom theme price output.

What to check: the list of active rules, their priority, product scope, roles, and the Hide Price mode. Open the same product as a guest, a regular customer, and a wholesale buyer. If the result changes after cache clearing, add exclusions for dynamic WooCommerce elements.

When to roll back: if price hiding affects too much of the catalog, temporarily disable the rule or switch to a two-button mode without hiding the price until the conflict is understood.

The quote submits, but emails do not arrive

Symptom: the record appears in All Quotes, but the administrator or customer does not receive an email. Possible causes: email notifications for that status are disabled, the recipient address is wrong, WooCommerce mail is not being delivered, the domain email is not configured, or the message is landing in spam.

What to check: review Request a Quote - Settings - Emails, then check core WooCommerce emails in WooCommerce - Settings - Emails. Send a WooCommerce test email or create a test account, as recommended by the Addify documentation. If core mail is broken, fix site mail delivery first.

The mini basket does not update or shows outdated products

Symptom: the product is added, but the mini basket counter does not change, the list stays empty, or it shows another user's product. Possible causes: page caching, JavaScript optimization, a theme conflict, or cached menu fragments.

What to check: in testing, disable script combining and deferred script loading, clear the cache, and try adding a product from both the product page and a category page. If the mini basket is embedded in a builder menu, try rendering it in a separate block with the confirmed [addify-mini-quote] shortcode and compare the behavior.

The popup form is awkward on mobile

Symptom: fields do not fit, the submit button drops too far down, the user cannot see the selected products, or cannot close the window. The cause is usually an overly long form, conflicting theme styles, or an unsuitable popup layout.

How to fix it: reduce the number of required fields, review the popup layout settings, test both a single-page and multi-step form if available, and for more complex quote flows use the standard quote page instead of the popup.

Product Add-Ons does not pass the file into the quote

Symptom: the customer uploaded a file in the product options, but the manager cannot see it in the quote. This matches the limitation documented for Product Add-Ons compatibility: the file upload field is not transferred. The fix is to add a separate file field to the WooCommerce Request a Quote form or change the workflow so the file is sent after the initial contact.

Converting to an order creates an unexpected total

Symptom: after converting the quote into an order, the total, tax, shipping, or payment method differs from what you expected. Possible causes: standard versus proposed price settings, tax mode, added shipping, hidden payment methods, or other pricing extensions.

What to check: create a test quote with one product, then with multiple products, then with a proposed price. Compare the quote details, PDF, email, and order. If the issue appears only with a specific pricing plugin, test that combination separately and do not roll it out across the catalog until it is confirmed.

Product Video: Where to See the Interface in Action

Addify includes a demo video in the documentation specifically for WooCommerce Request a Quote. It is useful as a quick visual reference: you can see how products are added to the quote, how the admin settings look, and how the overall quote workflow fits together. Use the video as a supplement to this guide, not as a replacement for testing on your own theme and products.

After watching it, it makes sense to return to the sections on rules, form fields, and verification. Those are the areas that most often need adjustment for a specific store.

Questions to Resolve Before Launching on a Live Site

Can the plugin be used for only one product category?

Yes. The rules can target specific products or categories, and they can also apply different logic by user role. This is the best way to start: enable quote requests for a limited group of products, verify the workflow, and only then expand the rule.

Why does the product still need a standard price if that price is hidden?

The developer documentation states that an empty price field may prevent the quote button from appearing. If the price needs to be hidden, use the Hide Price setting and the replacement text rather than removing the price from the product. After that, test the emails, PDF, and order conversion.

Can I keep normal purchasing and add a quote request next to it?

Yes. In the button behavior settings, you can choose a mode where Add to Cart stays visible and the quote button is added next to it. This works well for a mixed store: the retail customer buys immediately, while the B2B customer requests terms for a larger quantity.

What should I do if the theme or Elementor does not display the quote button?

Start by checking the rule, product, role, and standard price. If all of that is correct, open the page builder compatibility settings in Request a Quote - Settings - Page Builders and test the available alternative methods. These issues are often caused by the theme replacing the standard WooCommerce button hook.

Is the plugin suitable for products with files and personalization?

Yes, if the form fields are configured correctly and data transfer is tested. Compatibility with WooCommerce Product Add-Ons is stated, but the file upload field does not transfer into the quote. If the file is critical, add a separate file field to the quote form and verify it in the admin panel, email, and PDF.

Should I enable reCAPTCHA immediately?

If the form is available to guests, protection against automated submissions is usually a good idea. The plugin supports Google reCAPTCHA V2. But first test the standard form submission, then add the reCAPTCHA keys and test submission again as both a guest and a registered user.

Can quotes be sent to an external CRM?

The documentation describes REST API endpoints for rules and quotes. This kind of workflow is possible as a developer integration built on WooCommerce REST API, but it requires HTTPS, correctly scoped keys, and field validation. Do not store keys in exposed locations, and do not grant broader access than the integration needs.

Does the plugin affect SEO?

A quote request does not create a guaranteed SEO benefit by itself. What matters more is whether you have hidden important information from the user without explanation or broken the product page experience. If the price is hidden, add clear replacement text, explain the request conditions, and provide a fast path to the form. Search engines and users need clarity, not an empty button where commercial information used to be.

When WooCommerce Request a Quote Is the Right Choice

WooCommerce Request a Quote is a good fit when the store truly sells through negotiated terms: B2B quantities, custom-priced products, hidden wholesale conditions, personalization, manager-led offers, PDF quotes, and quote-to-order conversion. Its strength is not a single button, but the combination of rules, the quote basket, the form, statuses, emails, and admin-side processing.

Before launching on a live site, go through the full test cycle: product, role, rule, hidden price, form, email, PDF, status, order conversion, and mobile layout. If everything works on a test category, you can extend the rules to real products and gradually enable additional workflows: popup quote submission, the mini basket in the menu, offered price, reCAPTCHA, PDF, and REST API integration.

If, after testing, you can see that the plugin fits your actual workflow, move to the download section and download the latest version of WooCommerce Request a Quote to test it on a staging copy of the site. That way, you preserve normal sales and can safely enable the quote workflow only where it is genuinely needed.