How to · internal process · procurement, office, HR and marketing ops · one register, four roles, no silent approvals

How to Build a Working Merch Request Channel for Your Team

Most merch problems inside a company are not printing problems. They are coordination problems that arrive wearing a printing costume. Two departments each order the same staff shirts for the same trade fair because neither told the other. An approver who never replies is treated as a yes. A coordinator discovers the deadline eleven days late because the brief lived in someone’s inbox rather than anywhere durable. A channel fixes none of these by making people more careful. It fixes them by removing the moment at which care is required. This page sets out the structure that works: who may raise a request, who may approve it, where the brief lives so that it survives a person leaving, how stock is counted and handed out, and the two habits that eliminate duplicate orders and silent approvals.

Request a merch programme brief More how-to guides

What actually goes wrong when there is no channel

The failure is never dramatic. It is a series of small, defensible decisions that each looked reasonable on its own and collectively produce an expensive mess. Recognising the pattern is the first step, because a company that can name its own failure mode will accept the structure that prevents it.

Duplicate ordering. A marketing colleague orders 60 promotional bags for a client visit. An operations colleague, working from the same event date and the same guest list, orders 60 more from another supplier. Nobody is dishonest. Each order is individually sensible. The combined result is double the spend, two sets of artwork to approve, and a storage problem by the following month. Duplicate ordering is almost always a consequence of requests living in private places.

Silent approval. A request arrives by email on a Friday afternoon. The approver reads it, has no objection, and moves on. Two weeks later the coordinator treats the non-objection as permission and places the order against a date that has already passed. Silence is not consent, and the fix is procedural rather than cultural: an approval is valid only when someone writes a decision.

Brief loss. The person who built the brief knows which logo version is approved, which reference matches the corporate palette, and why the back neck label was dropped in favour of a woven size tab. When they leave, or when they are simply busy in the week before an event, that knowledge leaves with them and the supplier restarts the conversation from zero.

Stock blindness. Leftover merchandise from an event is moved back to the office and put on a shelf. Six months later it is rediscovered during a scramble for new apparel, and the shelf turns out to hold a garment in a discontinued colour, in three sizes, with the old logo. The company buys replacements for a category it already owns.

Deadline arithmetic nobody owns. A production schedule is not the event date minus a comfortable margin. It is artwork approval, then a proof, then production, then finishing, then a delivery window, then a distribution window before anyone wears the item. If nobody holds the whole sequence, every party assumes somebody else subtracted the lead time, and the assumption is always wrong in the same direction.

Four service lines, four coordination problems

Each service line a supplier produces creates a different coordination demand, and a channel has to absorb all four. Below is what each line needs from the internal side, written from the production point of view.

Booth staff apparel

Staff apparel has the hardest size problem and the tightest deadline. A team of twelve needs a size breakdown by name, not a total, and the breakdown is usually wrong the first time because it is estimated rather than measured. It also needs a naming convention at the point of delivery, because a box of forty polos arriving at an office reception gets opened and distributed by whoever is closest. Treat the size breakdown and the naming convention as fields in the brief, not as a conversation. A second coat in a different colour for the two people who present on stage should be a separate line in the register, because it competes for the same production slot.

High-volume giveaways

Giveaways punish a late brief most severely, because unit economics collapse when quantity moves. A tote, a bottle or a notebook is simple to produce, and simple to produce late, but a late large run competes for the same machine time as every other large run in the building. Giveaways also fragment more than other lines: one event often needs two or three variants for different audiences, and each variant consumes a separate production setup. Register them as separate products with a shared event key, so the setup cost stays visible rather than buried in a unit count.

Lead-capture gifts

Lead-capture gifts sit at the intersection of merchandising and data handling, which makes them the line most often mishandled internally. The physical item is rarely the problem. The problem is that quantity, variant and hand-out rule are decided at the event itself, often by a person with no visibility into what was ordered. The register needs a line for contingency stock above the expected hand-out count, and a named owner allowed to draw from it without raising a new request. Giveaways are also the line where leftover stock is most likely, because attendance is forecast rather than guaranteed, so surplus should be counted back within a week of the event.

