Price Match to a Competitor Price, per customer - Worth Considering?

[burt]

Assuming Shopowner is happy with request, he sets "status" to on (and sets expiry_date if applicable).
This then shows to the Customer (on relevant product_info page), assuming within expiry date.

pm_pi.png

[burt]

I think it's quite an interesting concept. Perhaps not for all shops (or even any shops ), but it makes it really easy for everyone involved:

Customer-friendly
Instead of abandoning their cart or shopping elsewhere, customer can quickly request a price match. It feels like the shop is "on their side."

Shopowner control
You're not giving blanket discounts; you're selectively approving only valid requests.
You retain full control over who gets what.

Automated handling
Once approved, the system automatically applies the matched price to that specific customer for that product, so there is no manual messing about or risk of errors.

The overriding idea

Don't lose a sale just because the same product is a bit cheaper elsewhere.
It's a way to keep the customer happy, maintain control, and make the process smooth for both sides.

[burt]

Any feedback or ideas or comments would be appreciated.
Useful to you, no, maybe ?

[Dan Cole]

Any feedback or ideas or comments would be appreciated.
Useful to you, no, maybe ?

I'm not interested but I think it would be useful to some. For me is it just not the sort of practice I want to encourage.

Dan

[burt]

Thanks Dan, appreciated feedback.

I think such a system is not really about price, it's more about catching that potential buyer at the moment she's thinking "its $1 cheaper at XYZ", and maybe initiating a conversation, where you might be able to say (eg) well yes it is 50c cheaper at XYZ but we give free shipping whilst XY charge $4.99...

[Dan Cole]

Thanks Dan, appreciated feedback.

I think such a system is not really about price, it's more about catching that potential buyer at the moment she's thinking "its $1 cheaper at XYZ", and maybe initiating a conversation, where you might be able to say (eg) well yes it is 50c cheaper at XYZ but we give free shipping whilst XY charge $4.99...

In theory it sounds great but I've done this in the past and I simply ended up with a few customers who wanted price matches on everything I offered (you can always find a better price) and I ended up spending a lot of time and effort with customers, that in hindsight, I ready didn't want.

Dan

[burt]

Circling back on this ... I was wondering about an automatic way to accept a Price Match. For example, a new input box on the admin product editing/adding screen that allows shopowner to set a "minimum acceptable" price match, per product;

EG:

Grapefruit: $9.99 (normal price)
Minimum Acceptable Match: $8.75

Customer asks for a Price Match of $7.50 [ie, lower than your minimum acceptable]
-> The system does not say "no", instead it simply does as normal and sends the Price Match for review
-> Shopowner enters dialog with Customer.

Customer asks for a Price Match of $9.00 [ie, higher than your minimum acceptable]
-> The system sets up a Price Match, immediately usable by the Customer.
-> Completely hands off for shopowner.

--

Note that the threshold (minimum acceptable price) is never publicly exposed, so the system can't be gamed, with other guardrails such as allow shopper to have just one request per product.

I think a Price Match system is a solid idea for some shops, depending on what products, what prices, customer demographics, shopowner ethos and so on. Unsure if this "auto approval" might be useful or not, but if anyone has feedback, or other ideas, this is the thread... I'd be grateful.

[burt]

AI says (of the auto approval idea):

Final assessment

Usefulness: High (for the right segment)
Adoption: Medium (depends on trust + UX)
Risk: Low (margin + behavioral effects)
Differentiation: Strong (this is not common in carts) <------ this is what I am most interested in


-------

What “differentiation” actually means here

Most ecommerce platforms (Shopify, WooCommerce, OpenCart, etc.) compete on:

• Theme/UI
• Extensions/plugins
• Checkout optimisation
• Marketing integrations

Very few compete on:

> Pricing intelligence and negotiation mechanics

Your idea sits in that underdeveloped layer:

> Dynamic, conditional pricing based on customer intent

That’s rare.

---

What competitors typically do (and don’t do)

Most carts support:

• Static pricing
• Discount codes
• Tiered pricing (bulk)
• Sales/markdowns
• Manual price match workflows by shopowner

These are all:

> Seller-initiated pricing changes

---

What does NOT exist (generally)

• Customer-initiated pricing with system logic
• Automated acceptance thresholds
• Negotiation systems embedded in the software
• Real-time “offer evaluation”

So your feature is fundamentally different:

Standard ecommerce
-> Seller sets price
-> Discounts are broadcast
-> Static rules
-> One-way pricing

Your idea
-> Customer proposes price
-> Discounts are conditional
-> Interactive pricing
-> Two-way pricing
---

Why this matters strategically

1. You’re introducing intent-driven pricing

A normal store doesn’t know:

> “This customer is willing to buy at £9.00 right now”

Your system captures that moment.

That’s powerful because:

• It converts hesitation into action
• It monetises “almost buyers”

2. It behaves like negotiation without friction

Real negotiation can be:

• Slow
• Manual
• Socially uncomfortable

You’re turning it into:

• Instant
• Private
• Scalable

That’s a structural shift, not a UX tweak.

3. It sits between two proven models

Your idea is a hybrid of:

“Make an Offer” (eBay-style)

• Customer proposes price
• Seller accepts/rejects

Dynamic pricing engines (Amazon-style)

• Prices adjust based on rules

You’re combining them into:

> Rule-based acceptance of customer offers

That combination is extremely uncommon in standard carts.

Where this creates real differentiation

1. Feature-level differentiation (surface)

On a feature list, this stands out immediately:

• “Auto-approve price matches”
• “Customer-driven pricing rules”

Most carts can’t say this.

2. Capability differentiation (deeper)

You’re enabling something others don’t:

> The ability to safely say “yes” more often

Most systems are built to:

• Protect margin
• Enforce pricing

Yours can:

• Capture marginal gains
• Flex intelligently

3. Philosophical differentiation (strongest)

Most ecommerce platforms assume:

> “The price is the price”

You’re saying:

> “The price is a range, and we control the boundaries”

That’s closer to:

• Real-world retail negotiation
• B2B pricing behavior
• Marketplace dynamics

Hidden upside (this is the interesting part)

If adopted, this feature could evolve into:

1. A pricing intelligence system

• “Most accepted price per product”
• “Average requested discount”
• “Conversion vs threshold”

2. A behavioural signal engine

Shopowner learns:

• Which products trigger negotiation
• Where pricing feels “wrong” to customers

3. A competitive tool

Shopowners can effectively say:

> “We’ll match within reason—instantly”

That’s a strong value proposition vs competitors.

Bottom line

This isn’t just:

> “Another pricing feature”

It’s:

> A new pricing interaction model inside a traditional cart

That’s why differentiation is strong.

The blunt truth

• 80% of shopowners won’t use it
• 15% will try it
• 5% will *love it*

But that 5%:

• Will see real gains
• Will talk about it
• Will choose Phoenix Cart because of it

And that’s exactly how differentiation works in practice.

[burt]

I guess, in simple terms, the idea is;

Auto Approve the "easy yes's" - those you would have approved anyway.

[BatteryTrader]

I suppose if it's built in, it does not have to be used. and lines could be introduced to it gradually. If a line does not have an auto amount allocated, it would revert to manual checking: sending an email to the store owner, who then double-checks the URL to see if it matches, decides whether it can be accepted, etc.

But it would have to stop the use of a discount code as well on that purchase, if that's not the system it's using (which I assume it's not)