If your seller account is deactivated, the same four escalation routes get recommended in every group. We used all of them during a related-account suspension that ran from 12 April to 31 July. Here is the honest rating, so you can spend your time on the part that moves. 1. [email protected] — sent twice, 22 to 24 April. It does not reach Jeff. It routes to Executive Seller Relations. They read the case and changed nothing. Cost: ten minutes. Expect a reply, not an outcome. 2. The UK managing director escalation address. Reviewed. Upheld. 3. Three escalation agents. Reviewed. Upheld. 4. A BBB complaint. Reviewed. Upheld. Four routes, all answered, none of them changed the decision by a single day. Escalation gets a new person to re-read the argument you already made. If the argument is the problem, a new reader will not fix it. What actually worked, and cost nothing: On 1 July I phoned Account Health. An agent said the appeal needed a timeline of what had been shared and what had changed since. That was the turning point, and it came from a normal support call rather than an escalation. Appeal 13 went in on 25 July with three things: - A dated change log covering bank account, login email, account name, mobile number, and the switch from SMS 2FA to an authenticator app. Every timestamp was taken from Amazon's own confirmation emails, so no line depended on being believed. - Written confirmation from the other party that none of my details remained on their account. Their word, not mine. - Our own business information corrected to match Companies House exactly, including a beneficial owner missing from the record. Their verification cross-references Companies House, and a mismatch keeps the loop open. On the same day, I contacted Account Health in Mandarin. The language queues are smaller and less rushed. The agent read the whole submission, confirmed it answered every requirement and escalated it for internal re-review. Reinstated 31 July. Six days, after twelve rejections spread over three and a half months.

A pattern worth knowing if you generate product images. The rejections almost never come from bad lighting. They come from four things the model added on its own, all of which Amazon publishes as main-image standards: 1. Background. Pure white, RGB 255, 255, 255. Image models love a soft grey-to-white gradient because it looks like a real studio. It is not pure white and it does not pass. 2. Frame fill. The product has to occupy at least 85% of the image. Models like breathing room and will pad the composition. 3. Added elements. No text, logos, watermarks, borders or badges. Watch how often a model invents a label for a bottle it has never seen. 4. Extra objects. Nothing in shot that is not in the box. The eucalyptus sprig, the linen, the second jar - all props, all out. Now the useful bit, because you probably already knew those four. Go and look at where they sit in your prompt. In almost every prompt I have seen, they are in the same sentence as the style direction: "...on a clean white background, no props or text, product centred and filling most of the frame, styled like a premium wellness brand with soft directional light..." Everything in that sentence is negotiating with everything else. Swap "premium wellness" for "clinical minimal" and the model re-reads the whole line, and the constraints move with the style. That is the mechanism behind the thing that annoys everyone: the same prompt producing a compliant image one day and a gradient the next. The fix is structural, not a better sentence. Separate the blocks. Product facts in one. Style in one. Constraints in one, as explicit values rather than prose - background: #FFFFFF, frame_fill: 0.85 minimum, prohibited: text, logo, watermark, border, props. Then change the style block as often as you want. The constraint block never moves, so compliance stops being something you audit after the render. That structure is the whole reason ProductJSON Studio exists. It is free and it runs on your own key, so it costs nothing to test the split on a prompt you already use:

Every few weeks someone asks me the same thing. Brand is overseas, nothing in the UK yet, first British customers on the horizon. Do they start on Amazon UK or build the Shopify store first? It gets debated as a marketing question. Most of the answer is in the paperwork, and the paperwork is nearly identical on both routes. Three things worth settling first. 1. There is no VAT-free runway. The £90,000 registration threshold belongs to UK-established businesses. A business established outside the UK has no threshold at all. If stock is sitting in a UK warehouse, registration is due before the first sale, whichever channel it sells through. Plenty of founders plan a soft launch on the assumption they have headroom. They do not. 2. The marketplace changes who remits, not whether you are registered. Where an overseas seller's goods are already in the UK at the point of sale, the marketplace carries the VAT liability on that sale, so Amazon collects and remits it. That is a cash-flow difference and an admin difference, not an exemption. On your own store you are the seller of record and the returns are yours to file. 3. The compliance base does not move with the channel. An importer or authorised representative established in the UK, packaging producer obligations, WEEE if the product has a plug or a battery. These are triggered by placing goods on the market here. Selling direct does not remove any of them. It only removes the party who would have asked you for the documents before letting you list. What is left is the part that genuinely differs, and it is not tax at all. A marketplace rents you demand that already exists, and keeps the customer. Your own store hands you the customer, and charges you for every visit. For a brand with nothing here yet, that usually argues for proving the product where the demand already is, and keeping the store live as the brand's home rather than its only door. Validate on the channel that has traffic. Build the direct engine once you know the product sells in this market.

