Customer Support for E-commerce

Almost every buying guide for ecommerce customer support software compares the same surface features: channels supported, seats included, whether there's an AI bot. Those are the wrong axis. The decision that actually determines whether a helpdesk moves your numbers is which data plane its store integration can read — and that is the one thing vendor comparison pages consistently blur.

Start with your own ticket mix, because it dictates everything downstream. Pull 200 recent conversations and sort them into two piles: those about an order that already exists (tracking, changes, cancellations, returns, refunds) and those from someone who hasn't bought yet (sizing, stock, compatibility, shipping cost). For most stores past a few hundred orders a month the first pile dominates by a wide margin — but the ratio is yours to measure, not to assume, and it is the only number that should drive the purchase.

Those two buckets are answered by completely different data, fetched over completely different mechanisms. Post-purchase questions need order records — order number, fulfillment state, carrier, refund status — which on Shopify live behind the Admin API and require the merchant to grant read scopes on orders and fulfillments. Pre-purchase questions need live session context — what the shopper is looking at right now, what's in the cart, at what price — which comes from a storefront pixel running client-side and never touches the Admin API at all.

A vendor can ship one, the other, or both. The marketing language for all three cases is identical: "deep Shopify integration." So when a page tells you agents will see "full customer context," the only useful follow-up is: which context, read through which scope? A pixel-based integration cannot answer "where is my order," no matter how good the inbox around it is. An Admin-API integration can, and requires a correspondingly heavier install and permission grant.

This page is written from the position of having built the pixel side. It sets out what each integration model can and cannot answer, so you can match a tool to your actual ticket mix instead of to a feature grid — including the cases where the honest answer is that our own connector is the wrong shape for your volume.

We built the pixel side of this, so the most useful thing we can offer is a precise account of what that model does and doesn't reach — stated as an architectural boundary rather than a roadmap gap, because it follows from the install model and won't change by us shipping harder.

What a storefront pixel can see, and why

Converge's Shopify connector ships as two client-side extensions: a theme app embed that loads the chat widget, and a web pixel that streams storefront activity. Both run inside Shopify's sandbox. Neither requests Admin API access, which is why connecting is an OAuth click that auto-installs the pixel rather than a permissions review over your order data.

What that puts in the agent's sidebar is the shopper's current session: the product being viewed (image, title, price) and the live cart (items, quantities, total), updated in real time over WebSocket as the shopper moves. When someone opens a chat from a product page, the agent already knows which product — the single most common clarifying question in pre-purchase support, removed.

What it does not put there is order history, fulfillment status, tracking numbers, or refund state. Not as a missing feature — as a consequence of the sandbox. A web pixel observes storefront events in the browser; it has no channel to your order records, and no client-side extension can have one without a server-side API grant. That is the same boundary for any pixel-based integration, ours or anyone's.

The practical translation, against the ticket mix above: this architecture addresses the pre-purchase bucket well and the order-and-returns bucket not at all. Your agents can answer WISMO from Converge, but they'll read the answer out of Shopify admin in another tab, exactly as they would with no connector installed. If order tickets dominate your queue and you want them answered without a tab switch, an Admin-API helpdesk is the right purchase and we'd rather you knew that before the trial than after.

Where the inbox layer does the work instead

The part that is not architecturally constrained is channel consolidation, and for ecommerce that carries more weight than the feature's genericness suggests. A shopper who DMs on Instagram, follows up on WhatsApp, and emails about a return is one customer with one problem; in separate apps they are three unrelated threads, and the agent re-asks for context the customer already provided twice.

Converge ingests Instagram, WhatsApp, Messenger, Telegram, Discord, Zalo, email and the website widget natively — first-party integrations, not email forwarding — into one thread per customer with history attached. Internal notes let a second agent be pulled into a return exception without the customer seeing the handoff. Quick replies cover the sizing and shipping answers that repeat fifty times a week.

None of this requires store data, which is why it is worth solving first: it is the cheapest problem on the list and it does not depend on a permission grant you may not want to make yet.

Pricing against the peak, not the average

Converge is $49/month flat for up to 15 agents. The reason to state that in a section about seasonality rather than a pricing table is that the flat rate only matters at the peak: if your team is four people year-round, per-seat tools are competitive. If you add six seasonal agents every Q4 against a peak-season volume spike, a flat rate means the December bill equals the March bill, and the staffing decision stops being a budget decision.

That is the whole of the pricing argument, and it is deliberately narrow. Flat-rate billing does not compensate for missing order reads. A store where WISMO is 40% of tickets should weigh a $300/month tool that answers WISMO above a $49/month tool that doesn't.

How to test any vendor's claim in ten minutes

The claims on this page and on every competitor's page are checkable, and the check is quick:

• Ask which scopes the app requests. On Shopify this is visible on the install screen before you approve. No read_orders means no order data in the inbox, whatever the marketing page says.
• Open a ticket from a customer with no live session. Pixel-based context panels are empty here. This one test separates the two architectures in under a minute.
• Ask an agent to answer WISMO without leaving the tool. If they open store admin, the integration hasn't deflected the ticket.
• Price it at December headcount. Quotes assume your average month; your worst month is the one that breaks the budget.

Run those four against us and you'll get the answers stated above: client-side scopes only, empty panel with no session, tab switch for WISMO, same price in December. Run them against an ecommerce-native helpdesk and you should get the inverse, plus a bigger invoice. Both are legitimate purchases — for different ticket mixes.