Web Store
WooCommerce
Connect your AI to WooCommerce
Store owners, shop managers, and operations teams run their commerce stack across WooCommerce, a shipping platform, and an accounting system, but the answers they need most span all three. AI can bridge that gap, but only if it controls what data each role sees and what actions each role can take.
Why it matters
Capabilities that matter most for WooCommerce
01
Ready-made sales reports
Install summary and month matrix lists for WooCommerce orders, products and customers, so sales trends are ready on day one.
02
Store beside accounting
Join WooCommerce orders with accounting or payments lists to reconcile what sold with what was paid.
03
Governed AI for commerce
AI tools answer within per-user and per-team security and redact customer details a role should not see.
Use cases
Example AI Use Cases for WooCommerce
scenario
-
New WooCommerce shoppers do not appear in Constant Contact unless someone exports and imports them. Doing it by hand means comparing two customer lists by email, skipping the people already there, and remembering whether each shopper ever agreed to marketing email before you add them.
What popdock provides
--
Set a lookback period, 30 days by default, and optionally a Constant Contact list, and it reads the recent WooCommerce customers and checks each email against Constant Contact. The list you name must match exactly one existing list, and no list is ever created. You see who is already present and who is missing, and you are asked both to confirm and to say whether these shoppers consented to marketing email; permission to send is set only if you say yes. Duplicate emails are created once and nothing in WooCommerce is touched.
Business outcome
---
Recent shoppers reach your Constant Contact account without duplicates, and consent is recorded only when you have it.
scenario
-
After a Constant Contact campaign goes out, the clicks live in one system and the orders in another. Working out who clicked and then bought in WooCommerce means exporting the click list, searching orders email by email and checking each order date against the click date.
What popdock provides
--
Name the campaign and an attribution window, 7 days by default, and it reads the campaign's sends, opens and clicks from Constant Contact, then looks for WooCommerce orders placed by each clicker inside the window after their first click. Canceled, failed and refunded orders are left out, orders placed before the click do not count, and matching is by email only, never by name. You get the conversion rate, attributed orders and revenue per currency, and the most clicked links. It is read-only and states plainly that this is correlation, not proof.
Business outcome
---
You see which campaign clicks turned into WooCommerce revenue, measured honestly, without building a spreadsheet of clicks and orders.
scenario
-
A bounced or unsubscribed address in Constant Contact looks like routine list hygiene until it belongs to one of your best WooCommerce buyers. Spotting those cases means cross-checking each bounce against customer records and order history, which rarely happens.
What popdock provides
--
Choose a lookback period, 30 days by default, and it reads recent Constant Contact bounces and unsubscribes, then looks for each address among WooCommerce customers and guest orders. Matched shoppers are sized by orders and spend over the last year and ranked, with a note where a hard bounce on a recent buyer suggests the billing email is wrong. Repeat bounces are reported once with a count. It recommends who to reach through another channel, but it is read-only and never re-subscribes anyone.
Business outcome
---
Paying customers with a broken or opted-out email are caught early, ranked by what they spend, so you contact the right ones first.
scenario
-
Understanding one shopper means looking at their WooCommerce orders and refunds in one tab and their Constant Contact lists, opens and bounces in another. Without both side by side it is hard to tell whether a loyal buyer has stopped reading your email or a keen clicker has stopped buying.
What popdock provides
--
Give an email address and a lookback period, 180 days by default, and it builds one profile: WooCommerce orders, spend per currency, refunds and top products, next to the Constant Contact contact's permission to send, lists, tags, sends, opens, clicks, bounces and unsubscribes. Guest buyers are still found through their orders. Where the two systems hold different names, both are shown rather than one being picked. It closes with a short read connecting buying and email behavior, and nothing in either system is changed.
Business outcome
---
You understand a shopper's buying and email habits in one read, ready for a support call or a targeted offer.
scenario
-
Putting together a best sellers email means pulling the sales report from WooCommerce, checking each product is still published and in stock, copying names and prices, and building the campaign in Constant Contact. A product that sold out last week or a price copied wrongly ends up in front of every subscriber.
What popdock provides
--
Give a sender email and name and how many products to feature, five by default, and it takes the WooCommerce top sellers, keeps only published, in-stock products and records their real prices, including sale prices. It checks recent Constant Contact campaigns so you do not repeat one, then drafts a subject, preheader and mobile-friendly body for you to approve. Only after you confirm is a draft created in Constant Contact; nothing is sent, prices are never invented, and placeholders mark where product links go.
Business outcome
---
A ready-to-review campaign draft of in-stock best sellers lands in Constant Contact without copying a single price by hand.
scenario
-
Winning back lapsed buyers takes three separate jobs: finding paying WooCommerce customers who have stopped ordering, creating a coupon that cannot be abused, and writing an email that quotes the code and expiry correctly. Get the coupon wrong or the email out of step with it and the offer falls flat.
What popdock provides
--
Set how many days counts as lapsed and the discount, 180 days and 15 percent by default, and it sizes the lapsed WooCommerce customers and checks a sample against Constant Contact for reachable contacts. It proposes an unused coupon code with a 30 day expiry and one use per customer, and waits for your confirmation. The coupon is created first and the Constant Contact draft is written only if that succeeds, quoting the discount and expiry exactly as created. Existing coupons are never changed and nothing is sent.
Business outcome
---
A one-use win-back coupon and its matching Constant Contact draft are ready together, with the audience and send left for you.
scenario
-
Before you email or call a shopper, it helps to know what they have bought, but WooCommerce history does not travel to Constant Contact. Writing a summary note means totalling orders, picking out top products and refunds, and typing it onto the right contact without duplicating last month's note.
What popdock provides
--
Give an email address and a lookback period, 365 days by default, and it finds the Constant Contact contact, stopping rather than creating one if there is none. It reads the shopper's WooCommerce orders, order lines and refunds, leaves out canceled and failed orders and totals each currency separately. A short summary note is drafted, any similar existing note is shown so you can decide, and the note is added only after you confirm. Nothing in WooCommerce is changed.
Business outcome
---
Your Constant Contact contacts carry an accurate purchase summary, so outreach is informed by what each shopper actually bought.
scenario
-
The same customer can have one phone number and company in WooCommerce and another in Constant Contact. Spotting the differences means comparing records field by field, and formatting noise such as dashes in phone numbers or CA versus California hides the real conflicts.
What popdock provides
--
Give one email, or a lookback period of 90 days by default, and it reads the WooCommerce customers and their matching Constant Contact contacts, matched by email only. First name, last name, phone, company and state are compared after normalizing case, phone punctuation, country codes and state abbreviations. A blank on one side is reported as a gap rather than a conflict. You get tables of conflicts and gaps, with a note that WooCommerce billing details are usually newer, and neither system is changed or second-guessed.
Business outcome
---
You see exactly where customer details disagree between the two systems, without formatting noise, before anyone edits a record.
scenario
-
Entering a WooCommerce order in Dynamics 365 Business Central by hand means checking it is not already there, finding or creating the customer, matching every line by SKU and handling shipping. Enter it twice, or miss a line, and fulfilment and invoicing go wrong.
What popdock provides
--
Give the order number, and it reads the WooCommerce order, stopping on pending, failed, canceled or refunded status unless you say otherwise, and stops if Dynamics 365 Business Central already has it. It matches the customer by email and only creates a new one if you confirm, then maps every line by SKU or barcode, refusing a partial order. You review the plan and nothing is written until you confirm. The order is created, checked against the WooCommerce total, and a private note with the new number is added to the web order.
Business outcome
---
Web orders enter Business Central once and completely, with the store order noting where they went.
scenario
-
Each refund issued in WooCommerce needs a credit memo in Dynamics 365 Business Central against the right invoice. Working out which lines and prices to credit, and making sure the refund was not already credited, is fiddly, and a duplicate credit overstates the customer's account.
What popdock provides
--
Give the refund ID, and it reads the WooCommerce refund and its lines and checks Dynamics 365 Business Central for credit memos already covering it, stopping if found. It finds the posted invoice for the order, credits each refunded quantity at the invoiced price, and asks which account to use for amount-only refunds. You see the plan and nothing is written until you confirm. The credit memo is created unposted, its total is compared with the refund, and a private note is added to the web order.
Business outcome
---
Web refunds become accurate draft credit memos, never twice, with a clear link back to the store.
scenario
-
WooCommerce orders that are processing or completed should all be in Dynamics 365 Business Central. Some never arrive, some arrive twice and some land with a different total, and checking order by order is slow enough that it rarely happens. Problems surface only when a customer calls.
What popdock provides
--
Give a date range, and it reads processing and completed WooCommerce orders, ignoring those not expected yet, and looks each up in Dynamics 365 Business Central as an open sales document or posted invoice by order number. Orders are classed as matched, amount differs, missing or duplicated, and you see only the exceptions, missing ones first. Currency differences are shown rather than compared raw, and truncated ranges are flagged. No order is created or altered.
Business outcome
---
Missing, duplicate and mismatched web orders are caught before they turn into fulfilment or billing errors.
scenario
-
Every WooCommerce refund should be credited in Dynamics 365 Business Central. In practice some are never credited, some are credited for a different amount, and some belong to orders that were never invoiced, and telling these apart means checking several document types per order.
What popdock provides
--
Give a date range, and it groups WooCommerce refunds by order and checks Dynamics 365 Business Central for posted and unposted credit memos, then whether the order was invoiced at all. Each order is classed as credited, credited but not posted, amount differs, not credited, or order not in Business Central, with not credited listed first since it needs action. Amounts include tax on the Business Central side. No credit memo is created.
Business outcome
---
Uncredited web refunds are found and prioritized, so customer balances and revenue stay right.
scenario
-
A store catalog drifts from the item list in Dynamics 365 Business Central: SKUs that do not exist there, blocked items still on sale, and prices or stock that disagree. Checking every product and variation by hand is not realistic for a busy store.
What popdock provides
--
Optionally name a category and a limit, and it reads published WooCommerce products, using variations rather than parents, and finds each SKU in Dynamics 365 Business Central by item number, then barcode. Each SKU is classed as no SKU, missing, blocked, price differs or stock differs, with a table per class. SKUs are matched exactly, never by name, and a pattern of same-percentage price gaps is called out as a likely tax difference. Neither the catalog nor the items are edited.
Business outcome
---
Catalog problems are found by type, from missing SKUs to blocked items still for sale.
scenario
-
Online orders and refunds sit in WooCommerce while balances, credit limits and blocks sit in Dynamics 365 Business Central. Knowing whether a web buyer is blocked, over limit or overdue means checking both systems by email, which nobody has time to do before every decision.
What popdock provides
--
Give an email address, and it gathers WooCommerce orders, spend and refunds, including guest checkouts, then finds the matching Dynamics 365 Business Central customers by exact email and lists open invoices tied to web orders. Flags appear only where true: blocked but ordering online recently, over the credit limit, overdue invoices, or not set up or set up twice. It never tries spelling variations and changes nothing.
Business outcome
---
Support and finance see a web customer's full standing at a glance before acting on an order.
scenario
-
When someone asks where a WooCommerce order stands, the answer spans the store and Dynamics 365 Business Central: was it entered, invoiced, paid, refunded and credited. Tracing it means searching several document types by order number and comparing lines yourself.
What popdock provides
--
Give the order number, and it reads the WooCommerce order, lines and refunds, then finds every Dynamics 365 Business Central document carrying it: open orders, posted invoices and credit memos. Lines are compared by SKU and quantity, and for a partly paid invoice it shows what has been applied. A one-line verdict says in sync, not yet in Business Central, amounts differ or refunded but not credited, and duplicates are flagged. Records are read, never edited.
Business outcome
---
Any web order question is answered with a clear verdict across store and ERP.
scenario
-
Dynamics 365 Business Central holds the true stock and prices, but WooCommerce has to be updated to match. Doing it by hand across products and variations is slow, and a careless bulk update can overwrite the wrong fields or push prices that include tax into a store that does not.
What popdock provides
--
Choose stock, price or both, and optionally a category, and it compares published WooCommerce products and variations with Dynamics 365 Business Central by SKU. Stock is rounded down and never negative, and only differences are listed. Missing, blocked and ambiguous SKUs are skipped and named, and if price gaps share one percentage it stops to ask about tax. You confirm the change list and can drop rows. Only stock and regular price are written, results are read back, and nothing is written to Business Central.
Business outcome
---
The store reflects ERP stock and prices after one reviewed update, with nothing else touched.
scenario
-
Orders sit in processing in WooCommerce long after Dynamics GP has invoiced them, because someone has to check each one in GP and update the store by hand. Customers wait for a completed notice, and an order marked complete before its invoice is posted causes its own confusion.
What popdock provides
--
Give a start date and a maximum number of orders, and it reads the WooCommerce orders still in processing and looks for a posted Dynamics GP invoice carrying each order number as the customer PO. Only orders with a posted invoice qualify, totals that differ by a cent or more are set aside, and two posted invoices for one order are flagged as a possible duplicate. You confirm the list, warned that customers usually get a completed email, and then each order is completed with a private note naming the GP invoice. GP is never changed.
Business outcome
---
Store orders move to completed as soon as GP invoices them, with a note tying each one to its invoice.
scenario
-
Keying a web order into Dynamics GP means checking it is not already there, finding the right GP customer, matching every store SKU to a GP item and retyping prices and freight. One wrong item number or a second copy of the same order and fulfilment or billing goes wrong.
What popdock provides
--
Give a WooCommerce order number, a batch and a document ID, and it first checks Dynamics GP for an existing sales document with that order number and stops if one exists. It resolves the GP customer by email, matches each line SKU exactly to a GP item and stops if any line has no match. You see the full sales order, with a warning when discounts may already be in the prices, and nothing is created until you confirm. The order and lines are then read back and the GP total compared to the store. It never creates GP customers.
Business outcome
---
Web orders arrive in Dynamics GP once, with the right customer and items, and a total you can check.
scenario
-
Products get added to the WooCommerce store without a matching item in Dynamics GP, and store prices drift away from the GP list price. Checking means opening each product and variation, finding its SKU in GP and comparing prices one by one, which rarely happens until an order fails.
What popdock provides
--
Name a category, or leave it open, and it reads the store's products and their variations, then looks up each SKU in Dynamics GP by exact item number. For matched items it compares the store regular price with the GP list price for the item's selling unit of measure. You get store SKUs missing from GP, price differences sorted by size, and products with no SKU at all. Where GP holds several price rows and no currency was named, it lists them rather than flagging a difference. Nothing in Dynamics GP or WooCommerce is changed.
Business outcome
---
Catalog gaps and price drift between the store and Dynamics GP show up before they turn into failed or mispriced orders.
scenario
-
Every WooCommerce order should reach Dynamics GP as a sales document, but imports fail quietly and totals change after edits. Checking a week of orders means searching GP by PO number for each one and working out which of its quote, order or invoice to compare.
What popdock provides
--
Give a date range, and optionally an order status, and it reads the WooCommerce orders and looks for each in Dynamics GP by customer PO number, trying the order ID as well when it differs. When an order has several GP documents it compares the store total with the most advanced one, an invoice ahead of an order ahead of a quote. You get orders missing from GP, total differences, and GP documents whose customer name looks nothing like the buyer. Currency mismatches are reported without being called differences. It reads from Dynamics GP and WooCommerce but writes nothing back.
Business outcome
---
Orders that never made it into Dynamics GP, or arrived with the wrong total, are caught in one pass.
scenario
-
The store says an item is in stock while Dynamics GP has nothing available, or the reverse, and customers order goods you cannot ship. Comparing means reading each product and variation, finding the SKU in GP and subtracting allocated from on hand for the right site.
What popdock provides
--
Name a category and optionally a GP site, and it reads WooCommerce stock for each product and variation, then reads Dynamics GP quantities by exact SKU. Available quantity is on hand less allocated, for the chosen site or all sites combined, with negative figures treated as zero for comparison but shown as they are. You get differences sorted by size, items in stock online but not in GP, items available in GP but out of stock online, and SKUs not in GP or not stock managed. No record in Dynamics GP or WooCommerce is touched.
Business outcome
---
Overselling and hidden stock are spotted early, with each difference tied to a SKU and a GP site.
scenario
-
Before approving a large web order you need the customer's Dynamics GP standing, but GP cannot search by email. You guess at the company name, check the email on each candidate, then look at holds, credit limit and overdue invoices while the order waits.
What popdock provides
--
Give the customer's email, or their GP customer ID, and it reads their WooCommerce record or recent orders, including guest checkouts. It finds the GP customer by company or last name and accepts only a candidate whose email matches, listing the candidates and asking when none or several do. You see hold and inactive flags, balance against credit limit, overdue documents, address and phone differences, and recent store spend, with one line on anything that needs action. It is read-only in Dynamics GP and WooCommerce.
Business outcome
---
You know whether a web customer is on hold or overdue in Dynamics GP before you ship their next order.
scenario
-
When list prices change in Dynamics GP, someone has to update the same SKUs in WooCommerce, product by product and variation by variation. Mistakes are easy: the wrong unit of measure, a price that drops below a running sale price, or a zero price published by accident.
What popdock provides
--
Give a list of SKUs, and optionally a currency and unit of measure, and it finds each SKU in the store and reads its Dynamics GP list price. You see current and new regular prices side by side, SKUs already matching are left out, and any new price at or below the sale price is flagged. SKUs with several or no GP price rows, or a zero price, are skipped rather than guessed. Nothing changes until you confirm, and then only the regular price is written. Sale prices, stock and GP are never touched.
Business outcome
---
Store prices follow Dynamics GP list prices with every change reviewed first and no accidental zero prices.
scenario
-
Keeping WooCommerce stock levels in line with Dynamics GP means reading available quantities in GP, subtracting what is already allocated, and typing the result into each product and variation. It is slow, so it gets done weekly at best, and the store sells stock that is already allocated.
What popdock provides
--
Give a list of SKUs and optionally a GP site, and it reads each SKU's Dynamics GP available quantity, on hand less allocated, rounded down and never below zero. You see current and new store stock side by side, with SKUs that already match left out and missing SKUs listed separately. Nothing is written until you confirm, then only the stock quantity changes. If a product does not manage stock it says so rather than switching that on, and GP is never changed.
Business outcome
---
Online stock matches what Dynamics GP can actually ship, updated in minutes with every change approved.
scenario
-
When a customer asks where their order is, the answer runs from WooCommerce through Dynamics GP sales documents into receivables. Following it means matching lines by SKU, finding the invoice, and checking which payments were applied, across several screens.
What popdock provides
--
Give a WooCommerce order number and it reads the store order, its lines and any refunds, then finds the Dynamics GP sales documents by customer PO number. Lines are matched by SKU and compared on quantity and price, and any invoice is followed into receivables for the amount still owed and the payments applied. It flags invoices not yet in receivables, refunds with no matching GP credit, and duplicate documents. It closes with one sentence on where the order stands. Dynamics GP and WooCommerce stay exactly as they were.
Business outcome
---
You can tell a customer exactly where their order stands, from cart to cash, in one answer.
scenario
-
When a WooCommerce shopper needs to be invoiced on account, someone sets them up in Sage Intacct by retyping their details. Without checking by email and name first, a second customer record gets created for someone already there.
What popdock provides
--
Give the shopper's email, and it reads the WooCommerce customer, or their latest order for a guest checkout, then searches Sage Intacct by contact email, billing company and name. A match only counts when the Intacct email agrees or is blank, and a different email is shown as a possible wrong match for you to judge. If the customer exists, nothing is created. Otherwise you review the values and confirm before one customer is created and read back, with the street address and country noted as left to complete.
Business outcome
---
Online shoppers become ledger customers once, with no duplicates and nothing written until you approve.
scenario
-
Orders keep shipping from WooCommerce to customers who are over their credit limit or long overdue in Sage Intacct, because nobody checks the ledger before fulfilment. By the time finance notices, the goods are gone.
What popdock provides
--
Set the order status and an overdue threshold, and it groups open WooCommerce orders by customer and finds each one in Sage Intacct by email, company or name, only accepting a match where the email agrees. Customers are flagged when their balance plus open orders exceeds the credit limit, an invoice is too far overdue, or they are inactive, with the reason shown. You choose which orders to hold; each is set on hold with a private note giving the reason, and customers never receive it.
Business outcome
---
Risky orders are paused before they ship, with the credit reason recorded on each order for your team.
scenario
-
Posting a WooCommerce order into Sage Intacct by hand means matching the shopper to a customer, mapping each product to an item by SKU and checking nobody posted it already. Skip the check and the order is billed twice; guess the customer and it lands on the wrong account.
What popdock provides
--
Name the order, and it reads the WooCommerce order and its lines, skips unpaid or canceled orders, and stops if a Sage Intacct document already carries that order number. The customer is matched by email, company or name, with a match only accepted where the email agrees, and you are asked rather than having a customer created. Each line must match one Intacct item by SKU or UPC, orders over two lines are refused, and tax, shipping and discounts are flagged as not carried. Nothing posts until you confirm, and a private order note is added only after a second yes.
Business outcome
---
Store orders reach your ledger once, on the right account, with a note on the order showing where they went.
scenario
-
Your WooCommerce catalog and Sage Intacct items are supposed to describe the same products, but SKUs go missing, discontinued items stay published and prices drift. Some stock differences are just orders waiting to ship, which makes real problems hard to separate from timing.
What popdock provides
--
Optionally name a category or warehouse, and it reads published WooCommerce products and their variations and matches each SKU to a Sage Intacct item by item ID or UPC. It lists SKUs missing or inactive in Intacct, stock and stock status differences, and prices that differ from the Intacct base price. Stock gaps that equal units on processing orders are grouped as timing only. It is read-only, lists unmatched products without SKUs, and stops if no SKU matches at all.
Business outcome
---
Your store and ledger agree on what you sell, its price and its stock, with timing noise separated from real errors.
scenario
-
Paid WooCommerce orders should all end up in Sage Intacct, but some never arrive, others carry a different total, and refunded orders sometimes stay booked at full value. Finding them means matching order numbers against invoice references across two exports.
What popdock provides
--
Give a date range, and it reads paid WooCommerce orders, marking refunded ones, and matches them to Sage Intacct invoices and order documents by order number, counting an order and its converted invoice once. You get orders missing from Intacct, totals that differ, with a note when the gap equals shipping or discounts, refunded orders booked at full value, and Intacct documents that match no order. It is read-only and says when results are partial.
Business outcome
---
Store revenue in your ledger matches what was actually sold and kept, with missing and overstated orders listed.
scenario
-
Every refund issued in WooCommerce should have a matching credit in Sage Intacct, but they are often missed or keyed for a different amount. Receivables stay overstated, and tracing refunds back through orders to invoices by hand is slow.
What popdock provides
--
Give a date range, and it reads WooCommerce refunds and their orders, finds each order's Sage Intacct invoice by order number and looks for AR adjustments against it. Refunds are compared per order, since one credit can cover several refunds. You get refunds whose order never reached Intacct, refunds with no credit, credits for a different amount, and those fully credited, with the uncredited total. Where a balance dropped without an adjustment it says the credit may have been applied another way, and nothing is changed.
Business outcome
---
Every store refund is reflected in your receivables, and the uncredited total is clear before month end.
scenario
-
When WooCommerce stock falls out of step with Sage Intacct, the store oversells items you do not have or hides items you do. Updating quantities product by product and variation by variation takes hours, and one wrong edit can switch off stock tracking.
What popdock provides
--
Name a SKU or take every stock-managed product, choose on-hand or uncommitted and optionally a warehouse, and it builds a list of WooCommerce quantities that differ from Sage Intacct. Negative quantities become zero and are flagged, and unmatched SKUs are left alone. You see every change and confirm before anything is updated, in batches of 50 for long lists. Only the stock quantity is changed, never price, status or stock tracking, and every change is read back to confirm.
Business outcome
---
Your store shows the stock you really have, updated from the ledger with every change approved first.
scenario
-
Questions about a customer's account mean checking WooCommerce for their orders and refunds and Sage Intacct for their balance, overdue invoices and payments. Completed orders that were never invoiced fall through the gap between the two.
What popdock provides
--
Give the customer's email, and it reads their WooCommerce profile, orders and refunds for the lookback period, then finds them in Sage Intacct, only accepting a match where the email agrees. You get identity details from both sides with disagreements flagged, store activity by status, and the Intacct balance, credit headroom, open and overdue invoices and recent payments. Completed orders with no Intacct invoice are called out. Currencies are kept apart and nothing is changed.
Business outcome
---
You answer customer account questions from one view, and completed orders that were never invoiced are caught.
scenario
-
New paying WooCommerce customers do not always make it into your Mailchimp audience. Adding them by hand means checking each email against the audience first, and a careless import can resubscribe someone who unsubscribed or was cleaned.
What popdock provides
--
Name the audience, and optionally how many days back to look and the status to use, and it reads recent paying WooCommerce customers and checks each email against the audience. Anyone already a member in any status is skipped and counted. You see the list to add and are told that pending sends a confirmation email, and if you choose subscribed it asks you to confirm the customers gave consent at checkout, falling back to pending if you do not. Nothing is written until you say yes, and failures are reported with their error.
Business outcome
---
Recent buyers join your audience with consent handled properly and no unsubscribed contact brought back.
scenario
-
Product blocks and recommendations in Mailchimp depend on its store catalog matching WooCommerce. Finding products that never synced, sit under another id or still carry an old title means comparing two catalogs line by line, and the problems only show when a campaign displays the wrong product or none at all.
What popdock provides
--
Optionally filter by product name, and it reads the published WooCommerce catalog and finds each product in the connected Mailchimp store, first by id and then by title. Products are classed as missing, title mismatch, id mismatch or in sync, with titles compared exactly. For title mismatches it shows the exact changes and, only after you confirm, updates the Mailchimp title and reads it back. Missing products and id mismatches are reported as a store sync issue rather than forced, and WooCommerce is never changed.
Business outcome
---
Your Mailchimp catalog matches the store, so campaigns show the right products under the right names.
scenario
-
The revenue Mailchimp credits to a campaign includes orders that were later canceled, failed or refunded in WooCommerce. Finding the real number means locating each attributed order in the store by customer, amount and date, then subtracting refunds.
What popdock provides
--
Give a campaign id or title, and optionally the attribution window, and it reads the Mailchimp report and the orders attributed to the campaign. Each order is matched in WooCommerce by customer email, total and currency within the window after sending, and classed as confirmed, lost or unmatched. Refunds on confirmed orders are subtracted, and the headline compares Mailchimp revenue with net WooCommerce revenue as an amount and a percentage. Currencies are never converted, and nothing is written to either system.
Business outcome
---
You report what a campaign really earned after cancellations and refunds, with every lost order listed.
scenario
-
Abandoned carts in Mailchimp do not tell you who came back and ordered in WooCommerce, or who tried and failed at payment. Without that, follow-ups go to shoppers who already bought, and recovery cannot be credited to the right email.
What popdock provides
--
Choose how many days back to look, and optionally a minimum cart value, and it reads Mailchimp carts and searches WooCommerce for a later order from the same email. Carts are classed as recovered, attempted when only pending or failed orders exist, or unrecovered. Unrecovered carts are ranked by value with whether the shopper is still subscribed and whether they have bought before, and unsubscribed shoppers are never shown as reachable. Follow-ups are suggested in text only, and nothing is changed.
Business outcome
---
You know which carts came back, which are worth chasing, and which shoppers you can still email.
scenario
-
Winning back lapsed WooCommerce buyers means finding who has not ordered in months, checking which of them still subscribe in Mailchimp, creating a coupon and tagging the right contacts. By hand it is easy to tag people who unsubscribed or reuse a code that already exists.
What popdock provides
--
Name the Mailchimp tag, and optionally the inactivity period and discount, and it finds paying WooCommerce customers with no qualifying order since the cutoff, then keeps only those subscribed in the tag's audience. It proposes a coupon code, checks the code is unused, and shows the discount, a 30-day expiry, one use per customer and the contacts to tag. After you confirm, it creates one coupon and tags each contact, stopping before any tagging if the coupon fails. It never creates tags or sends the campaign.
Business outcome
---
Your win-back campaign is ready to send, with a unique code and an audience of lapsed buyers who still accept email.
scenario
-
Answering a shopper well means knowing what they bought in WooCommerce, what was refunded and how they respond to your Mailchimp emails. That takes several screens, guest orders are easy to miss, and the two systems often disagree on totals.
What popdock provides
--
Give an email address and it reads the WooCommerce customer, including guest orders, with order counts by status, net spend after refunds and the products in the three latest orders. From Mailchimp it reads audience status, tags, open and click rates, recent campaign activity, unsubscribes and the store's copy of the customer. A gaps section shows what one system knows that the other does not, with any disagreeing names or totals side by side. Records are joined on email alone, never on name, and nothing is written.
Business outcome
---
You see a shopper's buying and email history together, with any mismatch between the systems laid out plainly.
scenario
-
The Mailchimp for WooCommerce sync can quietly miss customers or carry stale order counts and spend. Checking means comparing each new customer's orders in WooCommerce with their record in the Mailchimp store, then looking the other way for customers only Mailchimp knows.
What popdock provides
--
Choose how many days back to check, and it finds the connected WooCommerce store in Mailchimp, then reads recent WooCommerce customers with their valid orders and spend. Each is classed as in sync, missing or out of sync against the Mailchimp store, and store customers WooCommerce does not know are listed as Mailchimp only. The report ends with the store's sync status, notes when many gaps point to the sync itself, and warns that customers created today may simply lag. Nothing is created or updated in either system.
Business outcome
---
You find sync gaps between store and email platform before they skew segments and revenue reporting.
scenario
-
When an order is refunded or canceled in WooCommerce, the Mailchimp store copy often keeps counting it, so campaign revenue looks better than it is. Fixing it means finding each full refund and cancellation, checking the order exists in Mailchimp and changing its status by hand.
What popdock provides
--
Choose how many days back to look, 7 by default, and it reads WooCommerce refunds and cancellations, treating an order as fully refunded only when its refunds equal its total. Each order is confirmed in the Mailchimp store by order id, never by email or amount. You see the planned changes, the partly refunded orders being left alone, and a warning that Mailchimp may send notification emails, and nothing is written until you confirm. Only the financial status is changed, and WooCommerce is never touched.
Business outcome
---
Mailchimp stops counting revenue you no longer have, and partial refunds are never marked as full ones.
scenario
-
Every WooCommerce sale that is paid still has to be recorded as a payment on its Rillet invoice. Matching orders to invoices by number, checking the amount due and posting each payment by hand is repetitive, and posting one twice or against an already paid invoice throws receivables off.
What popdock provides
--
Give a date range and the Rillet account to post to, and it reads the WooCommerce orders paid in that range and finds each one's Rillet invoice by order number or id. Orders are sorted into ready, no invoice, already paid, over the amount due and currency mismatch, and any order whose invoice already has a payment of the same date and amount is held back as possibly recorded. The account is checked as active, you see amounts due before and after, and nothing is posted until you confirm. Refunds are left for credit memos rather than netted against payments.
Business outcome
---
Online payments land on the right Rillet invoices once each, with possible repeats held back for you to check.
scenario
-
When WooCommerce sales are not flowing into Rillet, someone has to find the orders with no invoice and key each one in with the right customer, net amount and tax. It is tedious, and a second pass over the same dates easily creates duplicate invoices.
What popdock provides
--
Give a date range and the Rillet product to book against, and it reads the WooCommerce orders that count as sales, totals each one's item tax, and keeps only those with no Rillet invoice under the same order number or id. Customers are matched by email, or to a fallback customer you name, and orders it cannot place are listed rather than created. You review net, tax and total for each invoice and nothing is created until you confirm. Rillet invoices are re-read just before creating so a repeat run does not duplicate, and WooCommerce is never changed.
Business outcome
---
Missing online sales reach Rillet as receivables with the right customer and tax, without duplicate invoices from a second run.
scenario
-
A refund issued in WooCommerce still needs a Rillet credit memo applied to the original invoice, or receivables stay overstated. Finding the invoice, checking whether the refund was already booked and applying the right amount by hand is easy to get wrong, especially for refunds paid back outside the gateway.
What popdock provides
--
Give a date range and the Rillet product to credit, and it reads each WooCommerce refund with its lines, finds the order's Rillet invoice and skips any refund that already has a memo numbered for it. You see every refund with its reason and invoice balance, with manual refunds flagged and orders with no invoice listed apart, and nothing is created until you confirm. Each memo is then created and applied to its invoice, capped at the amount due, and left unapplied with a note when the invoice was already paid. If applying fails, the memo is reported as unapplied and never created twice.
Business outcome
---
Every WooCommerce refund is credited against the right Rillet invoice once, so receivables match what customers actually owe.
scenario
-
Customers who buy in WooCommerce and customers billed in Rillet are rarely recorded the same way. One system has the email, the other the company name, and locations drift, so working out who exists where means scrolling two lists and guessing at near matches.
What popdock provides
--
Optionally narrow by part of an email, and it reads paying WooCommerce customers and every Rillet customer with their emails. It matches by email first, then by company, then by full name, stopping at the first rule that fits and listing anyone matching several Rillet customers as ambiguous. You get exact matches, probable matches that need a person to confirm, customers in only one system and matched customers whose country or state disagree. It changes nothing, and explains that guest checkouts will not appear.
Business outcome
---
You know which online buyers are set up in your ledger and which need attention, without guessing at matches.
scenario
-
Month end means proving that every WooCommerce sale reached Rillet at the right amount. Checking order numbers against invoice numbers in two exports is slow, and canceled orders that were still invoiced are the kind of error that only shows up when a customer disputes a bill.
What popdock provides
--
Give a date range, defaulting to last month, and it reads WooCommerce orders and separates real sales from pending, failed and canceled ones. Rillet invoices are read with a seven day margin either side and matched on order number, then order id, never on amount or date alone. You get a summary and tables for orders missing from Rillet, amounts that differ by more than a cent, non-sales that were invoiced, and Rillet invoices with no order, noted as possibly from another channel. Currencies are not converted and nothing is changed.
Business outcome
---
You close the month knowing every online sale is booked once at the right amount, with exceptions listed for follow-up.
scenario
-
Refunds are easy to issue in WooCommerce and easy to forget in Rillet. Without a matching credit memo applied to the order's invoice, receivables are overstated, and refunds paid back by hand outside the gateway need the cash side checked as well.
What popdock provides
--
Give a date range and it reads every WooCommerce refund, then Rillet credit memos from a widened window and the invoices for each order. A memo numbered for the refund is an exact match, and a memo on the order's invoice for the same amount is a probable one. You get refunds not credited, with whether the order was ever invoiced, amounts that differ, memos not applied to their invoice, refunds made outside the payment gateway and stray memos. Nothing is created or applied; it points you to the job that books missing credits.
Business outcome
---
Refunds and credits agree at month end, and manual refunds are flagged for a cash check.
scenario
-
Before a sales tax filing, the tax WooCommerce collected should agree with what landed in the Rillet tax account. Totalling order line tax, taking off refunded tax and netting journal lines by hand takes time, and the difference rarely explains itself.
What popdock provides
--
Give a period and your Rillet tax account, and it confirms the account exists, sums item tax on WooCommerce sale orders and the tax on refund lines, then nets the credits and debits posted to that account in Rillet. A table by currency shows collected, refunded, net and posted tax and the difference. When they disagree it lists likely causes, such as shipping tax not in the WooCommerce figure, refunds in another period, orders not yet invoiced or filings posted to the same account. It never posts an adjustment; it says what one would be.
Business outcome
---
You file sales tax with the WooCommerce and Rillet figures reconciled and any gap explained.
scenario
-
When a customer calls about their account, the orders and refunds are in WooCommerce and the invoices, payments and credits are in Rillet. Piecing together one picture by email, and spotting where the two disagree, takes several screens and a lot of matching by hand.
What popdock provides
--
Give the customer's email and a lookback window, and it reads their WooCommerce record, orders and refunds, then finds them in Rillet by email, or by company or name, and reads their invoices, credit memos and payments. It flags sales with no invoice, paid orders whose invoice is still open, totals that differ, refunds with no memo and canceled orders with an open invoice. You get both sides summarized, the disagreements as a table and the obvious next step if there is one. Guest buyers are handled, and nothing is changed.
Business outcome
---
You answer a customer's account question from one combined view, with every mismatch between store and ledger already found.
scenario
-
A WooCommerce catalog collects errors over time: missing SKUs, duplicate SKUs, products with no price, sale prices above the regular price and negative stock. Each one costs sales or breaks an integration, but finding them means paging through every product and variation.
What popdock provides
--
Optionally name a category, and it reads WooCommerce products and variations, plus categories, tags and attribute terms when auditing the whole store. It flags missing and duplicate SKUs, missing prices, bad sale prices, negative stock, uncategorized products, variable products with no variations, and unused categories, tags and terms, and lists unpublished products without calling them wrong. Findings are grouped by rule, most harmful first, with examples and suggested fixes. It is read-only, skips grouped and external products in price checks, and warns when results may be truncated.
Business outcome
---
Catalog errors that cost sales are found in one sweep, with the most harmful ones at the top.
scenario
-
WooCommerce coupons pile up: generous ones with no usage limits, codes that expired months ago, and stackable discounts nobody meant to allow. A leaked high-value code with no limit can cost real money before anyone notices.
What popdock provides
--
Set how far ahead to look for expiring coupons, and it reads every WooCommerce coupon and checks it against nine rules: large discounts with no limits, no expiry and no limit, stackable large discounts, invalid amounts, used up, expired, expiring soon, never used, and fixed cart discounts with no minimum spend. You get a count per rule, a table for each, most severe first, and a recommended fix. It is read-only and does not estimate what a coupon has cost, because revenue cannot be tied to coupons here.
Business outcome
---
Risky and dead coupons are found before they cost you margin, each with a clear fix.
scenario
-
A WooCommerce store can lose orders without anyone noticing: a missing checkout page, no shipping zone beyond the default, or no tax rate for a country customers buy from. These settings live in different places and are rarely checked together.
What popdock provides
--
Optionally give a country code, and it reads the WooCommerce store pages, shipping zones, methods and classes, tax rates and where customers bill from. It marks cart, checkout and account page problems as critical, flags a store with no real shipping zone and any unused shipping classes, and lists customer countries with no tax rate, duplicate rates, and compound or non-shipping rates to confirm. Fixes are listed in order of importance. It is read-only, does not claim a zone lacks methods, and notes that a missing rate matters only where you charge tax.
Business outcome
---
Checkout, shipping and tax gaps are found before they cost orders or cause tax mistakes.
scenario
-
Changing a WooCommerce order status looks simple, but some moves have side effects: marking it refunded records a refund without returning money, cancelling a paid order keeps the money, and completing it emails the customer. Getting it wrong is hard to undo.
What popdock provides
--
Give the order number, the new status, an optional reason and whether to notify the customer, and it finds the order in WooCommerce and checks its history. It refuses refunded and points you to a proper refund, warns before cancelling a paid order, asks whether payment was received before marking an unpaid order processing or completed, and tells you when WooCommerce will email the customer. Nothing changes until you confirm, then the status is updated once, the reason is added as a note, and the order is read back.
Business outcome
---
Order statuses change without accidental refunds, kept money or surprise emails to customers.
scenario
-
Placing a WooCommerce order for a customer who called or emailed means finding them, matching each SKU to the right product or variation, and checking stock before you promise anything. A failed attempt retried carelessly gives the customer two orders.
What popdock provides
--
Give the customer email and up to three SKUs with quantities, and it finds the customer in WooCommerce, asking whether to create them or place a guest order if they are missing. Each SKU is matched to a product or variation, and it stops on a variable parent, an unknown SKU or not enough stock. You see the lines, prices, subtotal, paid status and invoice choice, and nothing is created until you confirm. The order is created once, the invoice is sent only if asked, the stored lines are read back, and a failure is checked before any retry.
Business outcome
---
Orders you place for customers are right first time, with stock checked and no duplicates.
scenario
-
When an order looks wrong in WooCommerce you have to read its lines, notes, refunds and payment details and then work out whether the money adds up. The notes alone can run to dozens of entries, and the real cause is often buried among them.
What popdock provides
--
Give the order number, and it finds the order in WooCommerce and reads its lines, notes, refunds, downloads and customer. It checks that lines, tax and shipping add up to the total, explains the status against payment, compares refunds with the total and works out how long the order has sat in its status. You get a one-line verdict, a timeline, a money reconciliation and any issues with their evidence. It is read-only, keeps customer-facing notes apart from staff notes, and says when a cause is inferred rather than recorded.
Business outcome
---
You understand any problem order in one read, with the money reconciled and the next step clear.
scenario
-
Putting a WooCommerce category on sale means working out the sale price for every product and every variation by hand, then editing each one. Miss a variation or overwrite a deeper existing discount and the promotion goes out wrong.
What popdock provides
--
Name the category and a percentage off, and it finds the category in WooCommerce and works out a sale price for each published simple product and variation from its regular price. Grouped, external and variable parent products, items with no regular price, and items already on a deeper sale are skipped and listed. You see every change and confirm before anything is written, in batches of 50 for large lists. Only the sale price is changed, failures are collected, and everything is read back to catch mismatches.
Business outcome
---
Category sales go live accurately across every variation, without touching regular prices or deeper discounts.
scenario
-
Refunding a WooCommerce order means working out what has already been refunded, what is still refundable, and whether the money goes back through the gateway or has to be returned by hand. Get the route wrong and the customer gets nothing back.
What popdock provides
--
Give the order number, a reason and an optional amount, and it reads the order, its refunds and its lines in WooCommerce to work out what is still refundable. It refuses orders that were never paid or are fully refunded, and rejects amounts above the remainder. For manual payment methods it tells you the money must be returned outside WooCommerce. You confirm the amount, route and reason, the refund is made once and read back with the new status, and a failed gateway refund is never retried as manual without your say.
Business outcome
---
Refunds go back by the right route for the right amount, with no over-refunds or silent failures.
scenario
-
WooCommerce orders get stuck in pending, on-hold, failed or processing, and each status means something different: an abandoned checkout, a bank transfer to check, a declined card or a paid order not shipped. Without a regular sweep, paying customers wait.
What popdock provides
--
Set an age threshold and an optional minimum total, and it pulls WooCommerce orders stuck in each of those four statuses, reading the latest notes for the 25 highest-value ones. Each order is classified with a recommended next action, and paid processing orders are treated as most urgent. You get a count and value per status, tables oldest first, and a do-first list. It is read-only, never adds amounts across currencies, and warns when a list may be truncated.
Business outcome
---
Paid orders waiting to ship are handled first, and abandoned or declined orders are cleared deliberately.
scenario
-
Low-rated WooCommerce reviews point to real product problems, but they are scattered across products and mixed with spam waiting for moderation. Reading them all to find the patterns takes time nobody has.
What popdock provides
--
Name a lookback period and a rating ceiling, and it reads recent low-rated WooCommerce reviews and the moderation queue, adding each product's name, SKU, overall rating and sales. Complaints are grouped into themes with a short example each, products with two or more verified low reviews come first, and held reviews are checked for waiting time and likely spam. It is read-only, uses reviewer names rather than emails, treats unverified reviews as weaker evidence, and says moderation must be done in WooCommerce.
Business outcome
---
Product problems surface from reviews early, and spam in the moderation queue is easy to clear.
scenario
-
Editing a WooCommerce coupon means finding it by code and making sure the change is valid. A usage limit below the times already used kills the coupon at once, and a new code breaks every email that carries the old one.
What popdock provides
--
Give the coupon code and the change you want, and it finds the coupon in WooCommerce, listing close matches if the code is not exact. It handles amount, discount type, expiry, usage limit, description and code, and says plainly when a change is outside that. It checks amounts, future expiry dates, usage limits against times used, and that a new code is free, warning that renaming breaks existing links. You confirm a before and after table, the coupon is updated once with only the changed fields and read back, and a new coupon is never created.
Business outcome
---
Coupon changes go live correctly without accidentally disabling a code or breaking a campaign.
scenario
-
Updating a WooCommerce customer's address or phone sounds quick, but country and state codes must be right, the login email cannot be changed the same way, and a billing email may already belong to someone else. It is easy to tidy a field nobody asked you to change.
What popdock provides
--
Give the customer email and the change, and it finds the customer in WooCommerce, listing close matches if the email is not exact. It converts country names to two-letter codes, expects state codes where they apply, explains that only the billing email can change, and warns if a new billing email belongs to another customer. You confirm a before and after table and are told that existing orders keep their old address. Only the fields you asked for are updated, once, and read back, and no customer is ever created.
Business outcome
---
Customer records are corrected accurately, with only the requested fields changed and no surprises on past orders.
scenario
-
Changing stock or prices in WooCommerce by SKU means working out whether the SKU is a simple product, a variation or a variable parent with no price of its own. Update the wrong record and the storefront shows the wrong price or stock.
What popdock provides
--
Give a SKU and any of a new stock level, regular price and sale price, and it finds the item in WooCommerce, stopping to list the variations when the SKU belongs to a variable parent. It checks stock is a whole number, prices are above zero and the sale price sits below the regular price, and asks before turning on stock tracking. You confirm a before and after table, then the right record is updated once with only the changed values and read back, including its stock status.
Business outcome
---
Stock and price changes land on exactly the right product or variation, with nothing else touched.
scenario
-
Understanding a WooCommerce customer means pulling their orders, what they buy, refunds, reviews and downloads, and some of their orders may sit under a different billing email. Building that picture by hand takes a long time.
What popdock provides
--
Give a customer email and a lookback period, and it finds the customer in WooCommerce or notes that they only order as a guest. It reads orders by email and by account, order lines, refunds, reviews and, where relevant, downloads, counting only real sales. You get a profile, order count and value, average order value, top products, refund rate and reviews, with flags for a high refund rate, failed or stuck orders, low reviews or a long gap since the last order. It is read-only and keeps currencies separate.
Business outcome
---
You know a customer's value and risk before a sales or service conversation, from their real order history.
scenario
-
WooCommerce shows stock levels but not how soon each item will run out, so you either reorder too late or chase items that barely sell. Working out sales per day for every low item is a spreadsheet job.
What popdock provides
--
Set a stock threshold and a lookback period, and it finds the WooCommerce products and variations that are low, out of stock or on backorder, and measures recent sales for each by SKU. It works out daily sales and days of cover and ranks the items, putting out of stock items that are still selling first. You get a full table, the five most urgent items, and a note of items whose stock is not tracked. It is read-only and never guesses a SKU match.
Business outcome
---
You reorder the items that are about to run out, in order of urgency, based on how fast they actually sell.
scenario
-
Answering how one WooCommerce product is doing means adding up its sales, splitting them by variation, checking refunds and reviews, and comparing stock with demand. Each piece lives in a different report.
What popdock provides
--
Give a SKU or product name and a lookback period, and it identifies the product or variation in WooCommerce, listing candidates if a name matches several. It reports units, revenue, orders, customers and average price with the trend across the period, a split by variation, refunds and refund rate, recent reviews with low ones quoted, top seller status and days of stock cover. It closes with two or three observations. It is read-only and keeps currencies separate.
Business outcome
---
You see how a product is really performing, and where it needs attention, in a single report.
scenario
-
Refunds in WooCommerce carry reasons, products, customers and staff, but nobody looks at them together until margins slip. Spotting the odd one, like an order refunded for more than its total, means reading every refund.
What popdock provides
--
Give a date range, and it reads the WooCommerce refunds, refunded lines and orders in it. You get the refund amount, count and approximate rate, reasons grouped, the top ten refunded products, repeat refunders, gateway versus manual refunds by staff user, and anomalies such as an order refunded beyond its total or large refunds with no reason. It is read-only, keeps currencies separate, and warns when results may be truncated.
Business outcome
---
Finance sees why money is going back and catches refund mistakes before they add up.
scenario
-
A WooCommerce sales summary for a period means adding up orders, discounts, shipping and refunds, excluding failed and canceled orders, and pulling top products and new customers. Done by hand, the totals often include orders that never paid.
What popdock provides
--
Give a date range, and it reads WooCommerce orders, refunds, order lines and new customer accounts for it, counting only completed, processing, on-hold and refunded orders as sales. You get net sales, order count and average order value, a summary of gross sales, discounts, shipping and refunds, orders by status with excluded ones marked, the top ten products and new registered customers, with a weekly breakdown for longer ranges. It is read-only, notes that gross sales include tax and shipping, and keeps currencies separate.
Business outcome
---
You get trustworthy period sales figures, with unpaid and canceled orders kept out of the totals.
scenario
-
Customers who stop buying from your WooCommerce store are worth a nudge, but finding them means grouping a year of orders by email and ranking by spend. Then a win-back code has to be set up so it cannot be abused.
What popdock provides
--
Set a lapse period, a discount and an optional code, and it reads WooCommerce order history and finds customers whose last order is older than that, dropping small one-off buyers and ranking the rest by spend. It checks the code is not already taken and proposes a percentage coupon, one use per customer, not stackable, expiring in 30 days, and explains it cannot be limited to these customers' emails. Nothing is created until you confirm, then the coupon is created once and read back. Sending it happens outside the store.
Business outcome
---
You see who to win back and get a safe, single-use coupon ready for your campaign.
scenario
-
New WooCommerce customers should flow into Drip, but some never arrive. Adding them by hand means checking each one against Drip first, because adding an email Drip already holds updates that person and can resubscribe someone who opted out. WooCommerce does not record marketing consent here either, so care matters.
What popdock provides
--
Give a lookback period and an optional tag, and it reads recent WooCommerce customers and keeps only those Drip has no record of, leaving everyone Drip already knows untouched whatever their status. You see the list with billing country and created date, how many were already in Drip and how many of those are unsubscribed, plus a reminder to add only customers who agreed to marketing. Nothing is added until you confirm, blank names are never invented, and each new subscriber is read back. WooCommerce is not changed.
Business outcome
---
Missing WooCommerce customers reach Drip once, and nobody who unsubscribed is quietly signed back up.
scenario
-
After running a Drip email series you want to know whether its members bought anything in WooCommerce. Finding out means exporting the members, searching orders for every email, removing cancelled and refunded orders, and totaling sales without mixing currencies. It is slow, and the result is easy to overstate.
What popdock provides
--
Name the Drip campaign and a lookback period, and it finds the campaign, asking you to choose if the name is ambiguous, then reads its members and checks their WooCommerce orders from the later of the campaign start or the lookback date. Cancelled, failed and refunded orders are left out and each currency is totaled separately. Nothing is changed. You get buyers as a count and percentage, revenue per currency, the top 10 buyers and members who have since left, presented as purchases by members, not revenue the campaign caused.
Business outcome
---
You get an honest read of what Drip campaign members bought in WooCommerce, by currency, without overstating the campaign's effect.
scenario
-
When a customer writes in, their marketing history is in Drip and their purchases and refunds are in WooCommerce. Getting the full story means checking both, remembering that guest checkouts have no customer record, and noticing problems like an unsubscribed person who is still ordering. Doing that per ticket takes too long.
What popdock provides
--
Give an email address and how far back to look, and it reads the Drip subscriber with status, tags, lead score and email campaigns, then the WooCommerce customer, orders and refunds, matching guest orders by email too. Nothing is changed in either system. The profile covers identity, marketing, purchases with any open orders, and refunds with reasons, totaling each currency separately. A gaps section flags disagreements such as an unsubscribe in Drip against recent orders, or a paying customer missing from Drip, and differing names are shown side by side.
Business outcome
---
Support sees a customer's purchases, refunds and email history in one place, with the conflicts between Drip and WooCommerce called out.
scenario
-
Repeat WooCommerce buyers who stop ordering are worth winning back, but finding them means counting past orders per customer, ruling out anyone who ordered recently, and checking Drip before enrolling them. Enroll the wrong people and you email someone who opted out or never signed up at all.
What popdock provides
--
Name the Drip win-back campaign and set how many days counts as lapsed and the minimum earlier orders. It reads WooCommerce completed orders, finds repeat buyers with nothing since the cutoff, and drops anyone already on the campaign. Only active Drip subscribers are kept, since enrolling an unknown email would create a new subscriber. You see each person's order count, last order and spend per currency, with a warning if the campaign is not active, and nothing is enrolled until you confirm. Enrollments are read back, and the campaign is never activated for you.
Business outcome
---
Lapsed repeat WooCommerce buyers enter your Drip win-back series, limited to subscribers who opted in.
scenario
-
Drip tells you which subscribers are engaged, but not whether they have ever bought. Separating warm prospects from lapsed customers means checking each high scorer's WooCommerce order history by hand, so the people most likely to convert often get the same generic email as everyone else.
What popdock provides
--
This job is read-only and changes nothing in Drip or WooCommerce. Set a minimum lead score and a lookback period, and it reads active Drip subscribers above that score and checks each email for WooCommerce orders, ignoring cancelled and failed ones. Each lead is grouped as never ordered, ordered but not recently, or ordered recently. You get the never-ordered group ranked by lead score with tags and subscriber age, the lapsed group with last order and spend, and a reminder that some may have bought under another email.
Business outcome
---
You know which engaged Drip subscribers have never bought in WooCommerce, ranked so the warmest prospects come first.
scenario
-
A WooCommerce refund often signals an unhappy customer, yet Drip keeps sending them the same campaign email. Spotting this means listing recent refunds, grouping them by customer and checking each person's Drip campaigns. Any fix needs care, because tagging an unknown email in Drip creates a new subscriber.
What popdock provides
--
Give a lookback period and, if you want, a tag. It reads recent WooCommerce refunds, groups them by customer with amount per currency, reasons and order numbers, and counts guest refunds with no email. Each customer is checked in Drip for status, tags and active campaigns, and you get the refunded customers still on active email plus counts for the rest. With a tag it shows who would be tagged and waits for your confirmation, tagging only active subscribers. It never removes or unsubscribes anyone and WooCommerce is not changed.
Business outcome
---
Recently refunded WooCommerce customers still on Drip email are visible, and optionally tagged, so you decide how to treat them.
scenario
-
New WooCommerce customers should appear in Drip with matching details, but some never arrive, some have unsubscribed and others carry a different name or country. Checking means looking each recent customer up in Drip and comparing fields by hand, and nobody does it often enough to trust the list.
What popdock provides
--
Nothing is fixed or written in either system: this is a read-only check, and unsubscribed people are reported, never changed. Give a lookback period and whether to include only paying customers, and it reads recent WooCommerce customers and looks each email up in Drip. Every customer is sorted into missing from Drip, unsubscribed, details differ on name or country, or matched, with a blank on one side treated as not recorded. You get counts and a table per problem group with the differing values side by side.
Business outcome
---
You see exactly where recent WooCommerce customers and Drip subscribers disagree, before any email goes to the wrong person.
scenario
-
To send product follow-ups or cross-sells in Drip you first need to know who bought a given item in WooCommerce. That means confirming the SKU, pulling order lines, removing cancelled and refunded ones, and tagging each buyer in Drip without creating subscribers for guests who never opted in.
What popdock provides
--
Give a product SKU, a lookback period and a tag, and it confirms the product or variation in WooCommerce, stopping if the SKU matches nothing or several products. It reads the order lines for that SKU, drops cancelled, failed and refunded orders and guest lines with no email, then sorts each buyer in Drip as subscribed, already tagged, unsubscribed or not in Drip. Only subscribed buyers are tagged, and only after you confirm. A sample is read back to check the tag, and WooCommerce is not changed.
Business outcome
---
Buyers of a specific WooCommerce product carry a Drip tag for targeted follow-up, with no new subscribers created by accident.
scenario
-
Stock is checked in the web store and in NetSuite separately, so overselling or hidden stock is found only after customers complain. Per-location quantities in NetSuite make a simple comparison harder still.
What popdock provides
--
Give a SKU, and optionally a NetSuite location, and it reads the product, or variation if needed, in WooCommerce for stock quantity and status, then the NetSuite item with its on-hand and available quantity by location. It shows both sides with a NetSuite total and the difference, and flags WooCommerce in stock while NetSuite has none available, out of stock while NetSuite has stock, and differing quantities. It states the assumption that the NetSuite item number equals the SKU, reports untracked WooCommerce stock as not tracked rather than zero, shows one side only if the SKU is missing in the other, and never updates anything.
Business outcome
---
A SKU's store stock and ledger stock are checked in one reply, with gaps flagged and no product or item changed.
scenario
-
Orders that never reached NetSuite tend to be found at month end, when someone compares a WooCommerce export with NetSuite sales orders by hand. By then the list is long and each missing order has to be traced to see why.
What popdock provides
--
Give a date range of up to 31 days, and optionally a minimum order total, and it lists WooCommerce orders, skipping cancelled, failed and trashed ones. It looks up each customer in NetSuite by email, then matches that customer's sales orders on total within a cent and date within three days. The report lists unmatched orders with the reason, either the customer is not in NetSuite or no sales order matches, plus counts and the unmatched value. Matches resting on total and date alone are labelled probable. It never creates orders or changes records in either system.
Business outcome
---
Orders missing from NetSuite are listed with a reason and their value in one pass, instead of being found at month end.
scenario
-
Finance matches web orders to NetSuite sales orders and invoices by eye. Over time the totals or payment status drift apart and nobody notices until the books are checked.
What popdock provides
--
Give a WooCommerce order number, and it reads the order and its lines, then finds the customer in NetSuite by email and searches sales orders within a few days of the order date at the same total, also trying the order number. It checks the invoice for the same customer and window, with total, paid and unpaid amounts. The reply gives the difference in totals and a verdict of matched, total mismatch, payment status mismatch or not found in NetSuite. If several NetSuite orders match it lists them all, and pending or on-hold orders are treated as expected unpaid. It updates nothing, adds no notes and issues no refunds.
Business outcome
---
One web order is confirmed against its NetSuite sales order and invoice, or the mismatch is named, with nothing updated.
scenario
-
Someone checks a customer in the WooCommerce admin and again in NetSuite by hand, comparing emails, names and phone numbers across two screens. Small differences go unnoticed, and it is not obvious whether the customer exists in both places at all.
What popdock provides
--
Give a customer email and PopdockAI finds the customer in WooCommerce and stops with a list if more than one comes back. It then finds the customer in NetSuite, retrying once by last name if the email finds nothing. A table shows email, first name, last name and phone with the WooCommerce value, the NetSuite value and a match or mismatch flag, comparing emails and phones without regard to case, spaces and punctuation. It states whether the customer is in both systems or only one and includes the NetSuite balance. Both values are shown rather than choosing one, and nothing is changed.
Business outcome
---
Support sees in one answer whether a customer exists in WooCommerce and NetSuite and which fields disagree.
scenario
-
Refunds issued in a WooCommerce store are not always booked in NetSuite, so the books and the payment gateway diverge. Finding the matching credit memo or cash refund for each one by hand takes time, and a refund with no record is easy to miss.
What popdock provides
--
Give a lookback in days, with a default of 30, and optionally one customer email, and PopdockAI lists the WooCommerce refunds in that period. For each one it finds the NetSuite customer by email and looks for a credit memo from the refund date, and also checks NetSuite cash refunds. Each refund gets a verdict of matched, amount differs or no NetSuite record, with the count and value of those with none. Cash refunds have no customer filter, so a date-only match is called weak, and a customer not found in NetSuite is separated from an unmatched refund. Nothing is changed.
Business outcome
---
Finance sees which WooCommerce refunds have no NetSuite record and the total value at stake, with weak matches marked.
scenario
-
Collections staff check what a customer owes in NetSuite, then open WooCommerce to see which of their orders are still pending, on hold or processing. Two systems, two screens, and no easy way to see where they disagree.
What popdock provides
--
Give a customer email and it finds the customer in NetSuite, reading their balance and unpaid invoices with a subtotal. It then reads their pending, on-hold and processing orders in WooCommerce with a subtotal. The report puts both side by side and notes any WooCommerce order that looks unpaid with no matching open NetSuite invoice, or the reverse. If the customer is not in NetSuite it reports the WooCommerce side only, and an empty side is stated outright. Nothing is changed or sent in either system.
Business outcome
---
Collections see what a customer owes in NetSuite beside their open WooCommerce orders, with mismatches called out.
No items found.
Ready to unlock your data?
Start building tools that turn your business systems into AI superpowers
Join forward-thinking companies that are transforming their operations with intelligent, secure AI automation.