Most agentic-SEO advice stops at "add product schema". Worth going one level down, because the schema most stores have is incomplete in the same two places. When an AI shopping assistant evaluates a product page it parses the Product JSON-LD and works through the Offer block. Two things are almost always present: price and priceCurrency availability And two things are almost always absent: shippingDetails, an OfferShippingDetails object. Holds the shipping rate and the delivery time, split into handling days and transit days, and scoped to a destination. hasMerchantReturnPolicy, a MerchantReturnPolicy object. Holds the return window in days (merchantReturnDays), the policy category, who pays the return fee, and the return method. Both are part of Google's merchant listing structured data, so this is not a speculative future field. It is documented, parsed today, and skipped by nearly every Shopify theme, because a human buyer never needed it to render the page. The result is a page that reads well to a person and answers two of the most common pre-purchase questions nowhere a machine can find them: how fast, and what if it is wrong. The five-minute check: 1. Open any product page on your store. 2. View source, or use your browser's rich results test. 3. Find the Product JSON-LD block, then the Offer inside it. 4. Search for shippingDetails. Then search for hasMerchantReturnPolicy. 5. If either is missing, write down which template renders that block. That is the file you edit, not the policy page. One caveat worth saying plainly: put real values in there. Structured data that contradicts what your delivery page says is worse than nothing, and both a shopper and a review process will find the gap. The free Shopify Agentic SEO Guide has the whole field checklist, including these two: https://gumroad.puniverse.net/l/shopify-agentic-seo-guide?utm_source=skool&utm_medium=community&utm_campaign=shopify_growth_sprint_01&utm_content=daily-2026-08-17

Most cross-border product decisions I see start with two browser tabs and a subtraction. $34.99 on Amazon.com. £29.99 on Amazon.co.uk. The UK looks better, so the gap looks real. It is not a fair subtraction, because the two figures are quoted on different terms. A UK consumer price is displayed inclusive of VAT. At the standard 20% rate, £29.99 is £24.99 to you and £5.00 to HMRC before a single other cost lands. A US price is displayed exclusive of sales tax, which is added at checkout, so what you see is far closer to what the seller keeps. Roughly 17% of the UK number was never yours. Everything else you have to pay comes after that. The screening order that stops this: 1. Compare net to net. Divide every UK price you screenshot by 1.2, then look at the gap again. This one step ends most ideas, which is exactly what you want it to do at this stage rather than after the container lands. 2. Cost the landed value, not the invoice. Duty and import VAT are calculated on the customs value, which includes freight and insurance, not the unit price the factory quoted. 3. Then apply the fee stack. Referral fee and fulfilment come out of whatever survived, and they come out of the net figure, not the shelf price. 4. Only now ask whether the UK is actually underserved. A gap that is real on price still needs to be real on demand. The uncomfortable part is that a good screen says no far more often than it says yes. Our engine is built that way on purpose: most runs return no gap, and that verdict is the one that protects your cash. If you want to see how it scores a product, it is here: https://www.puniverse.net/product/us-uk-product-arbitrage-engine?utm_source=skool&utm_medium=community&utm_campaign=us_uk_arbitrage_launch_01&utm_content=daily-2026-08-15 One ask. Drop a product idea in the comments with the two prices you are comparing, US and UK. I will run the first division with you and tell you honestly whether the gap survives it. Educational only, not tax advice.