VIP and speaker kits

VIP and speaker kits are the lowest-volume, highest-attention line and they fail for a different reason: they are assembled informally. A notebook arrives, a pen arrives separately, a tote arrives from a different supplier in a different colour, and the kit presented to a speaker does not read as one thing. Each component is a separate request with a separate delivery, and nothing records that they were meant to arrive together. Register the kit as a single request with a component list and one assembly deadline, then treat a component arriving early as an open item rather than a completed one.

Four roles, and only one of them is the coordinator

The most common structural error is to make the coordinator also the requester. The moment that happens, the register stops being neutral, because the person deciding whether a request is sensible is the person who will be judged if the order fails. Separate the roles even in a small company. In a 40-person firm the coordinator may be the same individual for two departments on different days, but the request must still come from a named requester with a named approver.

Requester: Anyone inside the company who needs the item. Owns the brief content: product, quantity, sizes, audience, date, delivery point. Does not own the supplier relationship and does not negotiate.
Coordinator: One named person, usually in procurement, operations or marketing ops. Owns the register, the supplier relationship, the production schedule and the stock ledger. Consolidates requests, deduplicates them, and turns approved briefs into orders.
Approver: The budget owner for the line, usually a department head or the finance lead. Approves or rejects in writing with a stated response deadline. Approves the spend and the brand exposure, not the decoration method.
Finance contact: Confirms the cost centre, checks that the invoice carries the correct legal entity details, and confirms VAT treatment before the order is placed. Does not participate in the merch decision.

For a company with no dedicated procurement function the coordinator role is usually absorbed by an office manager or a marketing operations specialist. That is fine. What is not fine is leaving the role unnamed. An unnamed coordinator becomes whoever answers the loudest message, which in practice means the most senior person, which in practice means the person with the least time for it.

Where the brief lives: one register, not a folder of threads

The register is the whole system. Whether it is a spreadsheet, a shared workspace document or a lightweight issue tracker matters far less than four properties, and all four are about durability rather than features. It must survive staff turnover, which rules out chat histories: a chat channel full of useful decisions is write-only after a month and effectively unsearchable once the decisions sit under delivery notifications.

Every request gets a short identifier — a year, a category and a sequence number — and that identifier appears in the order, in the supplier correspondence, on the delivery note, and on the stock ledger row when the goods arrive. It is the thread that makes a query answerable six weeks later. The register must also record decisions, not just requests: who approved, when, and on what basis. Approval that lives in an email is approval that cannot be evidenced later, and the moment it matters is always later.

The field set has to be fixed and deliberately short, because a form with twelve required fields gets abandoned and a form with two gets ignored.

Field	Who fills it	Why it exists
Request ID	Coordinator	The join key between brief, order, delivery and stock
Requester	Requester	Single point of contact for specification questions
Event or purpose	Requester	Deduplication key. Same event and same product merges into one order
Product and variant	Requester	Prevents two people ordering the same item in different colours
Quantity and size breakdown	Requester	Size breakdown by named individual, not a total
Needed on site by	Requester	The real deadline. Everything upstream is derived from this
Cost centre	Requester, confirmed by finance	Prevents a valid order being unpaid because the code was wrong
Artwork status	Coordinator	Approved, in progress or not started. Production cannot start until approved
Approver and decision date	Approver	Makes approval evidenced and dated
Order and delivery dates	Coordinator	Lets the coordinator see the real queue and sequence it
Stock received and issued	Coordinator	Turns delivery into a quantity that can be drawn against
Leftover stock location	Coordinator	So the next request starts from what the company already owns

Three request classes, three approval paths

Not every request deserves the same attention, and a channel that applies full rigour to a 20-item reorder will be bypassed. Classify requests by decision risk rather than by value alone, then set a standing rule for the low-risk class so it never consumes an approver’s time.

Class A, standing reorder. An item already in the guidelines, in an approved colourway, in stock sizes, from an approved supplier, at or below a fixed unit ceiling set by the budget owner. No per-order approval. The coordinator places it, the ledger updates, and the approver receives a weekly digest. This class should carry the majority of request volume, because most merch is repetitive.

