Web Store
Shopify
Connect your AI to Shopify
Store owners, operations managers, and customer service teams run on Shopify data every day, but the answers they need span Orders, Customers, Fulfillments, and inventory across locations. AI can surface those answers instantly, but only if it governs what each role can see and what actions each role can take.
Why it matters
Capabilities that matter most for Shopify
01
Ready-made store lookups
Install Shopify lookups from the app store so AI tools can find a customer, order or product variant by email, order number or SKU.
02
Store beside ERP and support
Join Shopify orders with ERP, shipping or helpdesk lists to see an order's full story in one place.
03
Governed AI for commerce
AI tools answer within per-user and per-team security, redact customer details, and change orders only through approved actions.
Use cases
Example AI Use Cases for Shopify
scenario
-
New Shopify customers who tick the box to accept marketing should end up in Constant Contact, but the two do not stay in step on their own. Adding them by hand risks duplicating contacts or re-subscribing someone who already opted out.
What popdock provides
--
Give a start date and optionally a Constant Contact list, choosing from your lists if you leave it blank, and it reads up to 200 Shopify customers created since then who accept marketing. Anyone already in Constant Contact is dropped, whatever their status, so nobody who unsubscribed is re-subscribed. You see the customers and the target list, confirm, and say whether they opted in directly, with implicit as the default. Contacts are created once each and checked afterwards, failures are not retried, and it suggests a later start date if it hit the limit.
Business outcome
---
New shoppers who agreed to marketing join your email list, with no duplicates and no opt-outs reversed.
scenario
-
A Constant Contact campaign promotes a sale, and you want to know whether clickers actually bought in Shopify. Matching click dates to orders by email, skipping canceled orders and not double counting people who clicked twice, is fiddly spreadsheet work.
What popdock provides
--
Give the Constant Contact campaign id, and optionally a window, seven days by default, and it groups clicks by email with each person's first click date and links. For each clicker it finds the Shopify orders placed in the window after that click, leaving out voided and canceled orders and never counting an order twice. You get orders, revenue per currency and the share of clickers who bought, with a truncated result called out. If nobody ordered it reports zero rather than widening the window, labels the result as correlation, and only reads.
Business outcome
---
You see the orders that followed each campaign click, measured consistently and stated honestly.
scenario
-
Your highest-spending Shopify customers are the ones you most want reading your emails, yet some were never added to Constant Contact, some unsubscribed, and some stopped opening months ago. Without checking, you cannot see how much spend sits outside your email reach.
What popdock provides
--
Set a lifetime spend threshold, and optionally a look-back period, 90 days by default, and it reads up to 100 Shopify customers above it. Each email is looked up in Constant Contact and the customer is placed in not in Constant Contact, unsubscribed, subscribed but quiet, or engaged. You get a table per group with spend, order count and both marketing statuses, and the total spend in the first two groups. A failed lookup is reported as failed, never as missing, and nothing is changed.
Business outcome
---
You know how much of your top customers' spend your email program cannot reach, and which customers to act on.
scenario
-
When a shopper writes in, you want their Shopify orders and spend alongside their Constant Contact subscription and recent email activity. Checking both, and spotting that Shopify says they accept marketing while Constant Contact says they unsubscribed, takes several screens.
What popdock provides
--
Give an email address, and optionally a look-back period, 90 days by default, and it finds the shopper in Shopify with their order count, total spent, marketing consent and recent orders with payment and fulfillment status. The same email finds their Constant Contact contact, lists, tags, opens, clicks and bounces. Consent mismatches between the two, and name or phone differences, are called out. Email is the only join, several Shopify matches are listed for you to choose, a disconnected system is reported as such, and nothing is changed.
Business outcome
---
You understand a shopper's purchases and email relationship together, and spot consent conflicts before they become a complaint.
scenario
-
When someone unsubscribes in Constant Contact, Shopify does not find out, so the customer record can still say they accept marketing. Any campaign that relies on Shopify's consent flag then reaches someone who asked to stop. Finding these people means checking each unsubscribe against Shopify one at a time.
What popdock provides
--
Pick a look-back period, 30 days by default, and optionally one campaign, and it collects the unsubscribes in Constant Contact, removing duplicates. Each email is looked up in Shopify for marketing consent, order count and spend. You get the mismatches first, people who unsubscribed but are still marked as accepting marketing, plus counts of those that agree and those who are not customers, with blank consent listed as unknown. It tells you to turn consent off in Shopify admin and does not try to change it itself.
Business outcome
---
You find every customer whose opt-out has not reached Shopify, so consent can be corrected before the next send.
scenario
-
When a Shopify order is refunded, your email team rarely hears about it, so the same contact keeps getting promotions for the product they just sent back. Recording each refund on the Constant Contact contact means opening the refund, adding up its lines, finding the shopper's email and typing a note, one refund at a time.
What popdock provides
--
Give a start date and it collects every Shopify refund since then, works out the refunded amount and items from the refund lines, and fetches the customer email from Shopify when the refund lacks one. Each refund is matched to a Constant Contact contact by email, and refunds already mentioned in an existing note are skipped, so a rerun never doubles up. You see every planned note in a table and nothing is written until you confirm, and the report counts refunds with no email or no contact.
Business outcome
---
Every refund is on record against the right Constant Contact contact, so follow-up email reflects what the shopper actually kept.
scenario
-
Prices set in Dynamics 365 Business Central and prices shown in Shopify drift apart as products are added and repriced. Finding the mismatches means exporting variants, matching SKUs to item numbers, and comparing prices row by row, while variants with no SKU or no matching item slip through unnoticed.
What popdock provides
--
Optionally name one SKU or a tolerance, and it reads Shopify variants and finds each item in Dynamics 365 Business Central by SKU, falling back to the barcode. Every variant whose price differs by more than the tolerance is listed, largest difference first, along with variants missing from Business Central, a count of variants with no SKU, and matched items that are blocked. SKUs are matched exactly, with near matches in a different case flagged to fix. If you say the currencies differ, it shows figures without flagging. Neither the store nor Business Central is edited.
Business outcome
---
Price mismatches between the store and the ERP surface in one list, largest first, before customers find them.
scenario
-
Keying a Shopify order into Dynamics 365 Business Central means checking it was not entered already, finding the right customer, mapping every line to an item, and working out discounts. One wrong SKU or a second entry of the same order means shipping errors and a messy credit later.
What popdock provides
--
Give the Shopify order, and optionally a customer number, and it reads the order and stops if it is canceled or already in Dynamics 365 Business Central under the Shopify reference. It matches the customer by email, refuses blocked accounts, and maps every line to an unblocked item by SKU or barcode, refusing to build a partial order. You see the full plan with discounts and the Shopify total, and nothing is written until you confirm. The order is then created and read back against the Shopify total. Nothing changes in Shopify.
Business outcome
---
Web orders reach Business Central once, with every line mapped correctly and no duplicates to unwind.
scenario
-
Shopify marks an order paid the moment the gateway captures the money, but the matching invoice in Dynamics 365 Business Central can stay open for weeks until someone applies the payment. Those invoices then show up as overdue and trigger collection calls to customers who already paid.
What popdock provides
--
Give a date range, and it reads Shopify orders marked paid and finds each posted invoice in Dynamics 365 Business Central that still has a remaining amount. For each, it pulls the Shopify payment gateway, amount and date, the details finance needs to apply the payment. Invoices are sorted by due date with past-due ones marked, and it says whether the open amount matches the payment exactly. Paid orders with no invoice are listed too. It reads only; applying payments stays with you.
Business outcome
---
Finance applies web payments quickly and stops chasing customers who have already paid.
scenario
-
Shopify orders are supposed to flow into Dynamics 365 Business Central, but integrations miss some, and nobody notices until a customer asks why nothing shipped. Checking means searching for each order by its reference in open sales documents and posted invoices, often in two formats.
What popdock provides
--
Give a date range, and it reads Shopify orders, sets canceled ones aside, and looks each up in Dynamics 365 Business Central as an open sales document or posted invoice by the Shopify reference, with and without the hash sign. It learns which format matches and uses it first. Missing orders are listed oldest first with totals and status. If nothing matches at all it warns the reference may be stored elsewhere instead of calling everything missing, and it flags a possibly truncated range. It only looks; nothing is entered for you.
Business outcome
---
Orders that never reached Business Central are caught early, oldest first, before customers start asking.
scenario
-
Every refund issued in Shopify should have a matching credit memo in Dynamics 365 Business Central, or revenue and receivables are overstated. Matching them by hand is slow because one order can have several refunds, some refunds have no lines, and the amounts must include tax.
What popdock provides
--
Give a date range, and it reads Shopify refunds, totals each from its lines plus tax, and looks for posted credit memos in Dynamics 365 Business Central by order reference, ignoring canceled ones. Several refunds on one order are paired by amount, then date. You get refunds with no credit memo first, then amount differences, with one-cent rounding noted as such. If nothing matches at all, it warns the reference may live in another field instead of calling everything missing. Nothing is created.
Business outcome
---
Uncredited refunds are caught before month end, so revenue and receivables stay accurate.
scenario
-
When Shopify shows more stock than Dynamics 365 Business Central actually holds, you sell what you cannot ship. Comparing quantities by SKU across hundreds of variants, while allowing for service items, packs and products set to sell when out of stock, is too slow to do often.
What popdock provides
--
Optionally name a SKU and a threshold, and it compares each Shopify variant's quantity with the matching Dynamics 365 Business Central item, found by SKU or barcode. Variants where Shopify shows more than Business Central come first because they risk overselling, with quantities on sales and purchase orders alongside. Non-inventory items and missing items are listed, as are variants that sell when out of stock while Business Central has none. Possible pack size mismatches are pointed out. Stock levels are reported, never adjusted.
Business outcome
---
You spot oversell risks before orders come in, with the riskiest variants at the top of the list.
scenario
-
A customer's online buying lives in Shopify while their balance, credit limit and blocked status live in Dynamics 365 Business Central. Seeing whether a blocked or overdue customer is still ordering online means checking both systems and matching orders to invoices yourself.
What popdock provides
--
Give an email address and a lookback period, and it finds the customer in Shopify and Dynamics 365 Business Central by exact email, stopping if either side has several matches. You get a side by side view of spend, orders, balance, credit limit and blocked status, then recent Shopify orders matched to their Business Central invoices. It flags name differences, ordering while blocked, overdue balances, balances over the limit and orders never invoiced. Lifetime spend and current balance are shown side by side, never netted. Neither customer record is edited.
Business outcome
---
You see in one view whether an online customer is in good standing before shipping or extending credit.
scenario
-
When a customer asks about a Shopify order, the answer depends on both systems: was it shipped, what tracking number, did it reach Dynamics 365 Business Central, and was it invoiced and paid there. Answering means hopping between Shopify order screens and Business Central documents.
What popdock provides
--
Give the order name or number, and it reads the Shopify order, its lines, shipments with tracking links and payments, then finds the matching sales document and posted invoice in Dynamics 365 Business Central. You get a status block for each side, a line table comparing ordered, fulfillable, shipped, invoiced and outstanding quantities, and one sentence naming anything that disagrees, such as paid online but open in Business Central. Totals are compared only when currencies agree. It only reads both systems.
Business outcome
---
You answer any question about where an order is across store and ERP in a single read.
scenario
-
Prices and costs in Shopify drift away from the item records in Dynamics GP as one side is updated and the other is not. Finding the differences means comparing every variant's price and cost against the GP list price and current cost by hand.
What popdock provides
--
Optionally filter by product title or vendor and set a tolerance, and it reads Shopify variants with their price and unit cost. Each SKU is looked up as the Dynamics GP item number for current cost and list price, saying which price level it used. You get variants that differ beyond the tolerance, largest first, with the margin at the Shopify price, plus variants with no SKU and SKUs not found in GP. Missing prices are shown as missing, currency differences are flagged, and nothing is changed.
Business outcome
---
Store prices and costs stay in line with your ERP, so you do not sell online at the wrong margin.
scenario
-
Shopify orders that are fulfilled get tracking numbers in Shopify, but the matching sales document in Dynamics GP stays blank. Copying them across means finding the GP document by customer PO and keying each tracking number by hand.
What popdock provides
--
Give the Shopify order name, and it collects every distinct tracking number from the order's fulfillments. It finds the Dynamics GP sales document by customer PO number, preferring one that is not yet posted when there are several. You see the GP document and tracking numbers and confirm before anything is written. Each tracking number is added once, numbers over 40 characters are skipped rather than cut short, and any failures are reported. Shopify is not changed.
Business outcome
---
Tracking from Shopify appears on the GP sales document, so your team can answer shipping questions from one place.
scenario
-
Shopify B2B companies need to be tied to the right Dynamics GP customer so orders and credit can be checked. Doing it by hand means searching GP by name, creating the customer if it is missing, and pasting the ID into Shopify without overwriting an existing link.
What popdock provides
--
Name the Shopify B2B company, and optionally the GP customer ID, and it reads the company, its location and main contact, stopping if it is already linked unless you ask to replace it. It finds candidate Dynamics GP customers and shows them with city and balance. You confirm whether to link an existing customer or create one from the Shopify details before anything is written. The GP ID is then written to the Shopify company, both sides are read back, and if a step fails it says exactly what exists.
Business outcome
---
Each B2B company in Shopify is linked to one GP customer, ready for order posting and credit checks.
scenario
-
Refunds issued in Shopify should show up in Dynamics GP as credit memos or returns, but the two are rarely checked against each other. A missed refund overstates revenue and receivables, and finding it means matching order names across systems by hand.
What popdock provides
--
Set a lookback window, and it reads Shopify refunds and totals each one's lines and tax. It reads Dynamics GP credit memos and sales returns for the same period and matches them to refunds by order name in the customer PO field, summing when a refund is split across documents. You get refunds with no GP credit and the SKUs involved, amount mismatches, GP credits that matched no refund and a count of clean matches. It only reads.
Business outcome
---
Every Shopify refund is accounted for in Dynamics GP, so revenue and receivables stay accurate.
scenario
-
Rekeying a Shopify order into Dynamics GP means finding the right customer, checking every SKU exists as an item, applying discounts and freight, and making sure the order was not already entered. A duplicate or a missing line goes straight through to fulfilment and billing.
What popdock provides
--
Give the Shopify order name, batch and document type, and it reads the order, lines and shipping, stopping on a canceled order or one already in Dynamics GP. It finds the GP customer through the linked B2B company or by name and matching email, and confirms every SKU is a GP item, stopping rather than creating anything. You confirm the document with discounts folded into prices before the sales order and lines are created. The GP total is compared with Shopify, and a failed line is reported with the order number.
Business outcome
---
Shopify orders reach Dynamics GP once and complete, with totals checked against the store.
scenario
-
Every Shopify order should end up as a sales document in Dynamics GP, but checking means looking up each order's name in the customer PO field and comparing totals. Orders that never made it across go unbilled until a customer complains.
What popdock provides
--
Set a lookback window, and it reads Shopify orders, setting canceled ones aside. Each order is looked up in Dynamics GP by its name as the customer PO number, retrying without the hash and with the plain number, and preferring the invoice when there are several. You get orders missing from GP, total and tax mismatches, a count of clean matches and the canceled orders skipped. Differences under one cent count as a match, and nothing is changed.
Business outcome
---
No Shopify order goes unbilled, because missing and mismatched orders are found within days.
scenario
-
When Shopify shows stock that Dynamics GP does not have, you oversell, and when GP has stock Shopify hides, you lose sales. Comparing them means adding up Shopify locations and subtracting GP allocations for every SKU.
What popdock provides
--
Name a SKU, or check every tracked SKU, and set a tolerance. It totals Shopify available stock across locations, then reads Dynamics GP on hand and allocated for the same item number and works out GP available. You get SKUs that differ beyond the tolerance, largest first, SKUs missing from GP, and a count of Shopify rows with no SKU. SKUs that only matched in upper case are noted. It suggests adjustments but never makes them.
Business outcome
---
Online stock matches your warehouse, so you stop overselling or hiding items you actually have.
scenario
-
Shopify B2B buyers can keep placing orders while their Dynamics GP account is on hold, over its limit or overdue. Checking each company means finding its linked GP customer and reading balance, limit and open invoices one by one.
What popdock provides
--
Name a Shopify B2B company, or review them all, and it reads each company's linked Dynamics GP customer ID. For each it reads the GP balance, credit limit, hold and inactive flags and terms, and open invoices past their due date. You get available credit, overdue amount and Shopify spend per company, with flags for hold, inactive, over limit or overdue, plus companies that are unlinked or linked to a missing customer. A zero limit is treated as no limit, and nothing is changed.
Business outcome
---
Finance spots B2B buyers who are over limit or on hold before more online orders ship.
scenario
-
Prices and costs drift apart when someone updates Shopify but not Sage Intacct, or the other way round. Checking SKU by SKU means opening each variant, its inventory cost and the matching Intacct item, and a product quietly selling below cost can go unnoticed for months.
What popdock provides
--
Name a SKU or a product vendor, and it reads each Shopify variant's price and cost and the matching Sage Intacct item's base price and standard or average cost. Rows are flagged when price or cost differs beyond your tolerance, when the Shopify price is below either cost, or when a cost is missing, and flagged rows come first. Items with no Intacct base price are reported as priced by price list rather than as mismatches, and different currencies are not compared. It recommends fixes but changes nothing.
Business outcome
---
You catch pricing mismatches and negative margins before they cost you, with a SKU list ready to correct.
scenario
-
Shopify B2B companies are meant to point at their Sage Intacct customer through an external ID, but links go missing, point at deleted customers or drift as names change. Finding the broken ones means checking each company against Intacct by hand.
What popdock provides
--
Set how many companies to check, and optionally a name filter, and it reads your Shopify B2B companies and looks up each external ID in Sage Intacct. Companies are grouped as linked with a name difference, broken link, or unlinked with a single candidate, several candidates or no customer at all, worst first and sorted by spend. A candidate found by name is shown as a suggestion, never as a link. It only reads and points you to a separate step for fixing a company.
Business outcome
---
You know which B2B accounts are not tied to your ledger, starting with the most valuable, before orders and invoices go astray.
scenario
-
When a Shopify B2B company is not linked to its Sage Intacct customer, orders and invoices cannot be tied together. Fixing it means finding the right customer, creating one if none exists, and pasting the ID into the right Shopify field without overwriting a link someone else set.
What popdock provides
--
Name the company, and it finds it in Shopify and checks whether its existing link already resolves in Sage Intacct. If not, it looks for the customer by name, letting you choose when there are several, and only offers to create one when none exists, using the main contact and location details from Shopify. Each write, the new customer and the Shopify link, needs its own yes, and an old broken link is shown before it is replaced. If the customer cannot be created, Shopify is left untouched, and the link is read back at the end.
Business outcome
---
Each B2B company ends up tied to exactly one ledger customer, with nothing written you did not approve.
scenario
-
Money collected in Shopify reaches the bank days later, net of fees, so lining up daily takings with Sage Intacct deposits is guesswork in a spreadsheet. A payout that never arrived, or arrived short, can hide among normal fee gaps.
What popdock provides
--
Give a date range, and optionally a payment gateway, and it totals successful Shopify sales, captures and refunds by day, ignoring authorizations, voids and failures. It lines each day up with Sage Intacct deposits up to five days later within five percent, labels small gaps as likely fees and larger ones as mismatches, and lists days and payout-like deposits with no partner. The report says at the top that this is a date and amount match to check, not proof, and nothing is changed.
Business outcome
---
You get a short list of collection days that never reached the bank, so missing payouts are chased early.
scenario
-
Getting a Shopify order into Sage Intacct by hand means finding the right customer, matching each product to an item by SKU and checking nobody already posted it. Miss that last check and the same order is billed twice.
What popdock provides
--
Name the Shopify order, and it reads the order and its lines, then searches recent Sage Intacct invoices and documents for one carrying the same order number and stops if it finds it. The customer is found through the B2B company link, a contact email or the customer name, and you are asked rather than having one created. Every line must match exactly one Intacct item by SKU, orders over two lines are refused, and you are told that tax, shipping and discounts do not carry across. Nothing is posted until you confirm, and the new document is read back.
Business outcome
---
Shopify orders reach your ledger once, against the right customer and items, with no double billing.
scenario
-
Every Shopify order is supposed to end up in Sage Intacct, but integrations miss some and others arrive with a different total. Checking means matching order numbers against reference and PO fields across two exports, usually only after month end is already under way.
What popdock provides
--
Give a date range, and it reads non-canceled Shopify orders and the Sage Intacct invoices and order documents from the same period plus a week. Orders are matched on their order name or number against the Intacct reference or PO number, and each document matches only one order. You get the orders missing from Intacct, those with a different total, with a note when the gap looks like shipping or tax, and Intacct documents that look like orders but match nothing. It is read-only and says when the result is partial.
Business outcome
---
Missing and mismatched orders surface in minutes, so revenue in your ledger matches what the store sold.
scenario
-
When Shopify shows stock that Sage Intacct says is gone, or the reverse, you oversell or leave sellable items hidden. Comparing quantities item by item across systems and locations takes so long that it rarely happens.
What popdock provides
--
Name a SKU or check up to a set number of active stocked items, and it reads Sage Intacct on-hand quantities and sums Shopify available stock across locations for the exact same SKU. Rows where the two differ by your minimum are listed, largest gap first, along with SKUs found in only one system. Locations are paired only where names match exactly, never guessed, and duplicated SKUs in Shopify are flagged rather than summed. It explains that committed orders cause small expected gaps and changes nothing.
Business outcome
---
You see exactly which SKUs are out of step between store and ledger, before they cause oversells or missed sales.
scenario
-
A B2B buyer can keep ordering in Shopify while their unpaid invoices pile up in Sage Intacct, and nobody sees both numbers together. Working out real exposure means adding the ledger balance to orders not yet invoiced and comparing it with a credit limit kept somewhere else.
What popdock provides
--
Name the company, and it finds it in Shopify, follows its link to the Sage Intacct customer, or a single name match that it labels as such, and reads the balance, overdue invoices, terms and credit limit. It adds open Shopify orders not yet invoiced, leaving out any already billed, to show total exposure against the limit with the headroom or overage. Recent payments and any mismatch between Shopify and Intacct payment terms are called out. It recommends actions such as a hold but changes nothing.
Business outcome
---
You know a B2B buyer's true exposure before approving the next order, not after the invoice goes unpaid.
scenario
-
Shopify customers who agree to marketing at checkout do not always reach your Mailchimp audience. Fixing it by hand means comparing new customers with the audience one by one, and adding back someone who unsubscribed or was cleaned breaks their consent.
What popdock provides
--
Name the Mailchimp audience, and optionally a start date, and it reads recent Shopify customers who accept marketing and have an email. Each is checked against the audience, and anyone already a member in any status, or found in Mailchimp's unsubscribe history, is left alone and listed separately. You see the people to add and the status they will get, pending by default for double opt-in, and nothing is written until you confirm. Each added member is read back, and a run capped at 250 customers says so.
Business outcome
---
Customers who agreed to marketing reach your audience, while anyone who withdrew consent stays out.
scenario
-
Targeting your best Shopify customers in Mailchimp means finding everyone above a spend threshold, checking each is a subscribed member and adding them to a segment without doubling anyone up. A condition-based segment cannot take manual members at all, which often only shows up after the work is done.
What popdock provides
--
Give a minimum lifetime spend, the audience and a static segment, and it confirms the segment is static before doing anything else. It reads Shopify customers above the spend and keeps only those subscribed in the audience and not already in the segment, counting each skip reason. After you confirm the list, it adds the members and reads the segment again to show the new member count beside the old one. Nobody is added to the audience itself, and Shopify is not changed.
Business outcome
---
Your top spenders are ready to target in one segment, built from subscribed contacts only.
scenario
-
Mailchimp credits revenue to a campaign when an order is placed, and that figure rarely reflects cancellations or refunds made later in Shopify. Checking means finding each attributed order in Shopify by customer and amount, which is slow because the two systems share no order number.
What popdock provides
--
Name the campaign or automation and it reads the orders Mailchimp attributes to it, asking you to choose if several names match. Each order is found in Shopify by customer email, total and date, and ambiguous matches are noted. It checks cancellations and refunds, then totals attributed, confirmed, canceled, refunded and not found revenue per currency, with one sentence on how far the Mailchimp figure overstates kept revenue. If many orders are missing, it warns that Mailchimp may be connected to a different store. Neither Mailchimp nor Shopify is changed.
Business outcome
---
You report campaign revenue that survives refunds and cancellations, not the optimistic number Mailchimp shows.
scenario
-
A campaign can send hundreds of shoppers to a product that is about to run out. Checking means pulling the campaign's clicked links, working out which product each one points to, and opening every variant in Shopify to read its stock and whether it can still be ordered at zero.
What popdock provides
--
Name the Mailchimp campaign, and optionally a low stock threshold, and it reads the product page links and their clicks, merging links that point to the same product. Each product is found in Shopify, and every variant's quantity, SKU and stock policy is read. Variants are marked out of stock, low or ok, with a note where the policy allows overselling or turns buyers away. Collection and other links are counted but not looked up, and nothing is changed in either system.
Business outcome
---
You catch stock problems on promoted products before shoppers hit a sold out page or you oversell.
scenario
-
Mailchimp tracks abandoned carts, but it cannot tell you which shoppers came back and bought in Shopify later. Without that, you chase people who already ordered and cannot say whether your cart recovery emails work. Matching carts to orders by hand, one email at a time, is too slow to do every week.
What popdock provides
--
Set a start date, and optionally a minimum cart value, and it reads Mailchimp abandoned carts and looks for a later, uncancelled Shopify order from the same email. Carts are classed as recovered, not recovered, or unknown when there is no email, with counts, value per currency and the recovery rate. Unrecovered carts are sorted by value as the ones worth chasing, and recovered carts that ordered much less are noted. It sends nothing to shoppers and changes nothing.
Business outcome
---
You know your real recovery rate and which open carts are still worth following up.
scenario
-
When a customer writes in, their buying history lives in Shopify and their email history lives in Mailchimp. Piecing together orders, open shipments, subscriptions and recent unsubscribes takes several screens, and nobody notices when the two systems disagree on marketing consent.
What popdock provides
--
Give an email address and it reads the Shopify customer with recent orders, total spent and the shipment status of anything not yet fulfilled. From Mailchimp it reads each audience status, recent opens and clicks, unsubscribes with reasons, and any open cart with its checkout link. A consent check flags a mismatch, such as accepting marketing in Shopify while unsubscribed in Mailchimp. It matches on email only and changes nothing.
Business outcome
---
You answer a customer with the whole story in front of you, and consent conflicts surface before they become complaints.
scenario
-
Shopify's accepts marketing flag and a customer's Mailchimp status should agree, but they drift as people check out, unsubscribe and get cleaned. Spotting the gaps means comparing each customer's flag with their audience status by hand, and emailing someone without consent is a compliance problem.
What popdock provides
--
Name the audience, and optionally a start date, and it reads up to 250 Shopify customers and looks each one up in the audience by email. Every customer is classed as agree, missing from the audience, consent withdrawn in Mailchimp, subscribed without Shopify consent, or pending. Each mismatch class gets its own table sorted by spend, and duplicate members for one email are reported as a data problem rather than settled by picking one. It is read-only, so you decide how to fix each gap.
Business outcome
---
Every consent mismatch between store and email shows up in one report, before it turns into a complaint.
scenario
-
An unsubscribe count says little until you know who left. Working out which unsubscribes are valuable Shopify buyers, why they left and which campaign pushed them away means matching each email to a customer and reading their spend.
What popdock provides
--
Set a start date, and optionally a minimum spend, and it reads Mailchimp unsubscribes and looks each person up in Shopify by email. Paying customers are ranked by total spent with the campaign they left and their reason, reasons are grouped and counted, and campaigns are ranked by how many paying customers they lost. Customers whose Shopify marketing consent is still on are listed for you to fix in Shopify admin. It never resubscribes anyone and changes nothing.
Business outcome
---
You learn which campaigns cost you valuable buyers and why, and where store consent needs tidying.
scenario
-
Every Shopify payment needs to land against the right Rillet invoice, but matching captures to invoices by order number and posting them one by one is slow. Post one twice, against a paid invoice or for more than is owed, and receivables stop making sense.
What popdock provides
--
Pick a date range, yesterday by default, and a clearing account, and it reads successful Shopify sales and captures and finds the Rillet invoice for each order, trying the order number with and without the hash. Payments are sorted into ready, no invoice, already paid, over amount and currency mismatch, and only the ready group is posted. It confirms the account is active, skips payments that look already recorded, and stops posting once an invoice is fully paid. Nothing is posted until you confirm, and Shopify is never changed.
Business outcome
---
Shopify cash is applied to the right invoices, with no double postings or overpayments to unwind.
scenario
-
When Shopify orders do not reach Rillet, receivables are understated and someone has to create invoices by hand. That means checking each order against existing invoices, finding the right customer by email and splitting tax from the total, and a second pass easily creates duplicates.
What popdock provides
--
Choose a date range and a Rillet product, and it reads Shopify orders, skipping canceled and voided ones, and keeps only those with no Rillet invoice under the order name. Each order's customer is matched by email, or a fallback customer you name, and orders with no customer are listed but not created. You see each invoice with net, tax and total before anything is written. After you confirm, each is created once as a receivable-only invoice keyed to the Shopify order, and invoices are re-read first so a second run does not duplicate.
Business outcome
---
Missing Shopify sales reach your Rillet receivables, each tied to its order, with no duplicate invoices.
scenario
-
Each Shopify refund should become a Rillet credit memo applied to the order's invoice, but finding the refunded amount, the invoice and whether a memo already exists takes several lookups per refund. Book one twice and your receivables are understated.
What popdock provides
--
Choose a date range, the last 7 days by default, and a Rillet product, and it reads Shopify refunds with their successful refund transactions and refunded lines. Each refund is matched to the order's Rillet invoice, and any refund that already has a memo is skipped. Refunds whose money has not gone back yet are listed as pending and not booked. After you confirm, one memo per refund is created and applied to the invoice, capped at the invoice total, and if applying fails the memo is reported as unapplied rather than created again.
Business outcome
---
Shopify refunds reach your Rillet books once each, applied to the right invoice, with nothing double booked.
scenario
-
B2B buyers in Shopify and customers in Rillet drift apart: names are spelled differently, legal suffixes come and go and contact emails change. Working out which company is which, and which exist in only one system, takes a long side by side comparison.
What popdock provides
--
Optionally name one company, and it reads Shopify B2B companies with their contacts and every Rillet customer with their emails. Matching runs in order, external id, exact name, name without legal suffixes, then contact email, and stops at the first rule that fits, listing ambiguous companies with every candidate. You get matched, probable, Shopify only and Rillet only lists, plus email disagreements, with probable matches marked for a person to confirm. It recommends setting the Shopify external id so future runs match exactly, and changes nothing.
Business outcome
---
You know which B2B accounts line up between store and ledger, and which need a person to confirm or fix.
scenario
-
The inventory balance in Rillet should roughly match what is on the shelves in Shopify, but valuing stock means multiplying every tracked item by its cost across locations. Items with no cost and oversold stock distort the total, and differences go unexplained at month end.
What popdock provides
--
Give the balance sheet line and an as-of date, and it values Shopify's tracked on-hand inventory at cost by location and in total. Items with no cost are counted and listed, and oversold items are kept out of the total. It reads the matching Rillet balance sheet line and shows the difference as an amount and a percentage. It states plainly that Shopify gives only today's stock at current cost, keeps different currencies apart, and describes any adjustment without posting it.
Business outcome
---
You see how far stock on hand is from the ledger, with the items behind the gap already listed.
scenario
-
Month end means proving every Shopify order made it into Rillet at the right amount. Matching orders to invoices by number, comparing totals and tax, and catching orders canceled in Shopify but still open in Rillet is tedious work across two exports.
What popdock provides
--
Pick a date range, last month by default, and it reads Shopify orders and the Rillet invoices dated within a week either side. Orders match invoices only by order name, with or without the hash, never on amount or date alone, and totals and tax are compared to within a cent. You get four tables: missing from Rillet, amount mismatches, canceled in Shopify but still open in Rillet, and Rillet invoices with no Shopify order. Mismatched currencies are shown without conversion, and nothing is changed.
Business outcome
---
Month end gets a clear list of Shopify orders to fix in Rillet, instead of a total that does not tie.
scenario
-
The sales tax Shopify collected should match what was posted to your tax liability account in Rillet, but refunds, timing and filings muddy the comparison. Working it out by hand before a filing means adding up order tax, subtracting refunded tax and netting journal lines.
What popdock provides
--
Pick a period and the Rillet tax account, and it confirms the account exists, totals tax on uncancelled Shopify orders, subtracts tax on refunds, and nets the credits and debits posted to that account. For periods of 50 orders or fewer it also breaks the tax down by jurisdiction, and says why when it skips this. Where there is a difference, it lists likely causes, such as refunds booked in another period or orders not yet invoiced in Rillet. Every currency is shown separately, and nothing is posted.
Business outcome
---
You go into a tax filing knowing whether store and ledger agree, and why they differ if not.
scenario
-
For a B2B customer, what they order lives in Shopify and what they owe lives in Rillet. Preparing for a call means checking both, and the gaps are where trouble starts: an outstanding order with no invoice, an invoice overdue on an order Shopify shows as paid, or payment terms that differ.
What popdock provides
--
Name the company and it finds it in Shopify with its locations, payment terms, contacts and recent orders, then finds the matching Rillet customer by external id, name or contact email. From Rillet it reads open and overdue invoices, credit memos, contracts and current ARR. Outstanding orders are compared with Rillet invoices by order name, flagging missing invoices, balances that differ, invoices overdue on orders Shopify shows as paid, and payment terms that disagree. It suggests an obvious next action where there is one, keeps currencies apart and changes nothing.
Business outcome
---
You see a B2B customer's buying and balance together, with every disagreement between store and ledger flagged.
scenario
-
When a customer emails a new address, you have to check the Shopify order has not shipped or gone to a fulfillment service before you touch it, then retype every address field correctly. Change it too late and the parcel still goes to the old address while the order says otherwise.
What popdock provides
--
Give the order number and the new address, and it finds the order in Shopify and stops if it is canceled, already fulfilled, or already submitted to or accepted by a fulfillment service. The address is split into its parts, and it asks for anything missing, such as a country code, zip or US or Canadian province, rather than guessing. You see the new address field by field and nothing changes until you confirm. Only the shipping address is updated, the customer's saved address book is left alone, and a failed update is reported as returned, not retried.
Business outcome
---
Address corrections land only on orders that can still be redirected, so parcels stop going to the wrong place.
scenario
-
Before a call with a wholesale customer you need its locations, payment terms, catalogs, contacts and recent orders, and in Shopify those sit on separate screens. Orders are not even filed under the company, so you end up searching contact by contact to see what is outstanding.
What popdock provides
--
Name the B2B company and a lookback period, and it reads the company's locations with their payment terms, tax status and catalogs, its contacts and the roles each holds by location, and any critical alerts. Recent orders are traced through each contact, with unpaid and unfulfilled orders called out. The review ends with gaps worth fixing, such as locations with no catalog or contacts with no role. It is read-only, reports amounts in the currency Shopify returns, and says when a section is empty rather than leaving it out.
Business outcome
---
You walk into every account conversation with the full company picture, including the gaps and open orders to raise.
scenario
-
Answering a question about a Shopify customer often means opening their orders, refunds, transactions, addresses, saved cards and store credit one at a time. Something important, like a failed payment or an expiring card, is easy to miss when it sits three screens away.
What popdock provides
--
Give a customer email and a lookback period, and it builds a one-page review from Shopify: lifetime spend and orders, recent orders with any unpaid, outstanding or unfulfilled ones, refunds and the refund rate, failed transactions, the default address, payment methods with expiring or revoked cards flagged, store credit and critical alerts. If several customers match the email it lists them and stops. It is read-only, never prints full card numbers, and names any section that came back incomplete.
Business outcome
---
You understand a customer's whole account in one read and spot payment or fulfillment problems before they turn into complaints.
scenario
-
Failed payments in Shopify are scattered across individual orders, and the real question is which of them never recovered. Checking each order for a later successful charge takes time, and the worst case, an order that shipped without being paid, can slip through unnoticed.
What popdock provides
--
Name a lookback period, and optionally a gateway, and it collects every failed and errored payment transaction in Shopify. Each order is checked for a later successful charge or a paid status and sorted into recovered, unrecovered, or unrecovered but already fulfilled, which comes first. You get totals, patterns by gateway, error code and card company, and an action list of unpaid orders. It is read-only and only calls something a pattern when one gateway or error accounts for most failures on the same day.
Business outcome
---
You chase the unpaid orders that matter, starting with goods that shipped without payment, instead of reading every failed charge.
scenario
-
Late Shopify orders are stuck for different reasons: some are on hold, some are waiting on a fulfillment service, some are short of stock. Working out which is which means opening each fulfillment order and checking holds, requests and inventory by hand.
What popdock provides
--
Set an age threshold, and optionally a location, and it pulls every open, in progress, on hold or incomplete fulfillment order older than that in Shopify. For each it finds the blocker: the hold reason, the request sent to a fulfillment service and its answer, or stock at the assigned location for up to 20 items, and anything past its fulfill-by date is marked overdue. The report groups orders by location, oldest first, with totals and the three changes that would clear the most orders. It is read-only and only says out of stock when the inventory read shows it.
Business outcome
---
Your warehouse team knows exactly why each order is late and which fixes clear the backlog fastest.
scenario
-
Deciding what to reorder in Shopify means checking available stock per location, then looking up what is already on its way and what open orders still need. Doing that item by item across locations is slow, and short items are easy to miss.
What popdock provides
--
Set a stock threshold, and optionally a location, and it finds the tracked items at or below it in Shopify, with product and variant names. For each it adds incoming stock with the expected date and open demand from unfulfilled order lines, capped at the 25 lowest items. Rows where demand exceeds available plus incoming are marked short, with the cost to cover the shortfall. It is read-only, skips untracked items, and does not invent reorder quantities because there is no sales velocity data to support them.
Business outcome
---
Buyers see the true shortfall per location, with stock on order already counted, before customers feel it.
scenario
-
Understanding refunds in Shopify means going through each refund for the products, the tax, the shipping adjustments and whether stock went back on the shelf. Patterns, like one product refunded again and again or one customer refunding often, only show up when someone adds it all together.
What popdock provides
--
Name a lookback period, and it reads every Shopify refund in it with its lines, adjustments and the original order total. You get totals with full versus partial refunds, the top ten refunded products with how much was restocked, adjustments by kind and reason, repeat refunders, and themes from refund notes. It is read-only, words repeat refunders as a pattern to look at rather than an accusation, and keeps adjustment-only refunds in the count instead of dropping them.
Business outcome
---
Finance and merchandising see what refunds are costing and which products drive them, without building the numbers by hand.
scenario
-
Making a variant stockable at a new Shopify location means finding the right variant by SKU, finding the location, checking it is not already there, and converting both to the ids Shopify expects. Pick the wrong variant or location and stock gets received against the wrong place.
What popdock provides
--
Give a SKU and a location name, and it resolves both in Shopify, stopping to list candidates if either is ambiguous and refusing an inactive location. If the item is already stocked there it reports the level and does nothing. Otherwise you see the product, variant, target location and where it is stocked today, with a warning if tracking is off, and nothing is written until you confirm. The connection is made once, then read back so you see the new level.
Business outcome
---
New locations are set up for the right variant first time, with no duplicate or misplaced inventory records.
scenario
-
Shopify flags risky orders, but someone still has to check which of them are unfulfilled, whether payment was captured, and whether the buyer is new. Miss one and a high-risk order ships before anyone looks at it.
What popdock provides
--
Name a lookback period and a minimum risk level, and it gathers orders Shopify rated at that level or recommended to cancel or investigate. Each is checked: canceled orders are counted, already fulfilled ones are listed as exposure, and unfulfilled ones form the action list, with payment status and the customer's order history added. The table ranks cancel recommendations first, then risk level, then value. It is read-only, quotes the risk provider's reason as given, and words each one as a review, never as proof of fraud.
Business outcome
---
Risky orders get a human decision before they ship, ranked so the most exposed ones are seen first.
scenario
-
A where-is-my-order email means checking payment, shipments, tracking scans, what has not shipped yet and whether anything is on hold, all in different places in Shopify. Then you still have to write a reply that is accurate without exposing internal details.
What popdock provides
--
Give an order number or a customer email, and it finds the order in Shopify, asking you to confirm rather than guessing at a similar one. It reads each shipment with carrier, tracking and the latest scan, then the items still to ship with location, fulfill-by date and any hold. You get a staff summary, with shipments flagged as possibly stalled after seven days without a scan, and a short customer reply that leaves out hold reasons and app names. It is read-only and never promises a delivery date the carrier has not given.
Business outcome
---
Customers get an accurate answer about their order in minutes, and your team never over-promises a delivery date.
scenario
-
Answering a where-is-my-order ticket in Zendesk means finding the order number in the thread, looking it up in Shopify, reading fulfillment and tracking, then writing back. Rushing it risks quoting someone else's order or an internal hold reason to the customer.
What popdock provides
--
Name the Zendesk ticket, and optionally the order, and it reads the ticket and its comments for an order number, then finds the order in Shopify. It stops if the order email does not match the requester, so another customer's order is never disclosed. It reads shipments, tracking events and any hold, then drafts a reply by first name with the carrier, tracking link and expected delivery where Shopify has one. You see the draft and its facts, and it is posted as a public comment only after you confirm, exactly as you edit it. Ticket status is left for the agent.
Business outcome
---
Order status tickets are answered accurately from live Shopify data, without disclosing the wrong customer's order.
scenario
-
When a customer opens a Zendesk ticket asking where their refund is, you have to find the order in Shopify, see what was refunded, and check whether the money actually went back. A refund recorded in Shopify is not the same as a refund that reached the card.
What popdock provides
--
Name the Zendesk ticket, and optionally the order, and it reads what the customer says they are owed, then finds the Shopify order, stopping if its email does not match the requester. It lists each refund with items, tax and adjustments, and each refund transaction with its status and gateway, saying plainly when one is pending or failed. You see any gap between what was asked for and what was refunded, plus a suggested reply for the agent. Nothing is posted or refunded; both systems are only read.
Business outcome
---
Agents answer refund questions with facts about where the money is, and only for the customer who owns the order.
scenario
-
A customer writes into Zendesk with a new delivery address, and you have to copy it into the right Shopify order before it ships, then note what you did. Done carelessly, an address gets changed on an order the requester does not own, or on a parcel that has already left.
What popdock provides
--
Name the Zendesk ticket, and it takes the new address from the requester's own latest comment, asking you to choose if an agent wrote it or two addresses conflict. The Shopify order must belong to the requester's email and must not be canceled, shipped or sent to a fulfillment service, or it stops. Missing parts such as a zip or province are flagged for you to request. After you confirm the address field by field, it updates only the shipping address, then adds a private note to the ticket; if the update fails, no note is posted.
Business outcome
---
Address change requests are applied safely to the right unshipped order, with an internal record left on the ticket.
scenario
-
High-risk Shopify orders need a review before they ship, but nobody sees them unless someone checks the risk flags and opens a ticket by hand. Opening that ticket with the customer as requester can even email them about a fraud check.
What popdock provides
--
Set a lookback period, and optionally a Zendesk group, and it finds Shopify orders rated high risk that are not canceled or fulfilled. Orders that already have an unsolved Zendesk ticket are skipped and listed with that ticket. You see each order with its total, customer email and risk reasons, and nothing is created until you confirm. Each confirmed order gets one internal, high-priority task ticket with no requester, so the customer is never emailed, and the Shopify order itself is not changed.
Business outcome
---
Risky orders reach your review team as tickets before they ship, without duplicates or alerting the customer.
scenario
-
A Zendesk queue treats every requester the same, so a customer who has spent thousands can wait behind routine questions at normal priority. Checking each requester's spend in Shopify by hand is not realistic for a whole queue.
What popdock provides
--
Set a spend threshold, and it reads the new and open tickets in Zendesk and looks each requester up once in Shopify, including B2B company contacts, whose company spend is used. Tickets are ranked by customer value, then age, and those from high-value customers sitting at low or normal priority are flagged with a suggested priority. Requesters who are not Shopify customers stay in the list at zero. It is read-only, leaves priorities for you to change, and will not rank across currencies without saying so.
Business outcome
---
Your most valuable customers stop waiting behind routine tickets, and you decide which priorities to raise.
scenario
-
A bad satisfaction rating in Zendesk rarely says what went wrong, and the answer is often in Shopify: a late parcel, a refund dispute, a failed payment. Matching each rating to the customer's orders by hand takes too long, so the pattern and the revenue at risk go unseen.
What popdock provides
--
Name a lookback period, and it reads the bad Zendesk ratings in it, identifies each requester, and pulls their Shopify spend and the orders placed around the rating, checking fulfillments and refunds where needed. Each rating gets one likely cause, such as late delivery, wrong item, refund dispute or not order-related. The report ranks causes, shows each customer's lifetime spend, and names the five highest-spend unhappy customers with the follow-up each needs. Nothing is written in either system.
Business outcome
---
You see which order problems drive bad ratings and which unhappy customers are worth calling first.
scenario
-
To answer a Zendesk ticket well you need to know who the customer is in Shopify and what they have ordered, which means leaving the ticket and searching by email or order number. Order numbers mentioned in the thread sometimes belong to someone else entirely.
What popdock provides
--
Name the Zendesk ticket, and it reads the ticket and its comments for order numbers, then looks up the requester in Shopify by email. You get the customer's history, spend and tags, and a table of recent orders with payment, fulfillment and tracking, with orders the ticket mentions listed first. An order that belongs to a different email is flagged so its details are not shared. If several customers share the email they are listed, not merged. It is read-only.
Business outcome
---
Agents answer with full customer context without switching systems, and never share an order with the wrong person.
scenario
-
When B2B customers in Shopify have no matching organization in Zendesk, their tickets arrive unlinked and agents lose the company context. Setting them up by hand means checking for existing organizations, avoiding duplicates by name, and adding each contact who already has a Zendesk user.
What popdock provides
--
Optionally name a company, and it reads your Shopify B2B companies and their contacts, then matches each to a Zendesk organization by Shopify company id first and by name second. Name-only matches are reported for a person to check and never linked automatically. You see the organizations to create and the memberships to add, and nothing is created until you confirm. New organizations carry the Shopify company id as their external id, contacts without a Zendesk user are listed but not created, and a failed create skips its memberships.
Business outcome
---
Every Shopify B2B company gets a linked Zendesk organization, with no duplicate organizations or guessed matches.
scenario
-
New Shopify customers who opt in to marketing should land in Drip, but sync gaps happen and nobody notices. Catching them means exporting recent customers, checking each email against Drip, and adding the missing ones with the right tag. Get it wrong and you either miss buyers who wanted email or re-add someone who unsubscribed.
What popdock provides
--
Give a start date and a tag, and it reads Shopify customers created since then, keeping only those with an email who accept marketing. Each is looked up in Drip, with a lowercase retry, and anyone Drip already has is left alone whatever their status, so nobody who unsubscribed is re-added. You see the list and nothing is added until you confirm. After adding, it reads each new Drip subscriber back to check the tag landed, and warns you if the Shopify list may have been cut short.
Business outcome
---
Consenting Shopify customers reach Drip with the right tag, and nobody who opted out is ever subscribed again.
scenario
-
You want to know whether the people in a Drip email series went on to buy, but Drip and Shopify do not share that view. Answering it means exporting the campaign subscribers and searching Shopify orders for each email, while leaving out voided and cancelled orders. Most teams settle for a guess.
What popdock provides
--
Name the Drip campaign and a start date, and it finds the campaign, stopping to ask if the name fits more than one, then reads up to 100 subscribers and checks each email for Shopify orders since that date, retrying in lowercase before counting a non-buyer. Voided and cancelled orders are ignored. Nothing is changed. You get the subscribers checked, how many ordered, the conversion rate, revenue by currency and a table of buyers, with a clear note that an order shows overlap, not proof the campaign caused it.
Business outcome
---
You see how many Drip campaign subscribers bought in Shopify and what they spent, stated honestly as overlap rather than attribution.
scenario
-
A customer asks why they are still getting emails, or you want to know how a buyer is being marketed to, and the answer is split between Shopify and Drip. Pulling it together means opening the Shopify customer and orders, then the Drip subscriber and their campaigns, and spotting a consent conflict by eye.
What popdock provides
--
Give an email address and how far back to look, and it reads the Shopify customer with orders, spend and marketing consent, then the Drip subscriber with status, tags, lead score, lifetime value and email campaigns, retrying in lowercase before calling someone absent. Nothing is changed in either system. The report shows each side, then lists only real mismatches: Drip emailing someone without Shopify consent, an opt-out in Drip only, spend that differs by more than 10 percent, or a different name.
Business outcome
---
You answer consent and spend questions about any customer from one view, with genuine Shopify and Drip conflicts called out.
scenario
-
Adding one Shopify customer to a Drip email series sounds simple, but you should check they accepted marketing in Shopify, have not unsubscribed in Drip and are not already enrolled. Skipping any of those risks emailing someone without consent or sending them the same series twice.
What popdock provides
--
Give a customer email and the Drip campaign, and it first checks marketing consent in Shopify and the subscriber status in Drip, stopping if the customer has not consented or has opted out. It finds the campaign, asking you to pick if the name matches several, and stops if the person is already enrolled. You see the customer, their consent and the campaign status, with a warning if the campaign is not active, and nothing is added until you confirm. Afterwards it reads the enrollment back from Drip.
Business outcome
---
Shopify customers join Drip email series only with consent, once, and with the enrollment confirmed afterwards.
scenario
-
A customer who has just been refunded in Shopify may still be getting cheerful promotional email from Drip, which can make a bad experience worse. Spotting them means pulling recent refunds and checking each customer's Drip campaigns by hand, which nobody has time to do every week.
What popdock provides
--
This job only reports, so no campaign or subscriber is changed and removal stays your decision. Give a start date, and it reads Shopify refunds since then, groups them by customer email and counts refunds with no email. Each customer is checked in Drip for active campaigns where they are still an active subscriber. You get a table of refunded customers still receiving email, with the refunded order, date, note and campaign names, plus a count of refunded customers with no active campaigns and a separate line for those not in Drip.
Business outcome
---
You can review and pause promotional email to recently refunded Shopify customers before it adds to their frustration.
scenario
-
Shopify records whether a customer accepts marketing, and Drip records whether they are subscribed, and the two can quietly disagree. That leaves you emailing people who never consented, or missing people who did. Auditing it by hand means checking every recent customer in both systems and sorting them yourself.
What popdock provides
--
Nothing is fixed or changed: this is a read-only consent audit. Give a start date and a limit, and it reads recent Shopify customers with an email and looks each one up in Drip, retrying in lowercase before calling anyone missing. Every customer lands in one bucket: missing from Drip despite consent, marketed in Drip without Shopify consent, opted out in Drip only, or in agreement. You get a count per bucket, a table for each problem bucket with tags and status, and a suggested next step for each.
Business outcome
---
Consent conflicts between Shopify and Drip surface before they become a compliance problem or a missed buyer.
scenario
-
Open draft orders in Shopify are quotes or carts a customer has not paid for yet, and they go cold without a nudge. Getting those people into a Drip follow-up means listing the open drafts, matching each email to a subscriber, and tagging them, without accidentally adding people who never signed up.
What popdock provides
--
Give a start date and a tag, and it reads open Shopify draft orders that have not been converted, grouped by customer email with each draft name and value. Each email is looked up in Drip, and only active subscribers without the tag are kept. You see who will be tagged and how many were skipped as absent, unsubscribed or already tagged, and nothing is tagged until you confirm. No new Drip subscriber is ever created, and if the open filter finds nothing it says so when it falls back.
Business outcome
---
Customers with unconverted Shopify draft orders get a Drip tag for follow-up, limited to people already subscribed.
scenario
-
Your best Shopify customers deserve different email from first-time buyers, but Drip does not know who spent the most. Tagging them means filtering Shopify by lifetime spend, matching each email in Drip, and adding the tag one at a time, while taking care not to subscribe anyone who is not already on your list.
What popdock provides
--
Give a minimum lifetime spend and a tag, and it reads Shopify customers at or above that spend, matches each email to an active Drip subscriber, and skips anyone already tagged, unsubscribed or not in Drip. You see the list with spend, order count and current tags, and nothing is tagged until you confirm. It never creates a Drip subscriber, then re-reads a sample of tagged people to check the tag is there. The report states which currency the spend threshold assumes.
Business outcome
---
Your highest-spending Shopify customers carry a Drip tag such as vip, ready for dedicated email, applied only to existing subscribers.
scenario
-
Warehouse and web teams each record shipments, and a Shopify order marked shipped with no item fulfillment in NetSuite leaves inventory and revenue wrong until someone notices. Spotting them means matching orders to fulfillments by customer and date across two systems.
What popdock provides
--
Give a date range and how many orders to check, and it reads fulfilled Shopify orders and their tracking details, then finds the customer in NetSuite and looks for an item fulfillment on or after the order date. Results are grouped into fulfillment found, no fulfillment in NetSuite and customer not in NetSuite, with counts. When several fulfillments exist they are listed, and ambiguous or unmatched rows are marked rather than guessed. It is read-only on both systems and says when a result may be truncated.
Business outcome
---
Shipped orders missing a NetSuite fulfillment are found while they can still be corrected, so inventory and revenue stay right.
scenario
-
Stock is counted in NetSuite and sold in Shopify, and teams compare the two by pasting reports side by side. Differences, such as overselling or stock the store cannot see, go unnoticed until a customer orders something that is not there.
What popdock provides
--
Give a SKU, or leave it blank for up to 50 stock rows, and optionally a NetSuite location, and it reads Shopify inventory by SKU with location names, then the NetSuite quantity available and on hand for the same item numbers. It totals per SKU and compares, listing SKUs as matching, different, in Shopify only or in NetSuite only, with the largest differences first and counts per group. Ambiguous and unmatched records are marked, not guessed, and values that disagree are shown side by side. It is read-only on both systems and says when a result may be truncated.
Business outcome
---
Stock differences between the store and the ledger are listed largest first, so overselling and hidden stock are caught, with nothing changed.
scenario
-
Finance exports Shopify customers to a spreadsheet and compares their emails with NetSuite by eye. Web buyers with no NetSuite record are then never billed or reported properly, and the gap is hard to size.
What popdock provides
--
Give a start date and how many customers to check, and it reads Shopify customers created since then with their order count and total spent. It looks each email up in NetSuite, ignoring case, and groups customers as matched, matched with a different name, or not in NetSuite. Customers with no email are listed separately as unmatchable, and ambiguous matches are flagged rather than chosen. It ends with counts and the total spend of customers missing from NetSuite, using only rows it retrieved, and warns if the result may be truncated. Nothing is created or changed in either system.
Business outcome
---
Web buyers missing from NetSuite are identified with their spend, so finance can close the gap with real figures.
scenario
-
Orders taken on the web are meant to reach NetSuite, but nobody checks that they did. Missing or mismatched orders then show up at month end as revenue gaps that have to be traced back by hand.
What popdock provides
--
Give a date range, or use the last seven days, and it reads Shopify orders with their totals, payment status and cancellations. For each order it looks in NetSuite sales orders and then cash sales by order number, and if the number is not used in your account it says so and matches on customer email, date and total instead. Orders are grouped as found with the same total, found with a different total, or not found, with cancelled orders listed apart. Ambiguous matches are flagged, nothing is changed in either system, and it warns if the result may be truncated.
Business outcome
---
Web orders that never reached NetSuite, or arrived with a different total, are found within days instead of at month end.
scenario
-
Shopify payment receipts are reconciled to NetSuite by hand each month. Each sale means finding the customer in the ERP, finding their payment and comparing amounts, so unmatched or mismatched payments take days to track down.
What popdock provides
--
Give a date range, with a default of the last 7 days, and a record limit, and PopdockAI reads successful Shopify sale transactions and the customer email for each. It finds the NetSuite customer and looks for a customer payment dated within 3 days of the range, falling back to cash sales, and matches the amount within one cent. Payments are grouped as matched, amount differs and no NetSuite payment, with the unmatched total. It reports only rows it actually retrieved, marks ambiguous matches instead of choosing, flags truncated results and never changes either system.
Business outcome
---
Finance gets the Shopify payments with no or wrong NetSuite match, with the unmatched total, without a manual monthly tie out.
scenario
-
Refunds issued in a Shopify store are not always booked in NetSuite, so the books and the payment gateway drift apart. Checking each refund against credit memos and customer refunds by hand means finding the customer first, and missed refunds overstate revenue.
What popdock provides
--
Give a date range, with a default of the last 30 days, and a record limit, and PopdockAI reads the Shopify refunds with their order, customer email, amount and processing date. For each customer it finds the NetSuite record by email and looks for a credit memo or customer refund dated within 3 days of the refund. Refunds are grouped as covered, no credit in NetSuite and customer not in NetSuite, with the total not covered. It reports only retrieved rows, marks ambiguous lookups instead of choosing, flags truncated results and changes nothing in Shopify or NetSuite.
Business outcome
---
Finance sees which Shopify refunds have no NetSuite credit, with the total value not booked.
scenario
-
To answer a billing question, an agent opens the web store for the orders and then the ERP for the invoices and payments. The two often tell different stories about what was ordered, paid and owed, and spotting the difference takes careful reading.
What popdock provides
--
Give a customer email and, optionally, how many days to look back, which defaults to 90. It finds the customer in Shopify, stopping with a list if several match, and reads their orders, then finds the matching NetSuite customer and reads sales orders, invoices, payments and balance. The report shows one short section per system, then compares order counts and totals, unpaid invoice amounts against Shopify orders pending payment, and balance. Records on one side only and name differences are flagged, and values are shown side by side without deciding which is right. Read-only on both systems, with possible truncation flagged.
Business outcome
---
Support agents answer billing questions from one view of Shopify and NetSuite, with every mismatch shown rather than hidden.
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.