My wife Lena paints. Oils, acrylics, watercolors. Flowers, landscapes, the occasional cello or violin from her music series. Each painting is its own thing, photographed and listed on her store at artbylena.com. The catalog has crept past a hundred and twenty pieces and keeps growing.
Last spring, two weeks out from Mother's Day, she decided to run a 20% sale on the flower paintings. The right move - flowers are what people buy for their mothers. She opened the WooCommerce admin and started editing each painting in the Flowers category. Set a sale price. Set a start date. Set an end date. Save. Next painting. Save. Forty-something paintings later her shoulders hurt and the spreadsheet she'd opened to keep track of the original prices was wrong in two places. On the day the sale was supposed to end, she had to do it all again in reverse: open each painting, clear the sale price, save. Another evening of clicking.
She did this once. She is not doing it again.
The default WooCommerce sale model - per-product sale price, per-product start and end date - is fine for a single product. It does not scale. It does not need to.
The reframe: a sale is a rule, not a price
Stop thinking of a sale as something you set on each product. Think of it as a rule that lives next to the products and applies on the fly:
- Filter - which products this rule covers (category, tag, country)
- Discount - percentage or fixed amount
- Window - start and end dates and times
- Priority - tiebreaker when a product matches more than one rule
Set the rule once. TIV Sales Assistant is the WooCommerce extension that implements this model: it computes the right price at display time. No prices are written to the products themselves. When the window closes, the prices revert because nothing was ever overwritten in the first place.
For Lena's Mother's Day sale, the rule is nine words long:
20% off the Flowers category from May 1 to May 11.
Two clicks (select Flowers, type 20) plus the dates. The forty-something paintings in that category are now in the sale. They stay in the sale until May 11 at midnight. On May 12 the prices revert. She doesn't log in. There is no debris in the database, because nothing was written to the paintings in the first place.
What the bulk editor doesn't do
WooCommerce's bulk product editor has a "Set sale price" action. It works for the products you select. It has two problems that matter for a catalog like Lena's:
The reversion is your job. The bulk editor sets prices. It does not unset them. When the sale ends you have to remember to bulk-edit them back. If you wrote the original prices in a spreadsheet beforehand, you're already doing the wrong thing - the spreadsheet is the source of truth, and the database is a copy that's about to drift.
Filters are lossy. "All flower paintings done in oil" requires you to pre-filter to oil-tagged products before the bulk action. If you forget the filter, you discount everything. There is no rule object that remembers "this sale was for oil-on-flowers"; only the products themselves remember, via their prices.
A rule-based discount system has neither problem by construction. Reversion is automatic because nothing was overwritten. Filters are part of the rule definition, persisted, and re-applied every page load.
What the workflow actually looks like
You open the Sales Assistant dashboard. You click "Add Calendar Sale." You fill in:
- Name - "Mother's Day Flowers 20%"
- Discount - 20%
- Filter - category: Flowers
- Dates - May 1 to May 11
- Priority - 10
You save. You close the tab. You don't open the admin again until the next sale.
If you need to nudge the dates a day later, you don't open the editor - the list view's quick edit lets you change priority and dates inline. Five seconds.
If you want a second rule that bumps the discount on a subset (an extra 5% off oil paintings during the same window, say), you create a second rule with a tag filter and a lower priority. The two rules coexist. The priority field is how you tell the system which one wins for paintings that match both.
Filters that matter in practice
The three filters Sales Assistant exposes today:
- Category - the most common discriminator. Flowers, Landscapes, Music each get their own rule.
- Tag - finer-grained than category. Oil, acrylic, watercolor cut across categories. A flower painting in oil and a landscape in oil are in different categories but share a tag.
- Country - based on WooCommerce's geolocation. "20% off for US and Canadian visitors during Mother's Day" without affecting UK customers, whose Mothering Sunday is in March.
The filters combine with AND logic. "Oil flower paintings, US and Canadian visitors only, May 1 to May 11" is one rule with three filters. No code, no custom fields, no conditional logic.
The catalog you don't have
The most useful thing a rule-based sale system gives you is the catalog you don't have. Lena's catalog has more than a hundred paintings today. The sale rule doesn't care how many. The Mother's Day rule keeps working as new flower paintings get added, because the filter is "category: Flowers," not a list of SKUs that gets stale.
Compare to the per-product workflow: every new flower painting added between May 1 and May 11 needs to be edited individually to be included in the sale. Or it gets missed. Either way, the work scales with the catalog. The rule does not.
What changes for the developer
If you're building a Woo store for a client, the rule-based model changes what you write down in your handoff doc.
Old handoff:
To run a sale, edit each product, set the sale price, set the dates. Use the bulk editor with these caveats: prices need to be reset by hand at the end of the sale.
New handoff:
To run a sale, open Sales Assistant -> Add Calendar Sale, fill in the discount and the filter, set the dates. Done.
That's the whole training. It fits on a sticky note. It also means the client won't call you in panic at 11pm on the day a sale was supposed to end because they forgot to revert the prices.
When the per-product model is still right
Two cases:
A single hero product gets a unique price for marketing reasons. "The new commission is $499 instead of $799 for launch week." Edit the product.
You're discounting irregular subsets that don't map to category or tag. A handful of paintings the artist wants to clear because they don't fit the next show. A rule with a tag filter is still cleaner if you can add a temporary tag, but if you can't, the per-product editor is fine for a handful.
For everything else - any sale that touches a category, a tag, a country, or a date range - the per-product editor is the wrong tool. It is the default tool because it shipped first and because Woo can't assume a third-party plugin is installed. It is not, on any defensible cost-benefit analysis, the tool you should reach for first.
Try it before you trust it
There's a live demo at demo-sales-assistant.tiv.net. Each visitor gets their own isolated demo - your sales don't affect anyone else's view, so you can experiment freely. Create a Mother's Day rule, watch the prices change, delete it, try it again with a tag filter. Five minutes will teach you the workflow better than the rest of this article.
The store owner two weeks out from Mother's Day, clicking through forty paintings on a Sunday evening - she's the case for rule-based discounts. The case isn't subtle. The default just hasn't caught up yet.
TIV Sales Assistant on the WooCommerce marketplace.
