An enterprise swag program is branded merchandise run as shared infrastructure across offices, regions and departments — one approved catalog, one inventory position, and rules about who can order what from which budget. The distinguishing feature is not volume. It is that many people order independently and the program still has to hold together.
Most enterprise merch problems are not procurement problems. Buying is easy. What breaks is everything after the purchase order, and it breaks in the same four ways at almost every company past a few hundred employees.
The four failure modes
1. Merch is in places nobody can see
Stock at a 3PL, stock in an office closet, stock at the agency who ran last year's conference. Each is a real asset and none appear in the same count. The visible symptom is reordering something you already own several hundred of; the invisible one is the mediums running out everywhere at once because no single view showed the aggregate.
2. Regional teams order independently
Not out of defiance — because the central process was slower than a corporate card. Once that happens you get multiple logo interpretations, multiple vendors, multiple invoices and no consolidated spend number. The fix is never a stricter policy. It is a faster approved path.
3. Budget is reconciled, not controlled
Departments have merch budgets that exist in a finance spreadsheet while merch is ordered somewhere else. So the budget is a report produced after the money is gone. A control declines the order at checkout; a report just tells you what happened.
4. Recurring programs depend on a person remembering
Onboarding kits, regional event shipments, executive gifting. These run on somebody's calendar reminder, and they fail the week that person is on leave.
What the software actually has to do
Vendors use "enterprise" to mean SSO and a bigger invoice. The capabilities that matter are narrower and more specific:
- Multi-storefront off one catalog. Each region or department gets its own store, but they draw from the same approved product set. Separate stores with separate catalogs is just the original problem with better branding.
- Budget caps enforced at the point of order, with the remaining balance visible to the person spending it. That visibility removes most of the enforcement burden, because people do not generally try to overspend a number they can see.
- Conditional approval routing. By order value and by whether brand assets are involved. Approve-everything workflows get routed around within a month.
- One inventory position across locations, including stock you already own before the system arrived. Ask any vendor this specifically — it is the question that catches the most of them.
- Fulfillment triggered by the order, not by a handoff to a warehouse inbox.
- Role-based access that survives reorganisation. Permissions attached to a team, not to named individuals who change roles.
- A grouping axis you name yourself. Most platforms impose their own hierarchy. What you want is to carve the account along the line your business actually runs on — brands, regions, divisions, chapters — and then share catalogs, logo kits, address books and inventory to those groups, with orders labelled by group so reporting rolls up without anyone maintaining a spreadsheet.
Structuring the program
Centralised, federated, or both
Fully centralised gives you perfect brand control and a queue that regional teams will eventually bypass. Fully federated is fast and produces the four failure modes above.
What works in practice is federated ordering on a centralised catalog: regions order freely and instantly, but only from products the brand team approved, within budgets finance set. Autonomy in the choice, control in the constraints.
Who owns it
The three plausible owners want different things. Brand wants control, Procurement wants unit cost, People Ops wants the onboarding kit to arrive on day one. Programs that stall usually have no single owner, or an owner whose incentive is only one of the three. Name one owner and make the other two stakeholders.
What to measure
Most enterprise merch programs report on spend, which says nothing about whether the program works. More useful: what percentage of merch spend went through the approved path, how much inventory is over 12 months old, and how long a regional order takes from request to delivery. That third number predicts whether people will keep using the system.
The build-versus-buy question
Large companies often consider running this on existing tools — a Shopify store plus a 3PL plus a spreadsheet. That works, and it is genuinely cheaper, right up until the approval and budget logic has to live somewhere. That logic is the thing you would be building, and it is more intricate than it looks: conditional routing, per-team caps that reset on a period, and a permission model that survives a reorg.
A reasonable rule: if merch spend is under roughly $50k a year and one person handles it, assemble it from parts. Past that, or once more than one team orders independently, the coordination cost exceeds the software cost.
Where Brandmerch fits
Brandmerch is built as merch operations rather than gifting, which is the relevant distinction for enterprise. Procurement, multi-storefront ordering, stockroom inventory, approvals and fulfillment run on one catalog and one permission model, so a budget cap or approval rule applies wherever the order originates rather than per-store.
Storefronts do more work here than the word suggests. They come in five shapes because enterprises need different ones at once: a company merch store with budgets and approvals built in, an interactive gift catalog, a temporary pop-up for a conference or product launch, a pre-order campaign that collects orders before production so you stop guessing at quantities, and internal wholesale ordering at cost. Built in a no-code designer, with sales tax and VAT handled automatically. Each is inventory-connected — an order pulls from stock you already hold or triggers production, with no manual handoff — and one shop can mix ready-to-ship stock, on-demand production and self-fulfilment.
Enterprise Groups handle the people side: buyers scoped to whatever axis the org actually runs on, named by the client rather than imposed, with collections, logo kits, address books and stockroom inventory shared to the right groups and every order labelled for reporting.
Existing inventory can come into the system rather than staying invisible beside it, which is usually the deciding practical detail — a platform that only counts what it sold you leaves half your assets unmanaged.
Sends are programmable: the REST API creates a send, checks ready-to-ship inventory and emits send.created, send.shipped and send.delivered webhooks, so a CRM workflow or HRIS can trigger onboarding kits and campaign sends without anyone opening a storefront.
Where we are the wrong fit: we do not ship a prebuilt Salesforce or HubSpot app, or attribution reporting inside the CRM. If the reason you are buying is a dashboard showing gifts influencing opportunities, a gifting platform is purpose-built for that. If merch is genuinely centralised through one person with no regional ordering, the governance layer is overhead you do not need yet.
For the operational detail, see our guide to managing a merch program across teams, and enterprise covers how this maps onto distributed teams. Pricing is public.
