Merch program management software is the system of record for branded merchandise a company buys on an ongoing basis — sourcing, storefronts, inventory, approvals, budgets and fulfillment in one place, rather than in a spreadsheet, a Shopify store and five people's email. It is a different category from gifting software, which is built to send one-off gifts and attribute them to pipeline. If your problem is who is allowed to order what, at what price, from which budget, you are looking for the former.
That distinction matters more than it sounds, because most of the tools that come up when you search for this are gifting tools. They are good at sending. They are not built to govern an ongoing program. This page is about the governance problem: what it actually looks like, what a system has to do to solve it, and how to tell whether you have outgrown the spreadsheet.
The problem this software exists to solve
Merch programs rarely fail at the buying step. Buying is the easy part — there are thousands of distributors who will happily sell you a thousand hoodies. Programs fail at everything that happens after the purchase order.
A recognisable version: a company has merch in three locations, two Shopify stores nobody fully owns, and five people ordering promotional products independently because that was faster than asking. Nobody can answer basic questions. How much of last quarter's spend went to events versus onboarding? Which office has the medium hoodies? Did the regional team use the current logo? Is the $14,000 sitting in a warehouse an asset or is it obsolete inventory in last year's brand colours?
None of those are procurement questions. They are operational questions, and they compound. The larger the organisation, the more the merch program starts to resemble an unmanaged supply chain that happens to be paid for out of a marketing budget.
What "management" actually has to mean
Vendors use "management" loosely. Here is the specific set of capabilities that separates a system of record from a store with a logo on it.
Budget controls that bind before the order, not after
A department cap that is enforced at checkout is a control. A monthly report showing that a department overspent is a receipt. The difference is whether the software can decline an order. If budgets live in a finance spreadsheet and merch lives somewhere else, you do not have budget controls — you have reconciliation.
The useful shape is a cap per team, per period, checked at the point of order, with the remaining balance visible to the person spending it. That last part removes most of the enforcement burden, because people generally do not try to overspend a number they can see.
Approval workflows that route by what is being ordered
Not every order needs approval, and a system that requires approval for everything gets routed around within a month. What works is conditional: orders under a threshold go straight through, orders over it route to a named approver, and anything touching brand assets routes to whoever owns the brand.
The failure mode to design against is the approver who becomes a bottleneck. If approval takes more than a day, people stop using the system and go back to ordering directly — which is exactly the behaviour the program was built to eliminate.
Brand governance enforced by the catalog
The most reliable brand control is not a PDF of guidelines. It is a catalog that only contains approved products, with approved logos, in approved placements. If a regional team cannot order the wrong thing, you do not need to police whether they did.
This is the capability that most obviously separates a managed program from a company store. A store lets people buy. A managed catalog decides what buying is even possible.
One inventory position across every location
Merch in a warehouse, merch in an office closet and merch at an agency are the same asset and should appear in one count. Split visibility is how companies end up reordering something they already have three hundred of, and how the mediums run out everywhere at once with nobody noticing until an event week.
Fulfillment that triggers without a handoff
The step that quietly consumes the most time is the one between "someone ordered" and "someone shipped it." If that involves an email to a warehouse, a spreadsheet, or a person checking a queue, it will be the bottleneck in every busy week. Order and fulfillment need to be the same event.
Program management versus gifting platforms
These get compared constantly and they solve genuinely different problems. The comparison is worth making honestly.
Gifting platforms — Sendoso, Reachdesk and similar — are built around a send. A sales or marketing team picks a recipient, picks a gift, and the platform handles delivery and ties it back to a CRM record so the spend can be attributed to pipeline. The value is in the attribution and the campaign workflow. Sendoso has been consolidating this space, acquiring Postal in 2025 and Merch in 2026.
Program management is built around a catalog and a set of rules that persist. The recipients change constantly; the governance does not. There is no campaign to attribute, because the program is not a campaign — it is infrastructure that onboarding, events, client gifting and internal stores all draw on.
There is a second axis underneath that one: how much control you want over the merchandise itself. A gifting platform coordinates third-party suppliers and warehouses, which buys reach — a broad catalog, quick to send from. An integrated platform makes, holds and ships the goods itself, which buys control over what gets made, how good it is, how it ships, and who can order it against which budget. Neither is better in the abstract; they are different bets, and the integrated one trades catalog breadth for that control.
Plenty of companies genuinely need both. The mistake is buying one expecting it to do the other's job, which usually surfaces about four months in, when someone asks a question the tool was never built to answer.
When you have outgrown the spreadsheet
Most companies adopt this kind of software later than they should, because the spreadsheet keeps almost working. Reasonable signals that the moment has passed:
- More than one person orders merch, and they do not always know what the other ordered
- You hold inventory in more than one place, and no single view shows both
- Someone has ordered something off-brand in the last year and it shipped
- You cannot answer "what did we spend on merch last quarter, by team" without an afternoon of work
- A recurring process — onboarding kits, event shipments — depends on one person remembering to do it
- You have written off obsolete inventory, or suspect you should have
Three or more of those and the spreadsheet is not saving you money; it is deferring a cost that is quietly accruing.
How Brandmerch approaches it
We built Brandmerch as a merch operations platform rather than a gifting tool, which shapes most of the design decisions. Procurement, branded storefronts, stockroom inventory and fulfillment run on the same catalog and the same permission model, so a budget cap or an approval rule applies wherever the order originates.
Practically that means department budget caps checked at checkout, approval routing by order value and by brand asset, a catalog that constrains what can be ordered rather than a guideline document that asks nicely, one inventory position across locations, and fulfillment triggered by the order rather than by a handoff.
It also means we make the merchandise. Sourcing, decoration, warehousing and shipping are ours rather than brokered out, which is why a send can be built to spec instead of picked off someone else's menu, why the stock count is the actual stock, and why a bad run is one company's problem to fix. Storefronts are their own product rather than a checkout bolted on: a company store with budgets and approvals, a gift catalog, a pop-up for an event, a pre-order campaign that collects orders before production, or internal wholesale ordering — built no-code, with tax and VAT handled automatically, and each one connected to inventory so an order either pulls from stock or triggers production with no handoff. Enterprise Groups handle the people side, scoping what each part of a large org can see. For agencies, Agency Mode extends the same idea across separate client companies, with clean ownership handoff.
Sends can be triggered programmatically. 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, an HRIS or an internal tool can fire merch without anyone opening a storefront.
We are a poor fit for some things, and it is cheaper for both of us to say so here. We do not ship a prebuilt CRM app or in-CRM pipeline-attribution reporting — if the reason you are buying is a dashboard showing gifts influencing opportunities inside Salesforce, a gifting platform is purpose-built for that and we are not. If you need a dozen shirts once and will not need anything again, a distributor is faster and cheaper than any software. And if a single person handles all merch for a company of forty, a spreadsheet is genuinely adequate — the governance overhead only pays for itself once more than one person is spending.
Questions worth asking any vendor
Whichever direction you go, these separate real capability from a features page:
- Can a budget cap actually block an order at checkout, or does it only report afterwards?
- Can approval rules differ by order value and by product, or is it one rule for everything?
- If merch sits in two locations, do I see one number or two?
- When someone orders, what has to happen before it ships — and is any of it manual?
- Can a regional team order an outdated logo? Walk me through what stops them.
- What happens to inventory we already own — can it come into the system, or does it stay invisible?
The last one catches more vendors than the others, and it is the one most likely to matter in your first month.
If you want to see how this maps onto a specific program, our guide to managing a merch program across teams covers the operational side in more depth, and pricing is public.
