Acknowledged is not the same as alive
The request is real and it is specific. A planner needs to reconcile open-to-buy at classification level while the suite insists on rolling up at department. An allocator needs store-grade size profiles the allocation module does not carry, and is exporting to a workbook to build them. A merchandiser wants the season broken into drops the way the line is actually bought, not into the two fixed halves the data model was born with. Someone writes it up properly — screenshots, the workflow it blocks, the workaround it forces — and sends it in.
What follows has a liturgy to it. The account manager logs it and says it has been raised with product. The portal assigns a reference number and a status — under consideration, planned for evaluation, on the backlog. Sometimes other customers can vote for it, and a handful do. A release goes by, then another. The status does not change. At the next account review the item is raised again, acknowledged again, and re-logged with sincere apologies for the delay. The renewal arrives and is signed anyway, because the request, however irritating, was never the whole relationship.
The detail worth dwelling on is what did not happen. Nobody said no. There is no artifact anywhere in that sequence recording a decision against the request — and that absence is what makes the silence so hard to act on. A no would trigger a response: build around it, price the gap into the renewal, start evaluating alternatives. Silence defers all of that indefinitely, while the status page keeps a small light of plausibility on. A team can carry a request through multiple renewal cycles on nothing more than that light.
A roadmap is an allocation, not a queue
To understand why the light so rarely turns into a release, look at the decision from the vendor’s side of the table. A large suite’s engineering capacity is finite and heavily committed before any enhancement ticket is read. Platform work claims a share off the top — performance, security, re-architecture, the migrations that keep the product sellable at all. Strategic bets claim the next share: the capabilities that open new markets or answer whatever the analyst reports say the category now requires. Commitments negotiated into large enterprise deals claim another. What remains is the pool the enhancement backlog competes for, and the backlog does not share it politely.
The competition is run through some variant of the same arithmetic everywhere: expected value, times the number of customers touched, over the cost to build. Every product organization dresses it differently, and the dress does not change the outcome. Revenue at risk weighs heavily, so the accounts that can move the number get heard first. Reach weighs heavily, so features that touch the entire base outrank features that touch a segment. Strategy weighs heavily, so the requests that happen to align with where the product was already going get adopted and the rest wait. The backlog is not a queue; it is a competition the request re-enters every quarter, against a field that refills every quarter.
It is important to be precise about what this is not. It is not negligence, and it is not contempt for smaller customers. The product managers running triage are doing exactly the job the suite’s economics require of them: a business that sells one product to grocery, big box, specialty, and apparel at once can survive shipping the wrong niche feature, but it cannot survive systematically misallocating engineering against its revenue. The math is doing what it was designed to do. That is precisely why appeals to the account team, better-written tickets, and passionate advocacy at user conferences move the outcome so rarely — none of them changes any input to the equation.
Workflow-specific is narrow by definition
Now put the apparel request into that equation and watch what happens to it. Nothing a planning team asks for is exotic from inside the job. Size curves carried at style-color rather than category default. Prepack logic that survives contact with the allocation engine. Drops inside a season, because that is how the range is actually bought and delivered. A chase workflow that knows what lead time means. Wholesale prebooks and DTC replenishment planned against the same inventory without pretending they are the same business. These are not edge cases; they are the load-bearing structure of the merchandising calendar.
But the scoring model does not ask whether the request is central to the requester’s job. It asks how many customers the change would touch — and the honest answer is: the customers who plan in size runs, prepacks, and drops, which in a cross-industry base is a minority segment. The very specificity that makes the request valuable to an apparel team is what makes it narrow in the reach column. Workflow-specific means narrow by definition, and narrow is what the equation is built to deprioritize.
Meanwhile the requests that do clear the bar are the broad ones: reporting improvements, admin and permissions work, API surface, dashboard refinements. All genuinely useful, all touching every customer in the base, and none of them the item on the planning team’s list. This produces the experience that makes the whole thing so corrosive to trust: the suite visibly improves, release after release, while the gap that forces the nightly export stays exactly where it was. The product gets better every quarter at everything except the thing you asked for — and from inside the scoring model, that is the system working correctly. The category-level version of this argument, and what it implies about who should build for apparel at all, is made in why apparel needs its own operating system.
When it does ship, it ships generalized
Occasionally a workflow request survives triage, and what happens next is instructive, because the request rarely ships as the thing that was asked for. A product manager who funds a change for a cross-industry base has to build it for the cross-industry base — that is what made it fundable. So the size-curve request returns as a flexible attribute hierarchy that can, with configuration, be persuaded to hold something curve-shaped. Drops return as generic sub-season buckets with no opinion about delivery flow. The buy-sheet request returns as a configurable line-item field set that knows nothing about vendor minimums because minimums are an apparel concept and the feature is not allowed to be apparel-specific.
The team that asked then attends a configuration workshop, maps its concepts onto the abstraction, gets most of the way there, and quietly keeps the workbook that does the real thing. The generalization that made the feature fundable is the same generalization that makes it miss. Configuration can express a great deal, but it cannot express a concept the underlying data model does not hold; a bucket does not become a drop because it was renamed one. This is the honest boundary of the configurable-suite promise, and it is worth understanding before the buying decision rather than after — the fuller comparison is drawn in Apparel OS vs enterprise retail suites.
Settle, or route around
While the request sits, the work does not wait, so teams choose between two rational responses. The first is settling: adapt the process to the tool. Plan at department because the suite rolls up at department, and accept that classification-level signal arrives late or not at all. Carry the category size curve because style-color curves have nowhere to live, and absorb the broken sizes at the outlet end of the season. Settling is quiet and looks free, because its cost arrives as slightly worse decisions at a grain nobody is measuring anymore.
The second response is routing around: the shadow workbook. Export what the suite holds, do the real work in the sheet — the curve overrides, the drop phasing, the minimum-versus-plan reconciliation — then re-key the result back in, or simply let the sheet become where the truth lives. Most teams do both at once, settling on some dimensions and routing around others, and the routing is not a fringe behavior of struggling organizations. In an August 2018 McKinsey article, merchants — at retailers generally, not apparel planners specifically — were reported to spend “approximately two-thirds of their time gathering data, managing exceptions, ‘firefighting,’ and participating in meetings to syndicate with colleagues.” That pattern predates any one suite and no single workflow gap explains it; but every unresolved gap feeds exactly that column of the day, one export and one reconciliation at a time.
The uncomfortable part is that the workaround is not a mistake. Any given week, building the sheet is the correct decision: the buy is due, the vendor cutoff is real, and the roadmap is not coming. The workaround is the right call every single week; the cost accrues somewhere nobody is looking — in the handoffs, in the re-keying, and in a dependency this essay comes to shortly. The anatomy of what that fragmentation does to margin is traced in the disconnected apparel stack and priced in the cost of disconnected workflows.
The workaround silences the request
There is a second-order effect here that deserves more attention than it gets. The moment the workaround exists, the pain that produced the request stops being visible to the vendor. Usage telemetry shows a healthy, active account. The support queue shows nothing, because a workbook does not file tickets. The account review loses its urgency, because the planner who felt the gap has solved it and has better things to fight about. The request stops being re-raised — not because it was addressed, but because the person carrying it found a private exit.
Follow that back into the prioritization equation and the loop closes. The reach column needed evidence — escalations, at-risk revenue, visible pain across accounts — and the coping behavior is suppressing exactly that evidence. The better a team copes, the less evidence the vendor ever sees, and the less likely the gap clears triage in any future quarter. Workflow gaps in large suites are, in this sense, self-concealing: the accounts that feel them most competently are the accounts that hide them best. Nobody designed this. It is simply what happens when a signal has to travel from a planner’s Tuesday through an account manager’s summary into a scoring model that counts louder things.
The workaround leaves with its author
The deferred cost of routing around lands somewhere specific: in who holds the knowledge. A workaround is authored. It encodes one person’s accumulated judgment about the gap it papers over — which export to pull and on what day, which columns arrive wrong and how to correct them, which cells are load-bearing and which are decoration, which numbers the suite can be trusted on and which have to be rebuilt from source. None of that is written anywhere, because the workaround was never a project. It was a Tuesday afternoon, repeated until it became the process.
The suite’s official workflow, meanwhile, is documented, trained, and supported — and partially fictional, because the real decisions happen in the sheet. This is a stable arrangement with a single point of failure. People change roles in the ordinary course of a career: a promotion, a maternity cover, a move to a competitor, a reorganization. When the author of the workaround moves on, the workbook stays behind but the reasoning leaves with them, and the replacement inherits a set of artifacts with no rationale attached. The org chart says the process lives in the suite; the process lives in a person — and the organization discovers which is true at the precise moment it can no longer ask them.
What follows is a slow, invisible retraining: a new planner reverse-engineering undocumented logic under a live buying calendar, re-deriving corrections the predecessor made silently for years, and occasionally trusting a cell that should not have been trusted. The cost rarely appears on any ledger, because officially the system of record was the suite all along. This is the quiet answer to a question buyers rarely ask about workarounds: not what they cost to run, but what they cost to inherit.
When the big suite is still the right call
The argument so far has a boundary, and it should be drawn plainly. For a global, multi-banner retailer, the same mechanism that starves a mid-market request works in the buyer’s favor — because that buyer sits at the top of the allocation. An account that moves the vendor’s number gets roadmap conversations, not portals; its requests arrive with revenue attached and often leave with contractual commitments attached. The prioritization mechanism is not broken for everyone. It works precisely for the buyers it was built around.
And for those buyers, the suite carries genuine advantages that a category-specific system does not automatically match. Deep, transactional integration with a global ERP estate — finance postings, master-data governance, intercompany flows across banners and regions — is real engineering that large suites have spent decades hardening. An in-house IT organization that manages the vendor relationship as a discipline, with named product owners, architecture review, and the leverage to negotiate roadmap items into contracts, converts the vendor’s process into something navigable. Procurement standards at that scale can legitimately require vendor size, security posture, support coverage across time zones, and a reference base of comparable deployments — requirements that exist for good reasons and that scale of vendor exists to meet.
So the claim here is not that enterprise suites are bad software. It is a claim about weight class: the feature-request mechanism serves the customers the suite is economically organized around, and a mid-market apparel brand is not one of them. Buying a system whose change process answers to someone else’s requirements is a real cost, and it belongs in the evaluation next to license fees and implementation effort — not discovered two renewals in, one dead ticket at a time.
Interrogate the change process, not the feature list
All of which reframes what a software evaluation is for. A demo shows the product as it exists on the day of the demo; the contract is for years of the vendor’s future decisions. The feature list answers the first question. Almost nothing in a standard evaluation answers the second — and the second is where this essay’s mechanism lives. You are not buying the feature list; you are buying the vendor’s decision process, and that process can be interrogated directly, for any vendor of any size.
Ask how requests are triaged: on what cadence, against what criteria, and which named role decides. A functioning answer describes a person and a rhythm; a weak answer describes a portal. Ask what happens to a request that will not be built — specifically, whether the customer is told. A vendor willing to say no in the open has a working process and respects your planning enough to give you a decision you can act on; a vendor whose backlog has no exit is describing the silence this essay opened with. Ask for recent examples of shipped changes that originated with customers of your size, and how they travelled from request to release — not a policy statement, an actual trail. And ask where configuration ends and customization begins for the workflows you actually run: what can be changed without the vendor’s engineering, what requires it, and what happens to custom work at upgrade. The distinction is load-bearing, because customization does not escape the roadmap problem — it privatizes it.
None of these questions is adversarial, and a good vendor — large or small — answers them easily, because a good vendor has thought harder about its own change process than its buyers have. The point of asking is not to catch anyone out. It is to make the thing this essay describes visible before signature, while it is still a selection criterion rather than a discovery. A fuller evaluation frame, including the questions that precede vendor conversations entirely, is in the apparel software buyers guide.
The dead feature request, read correctly, is not a service failure. It is a disclosure — an accurate, involuntary statement of where a brand ranks in its vendor’s allocation of the future. The useful response is not to write better tickets, escalate more warmly, or collect more votes on the portal. It is to hear what the silence is saying, price it the way you would price any other fact about a long-term operating partner, and let it inform the one decision that is still entirely yours: whose roadmap your planning workflow lives on.