Agreed, but with one caveat, stemming primarily from Amazon’s penchants for both purposefully segregating various teams - often enough, a factor leaving this or that of them to stumble, unknowingly, into cross-purposes - and that paradigm’s conjunction with the DPC (“Detail Page Control”) hierarchy (perhaps best envisioned as pyramidical, with the ART [“Amazon Retail Team”] at the pinnacle, w/ 3P Sellers representing the base, and a slew of other levels in between), and the ‘elections’ that Amazon’s automated mechanism are designed to conduct in order to determine the “Winning Contribution” for this or that attribute.
At the first blush, it would likely seem to be counterintuitive, but there’s a reason why Amazon published the policy embodied in the SHC’s “Update product shipping package dimensions and weight for prepaid returns” (link) - and I remain convinced that the main reason for doing so rests in the DPC elections.
The “Refrigerator Box Return” Initiative, which was originally announced as a “…short-term experiment to understand buyer behavior…” in the 081922 News Headline “Additional return shipping options for seller-fulfilled returns” (link, ‘new-style’), was quite-obviously actually impelled by the desire to foist off the return-shipping costs Amazon had for years been incurring by its customer-centric corporate policy of not holding members of its Buyer Community to the rather stringent return requirements embodied in certain of its CHC (“Customer-facing Help Content”) published policy pages, and the subsequent erosion of what limitations were described in that Headline - up to & including last week’s evisceration of the sole-remaining RAO (“Return Attribute Override”) reason, High Value Exemption, as announced in the 010926 News Headline “Prepaid return labels required for high-value items starting February 8” (link, Seller Central) - have all combined to produce a paradigm where setting dimensional & weight attributes via the mechanism outlined in the aforementioned SHC page, and/or crafting Return Instructions incorporating Amazon’s own customer-facing policy language, may not necessarily be followed.
Nevertheless, as I’ve been know to mention a time of more before (such as in this 072722 OSFE post [link]), it’s not at all unusual for this and that Amabot (and/or data-deduplication/backup routine, etc.) to pull data from a supposedly-segregated database, and use it to override data set in another by the 3P Seller; hence the reason why we expend time & treasure to not only set every-possible editable attribute to our OWN liking, but also use more of the same, going forward, to monitor for unwanted changes (which, as I suspect most all of us who’ve been around the block a time or two are aware, has long been another of Amazon’s penchants).
Doing so - and thus, being able to prove that we did - has pulled our fat of this or that fire lit when Amazon’s first (lowest) couple of support tiers resort to another of Amazon’s corporate philosophies, the “Defective By Design” (aka “sludge”) Business Model of Provisioning Customer Support.