Class B, specified order. An item that matches the guidelines but differs in quantity, size mix, colour or decoration position. Requires the requester to confirm the specification and the coordinator to confirm availability and lead time. Requires budget-owner approval only where the total exceeds a stated ceiling.

Class C, outside the guidelines. A new product, a new colour, a new decoration method, a new supplier, or anything with a logo larger than the stated maximum. Requires the brand owner as well as the budget owner, because this is the class where brand exposure risk lives. Class C should be rare. If more than about a fifth of requests land in Class C, the guidelines are wrong rather than the requesters.

The value of the classification is that it converts approval from a conversation into a lookup. The requester knows before writing anything which path the request will take and how long it will take. A Class A request placed on a Monday can be on the shelf by Wednesday. A Class C request placed on the Monday before an event will not be delivered on time, and everyone finds that out at the start of the process rather than at the end.

Approval rules that end the silent approval problem

Silent approval is a design failure, not a discipline problem. People do not ignore approvals maliciously; they ignore them because the request format gives them no cheap way to decline. A request that can only be answered by composing an explanation will be left. A request that can be answered by choosing a button will be answered. Three rules do most of the work.

Silence is pending, never approved. Write it into the process. If an approver does not respond by the stated deadline, the request escalates to a named backup approver or is flagged in the next digest. It is never converted to an approval by the passage of time.

Set a response deadline, not just a send time. A request that arrives at 17:00 on a Friday has a realistic response window of the following Tuesday. Stating that explicitly is what converts a missed approval from a failure into a scheduling fact.

Requester response deadline: Coordinator sets it at submission, working back from the needed-on-site date and the stated production lead time
Approver decision deadline: Typically two working days for Class B, four for Class C
Backup approver: Named, not a job title. If the primary does not answer by the deadline, the request moves automatically
Digest: Weekly list of decisions taken, decisions pending and stock issued. One message, fixed day, no exceptions

Stock: counted at size level, issued against a name

The stock ledger is the part most companies skip and the part that saves the most money a year later. A single figure reading “40 polos on the shelf” is close to useless. It does not say which sizes, which colour, or whether the logo is the current one. The ledger needs size-level rows, a colour column, a garment-version column that distinguishes current from superseded artwork, and a location.

Issuing stock is a separate act from ordering it and deserves the same discipline. Every hand-out records the requester, the item, the size, the date and the reason. That single row answers the three questions that always arrive later: whether the company can honour a new request without buying more, whether a size run is nearly exhausted before a large event forces a top-up, and whether the leftover count after an event is a real number.

Count stock back within seven days of any event where items were carried off site. Attendance is a forecast, so surplus is rarely zero, and surplus that is not counted becomes invisible stock that the next requester will duplicate. Record the leftover with its location and its garment version, and let the next request start from that row.

One practical rule prevents most waste: never order a new quantity of a product line without first checking the ledger for what is already held. A company with 90 unissued shirts in four sizes has more capacity for the next event than its own requesters realise, and a top-up that ignores that is the most common avoidable spend in a merch programme.

Preventing duplicate orders mechanically

Goodwill is not a duplicate-order control. The two requests that collide are always the two nobody connected, and asking people to be more careful does not scale past a company of about thirty people. Two mechanical rules prevent almost all of it.

Merge by event key. Every request row carries an event or purpose field. Before a new order is placed, the coordinator searches the register for an open or recently closed request with the same event key and an overlapping product. A match is a merge, not a new order, and the merge is confirmed with the second requester rather than decided silently.

Separate standing stock from event stock. Stock held for general office use is drawn down rather than re-ordered. Event stock is ordered against a named event with a date. Keeping the two in different rows, and never letting an event request consume standing stock silently, removes the largest source of double counting.

The derived quantity is worth stating explicitly, because requesters miscalculate it. For an event, the working quantity is expected attendance multiplied by a hand-out rate, plus a contingency of roughly ten per cent, less confirmed existing stock. Skip any of those three terms and the order is wrong. Most teams forget the subtraction, which is the reason the office ends up with shelves that stay full for a year.

A worked sequence: 120 staff, one event, one quarter

The following is the ordinary shape of a small programme in an Armenian company, written as a sequence rather than a principle, because a channel is only real when it has dates.

Week one: the register is opened for the quarter. The coordinator lists the known events with their on-site dates, derives an order-by date for each by subtracting the production lead time plus a distribution window, and publishes those dates. Publishing order-by dates changes behaviour more than any other single action, because requesters stop negotiating against the event date and start planning against the order-by date.

Weeks two to three: requests cluster. This is when the channel earns its keep. A Class A reorder for office use, a Class B apparel order with a named size breakdown, a Class C giveaway variant for the client-facing stand, and a VIP kit for four speakers all arrive close together. Deduplication catches a second request for the same client-facing giveaway from the sales team. The Class C request is the long pole, so it moves to the front of the queue and its artwork goes to the brand owner the same day.

Week four: the deadline falls before the event, not after it. Artwork is approved, proofs go out, the coordinator consolidates the four requests into two supplier orders where the production route and lead time allow, and anything that has not reached approval by this point is escalated rather than carried.

Week five: delivery, count, issue. Goods arrive, the ledger is updated at size level, and distribution is scheduled so that apparel reaches named people rather than a shared pile. The contingency stock stays with the coordinator and is not distributed. In week six the contingency is drawn against during the event, each hand-out logged, and within seven days the surplus is counted, its location recorded, and the row left open so the next requester sees it before ordering.

Run that sequence four times and the register becomes the company’s institutional memory of merch: what it owns, what it has approved, which supplier delivered reliably and how long it took. A channel that only routes requests is a form; a channel that also accumulates state is the mechanism by which a mid-size company stops re-learning the same lessons every year.

Questions teams ask about merch request channels

Should merch requests go through the chat channel or a form?

Use a form or a structured row as the system of record, and treat the chat channel as notification only. A chat message is fast for the requester and unreliable as storage: it is hard to search later, it disappears into delivery chatter, and it gives no way to see what is pending. A structured row costs the requester two minutes and gives the coordinator everything needed to sequence work, deduplicate against existing stock and report at the end of the quarter. If the request arrives by chat, the coordinator’s first action is to transcribe it into the register and reply with the request ID.

Who should be allowed to approve merch spend in a small company?

One named person per cost centre, plus one named backup. In a company without a procurement function this is usually the department head for the budget and the finance lead for anything above a stated ceiling. What matters is that the approver is a person and not a role, that a backup exists in writing, and that the approval is recorded with a date. Splitting approval between the person who requested the item and the person who owns the budget is the control that catches errors, and for a small company it costs nothing to keep.

How often should leftover stock be counted?

Within seven days of any event where merchandise left the office, and once at the end of each quarter otherwise. The seven-day rule matters because leftover volume is highest immediately after an event and the temptation to count it later is strongest at that moment. The count must be at size level with a colour and garment version, because a single total cannot answer the next question, which is whether the company already owns enough stock to reduce the following order.

Is Corp-Merch a partner or an official supplier referenced on this page?

No. Corp-Merch is an independent B2B merchandise supplier. Any organisation, platform, standard or body referred to in this guide is named for information only, and nothing here implies a partnership, sponsorship, endorsement or official-supplier relationship with any of them. No client, reference or case study is claimed anywhere on this page.

This page is written for corporate buyers, procurement leads and office, HR and marketing operations teams in Armenia who order custom merchandise repeatedly and need an internal process that survives staff turnover. Corp-Merch is an independent B2B merchandise supplier, and no company, event, platform or standard named here is a client, reference or partner. Production lead times, the request classes and the stock rules described are typical operating practice for corporate merchandise programmes and vary with product, quantity, artwork complexity and delivery destination; each order is specified and scheduled individually against a written brief. Nothing on this page is a quotation, a commitment or a binding price, and all figures are illustrative rather than contractual.