T The People on the System

An ERP is not used by "the company." It is used by nine or ten specific people, each of whom touches a different sliver of it, at a different hour, with a different question in their head — and by another five who never log in at all but whose paperwork flows through it anyway. This chapter walks through every one of them: what their day actually looks like, which screens they live in, what they write versus what they only read, and how one wholesale order passes through all of their hands in turn. If the previous chapters taught you the business, this one teaches you the cast.

What you need to know first

A wholesale apparel brand doing $2–10 million a year — the size this book is written for — typically runs on eight to twenty-five people, and many of the jobs in this chapter are halves of one person. At the five-person stage the founder is the sales manager, the credit department, and half of customer service; the production coordinator is also the warehouse manager on receiving day. The jobs still exist even when they share a body — the point of naming them separately is that they are different relationships with the system, and your ERP has to serve each relationship well even if two of them log in with the same account.

Two vocabulary points before the tour:

A job is not a role. Chapter P makes this precise, but you need the idea now. "Production coordinator" is a job — a set of tasks. "May adjust inventory" is a permission — a thing the system allows. A good ERP never checks jobs; it checks permissions, and lets the owner decide which jobs get which. The reason is practical: at a small brand one person holds three jobs, and at a big one a single job is split across four people. Any rule you write against a job title will be wrong within a year.

Readers outnumber writers ten to one. For every person who creates an order there are several who only need to see it: the warehouse checking what to pick, finance checking what to invoice, the owner checking how the season books against last year. Most ERP screens are read screens, and the quality bar for them is different — a read screen must answer a question in seconds, while a write screen must make an error hard to commit. Confuse the two and you get the classic bad ERP: data entry forms everywhere and answers nowhere.

The cast, at a glance

Here is the whole company in one table. The rest of the chapter takes them one at a time.

The owner

The owner is the only person who uses the whole system, and paradoxically the person with the least patience for it. They will not read a manual, they will not file a ticket, and they will judge your entire ERP by whether one number they care about is on the first screen they see.

A normal day. Coffee, then the dashboard: bookings for the current selling season against the same week last year; cash position; anything on credit hold; anything late from a factory. That is a ninety-second read, and if the ERP cannot supply it the owner reconstructs it from three spreadsheets and stops trusting the system. Mid-morning they are pulled into an exception — a key account wants a price, a factory slipped two weeks, the factor declined a new boutique — and each exception is a conversation that ends with a decision the ERP must record: a price override, a revised delivery, an order released on the owner's say-so. Afternoons in season are selling; afternoons out of season are planning next season's line with whoever does merchandising.

What they write. Approvals and exceptions, almost exclusively. The owner rarely creates records; they change the ones that matter. A price override on a key account's order. A hold released because they know the buyer personally. The final wholesale price on next season's line after the costing meeting from chapter F. Every one of these is exactly the kind of write your audit trail must capture with a who and a when, because six months later somebody will ask "who approved this?" and the honest answer is usually "the owner, verbally, in a hallway" — unless the system made recording it effortless.

What they fear. Selling goods that do not exist, and running out of cash while profitable on paper. Both fears are ERP questions: the first is the ATS discipline of chapter 1, the second is the cash timeline of chapter K.

The sales rep and the showroom

Most brands this size do not employ their sales force. They engage independent reps — self-employed agents who carry several complementary, non-competing brands (their "lines") into a territory they know, for a commission of roughly 10–15% of wholesale on what they sell. A showroom is the same idea with a lease: a company holding permanent space in a market building, staffing it year-round, showing your samples to the buyers who walk its floor. Chapter H covered the economics; here is the relationship with your system.

The rep is an outsider with insider needs. They do not work for you. They also cannot sell without knowing your line, your prices, your stock, and your ship dates — and every minute they spend fighting your systems is a minute they spend selling one of their other lines instead. This tension defines the whole design problem. Give them too little access and they write orders on paper against stock that is gone; give them too much and one contractor's stolen laptop exposes every account you have.

A market day. A rep at a trade show writes orders in bursts — fifteen appointments, twenty minutes each, badge-scan, size-run, next. The booth wifi is bad (chapter R treats this as the operational emergency it is). What they need from the system at the booth: the line with wholesale prices, live-enough ATS for immediates, the account's status (may I even sell to them, or are they on hold?), and order capture that survives offline. What they must NOT see: your cost. A rep who knows your margin negotiates against you; the field-level masking your ERP applies to cost columns is not paranoia, it is the industry's standing assumption.

Between markets. The rep's off-peak questions are status questions: did my order confirm, did it ship complete, did my customer's chargeback get resolved, and — the one they care most about — where is my commission statement? Commission is computed on order-written, net-invoiced, or cash-collected depending on the rep agreement (the spread between those three definitions is real money; chapter H's exercise makes you compute it). Whichever the contract says, the ERP is the ledger it is computed from, and a rep who disputes a statement will go line by line.

Customer service and sales operations

If the rep is the mouth of the company, customer service is its ears — and in wholesale, "customer service" mostly means order lifecycle management, not consumer complaints. The job: everything that happens to an order between the day it is written and the day it is paid, that is not picking boxes.

The daily grind. Morning: the open-order report. Which confirmed orders enter their ship window this week? Which are short — sold 60 units, only 48 landed — and need a decision: ship short, substitute, or call the buyer? Which buyers changed something — a door address, a cancel date extension, a size-run swap — by email overnight? Each of those emails becomes an order edit, and each edit has consequences downstream (a changed delivery re-allocates stock; a changed door reprints labels). Afternoon: returns authorizations. A buyer wants to send back a defective carton; CS issues an RA number (return authorization) so the warehouse knows the box arriving next week is legitimate, and finance knows a credit memo is coming.

What makes the job hard is that CS holds the pen on records other people created and other people fulfill. They edit the rep's order, against the coordinator's supply, ahead of the warehouse's pick. Every edit screen they touch needs three things: the change itself, the reason (buyers dispute; "who extended this cancel date and why" is a chargeback defense), and visibility of the blast radius — if this delivery moves a week, does it collide with the buyer's routing window? A good ERP shows the collision at edit time; a bad one lets the chargeback discover it.

The production coordinator

The coordinator owns the inbound half of the business: everything between "the season sold" and "the goods are on the shelf." Chapter G covered the factories and the calendar; what matters here is the shape of the coordinator's system use, because it is unlike everyone else's: low volume, high stakes, long horizons. The warehouse writes two hundred small facts a day. The coordinator writes five big ones a week — and a wrong one strands fifty thousand dollars on a boat.

The season's arc. At book close, the coordinator runs the cut sheet: demand (confirmed futures orders plus a stock bet the owner signs off on) minus coverage (anything already made or in progress), by SKU, against each factory's minimums. That arithmetic decides what gets made; it is the single most consequential computation in the company, and it is pure ERP — the order book on one side, the inbound book on the other. Then the placing: purchase orders or production runs to factories, each with a cost, a quantity, and the dates counted backwards from the buyer's cancel dates (goods must land, clear, and ship to stores inside the window — miss it and chapter I's penalties apply). Then months of chasing: WIP check-ins with factories over WhatsApp and email, lab-dip approvals, slippage. Every slip is a re-computation — which orders does a two-week delay endanger? — that the coordinator asks the ERP, or asks a spreadsheet if the ERP cannot answer.

Receiving day is the handoff: the container lands, the warehouse counts it in, and the coordinator reconciles what landed against what was ordered — short shipments, overs, wrong ratios — and decides what to do about the gap. The receipt is the warehouse's write; the judgment about the gap (accept the short run and close the PO, or hold it open for a second delivery) is the coordinator's, and the ERP must let both verbs exist separately.

The warehouse

The warehouse is where your data model meets physical reality, and physical reality wins every argument. Whatever the system says, the shelf holds what it holds. The warehouse staff — a manager and, in season, a few pickers — are the highest-frequency writers in the whole company, and they write from a forklift, wearing gloves, against a clock.

The four verbs. Everything the warehouse does to stock is one of four moves, and chapter 1 already taught you why each must write a ledger line: receive (goods land against a PO), pick/ship (goods leave against an order), transfer (goods move between locations), count (a human recounts a shelf and the system records the difference it discovered, not just the new number). There is no fifth verb. The day your ERP lets someone type a quantity directly into a stock cell is the day your ledger stops being one.

A ship-window day. The pick list is sorted by the routing rules of whoever is being shipped: a boutique gets a box with a simple packing slip; a major gets chapter I's full ceremony — cartons packed to spec, GS1-128 labels, an ASN transmitted before the truck leaves the dock. The picker's questions are brutally simple: what do I pick, from where, packed how, labeled how, on which truck, by when. Screens for the warehouse must be readable at arm's length, workable with numb fingers, and honest about sequence — pick, then pack, then label, then ship confirm. The ship confirmation is the single most load-bearing write in the system: it decrements stock, completes the order line, triggers the invoice, and starts the revenue clock. One tap, five consequences.

Credit and finance

At this size "finance" is one sharp person plus an outside accountant, and their half of the ERP runs on a different clock from everyone else's: not the season, but the month — invoice runs, statement runs, remittance reconciliations, month-end close.

Credit control is a gate on sales. Before an order confirms, someone has decided this buyer may owe you this much. For factored invoices (chapter K) that decision is largely outsourced — the factor approves the buyer or refuses, and an unapproved buyer ships prepaid or not at all. For house accounts it is a judgment recorded as a credit limit, and the honest way to store that judgment is as a dated ledger of reviews — who decided, when, based on what — with the number on the account being merely the latest entry's conclusion. A hold is another ledger entry with a reason. When the buyer's rep calls shouting, the reason is the conversation.

The deduction slog. The least glamorous recurring task in wholesale finance: the remittance arrives and it is short. The buyer paid $9,412 against a $10,000 invoice, citing a compliance chargeback, a co-op advertising allowance, and an early-pay discount taken late. Finance matches each deduction to its reason code, decides dispute-or-eat for each, and files the paperwork for the disputes — all of it against the shipment records, label data, and timestamps your ERP kept. Chapter I said it and this chapter repeats it: the warehouse's data quality is finance's ammunition. The persona who wins the chargeback dispute is the picker who scanned the carton correctly three months earlier.

The people who never log in

Half the traffic through your ERP belongs to people with no account on it. Design for them deliberately.

The retail buyer interacts through whatever surface you give them: a PDF linesheet and an email thread at minimum; a wholesale portal (yours, or JOOR/NuORDER) where they browse the line, place and track orders, and reorder basics if you have one; full EDI (chapter 4) if they are a major — in which case "the buyer" is really their replenishment system sending an 850 at 3 a.m. Every one of these is the same event to your ERP — an order arriving — through a different door. The portal deserves one warning: a buyer's login is an invitation to their own account's orders and nothing else, and it is a different animal from a staff login. Never model it as a low-privilege employee; model it as an outsider with a keyhole.

The factory lives on email, WhatsApp, and whatever PDFs you send. What they need from your system (via you): tech packs, POs with unambiguous quantities by size, packing and labeling requirements, and payment status. What you need from them, recorded into your system by the coordinator: WIP status, ship dates, invoice amounts. A factory portal is a someday; a coordinator who records factory reality promptly is the today that matters.

The factor receives an assignment schedule of invoices (a file, weekly) and answers credit approval requests (a portal of theirs, or email). The accountant wants clean exports at month-end: sales journal, AR aging, inventory valuation. Neither will ever open your app. Both are integrations in the chapter 4 sense, even when the "integration" is a CSV attached to an email — the export is a contract, and it must reconcile.

One order, every hand

Here is the whole chapter in a single object. Follow purchase order #4417 — a boutique's futures order, written at a February trade show, shipping in August — through every pair of hands it passes.

Notice three things. Every hand touched a different aspect of the same object — nobody needed all of it. Every write happened at a specific moment with a specific reason, which is why the audit story of chapter 1 insists on recording intent, not just changed rows. And the order's history is a chain of custody: order → run → receipt → shipment → invoice → payment. When any link cannot be traced to the previous one, some month-end reconciliation is about to fail.

Permissions are the org chart

Now compress everything above into access design. Three patterns cover nearly all of it:

1. Grain: what may you do? A closed catalog of permission keys — manage styles, adjust inventory, create orders, confirm orders, manage credit, and so on — bundled into roles the owner can customize. Small enough to reason about; the moment your catalog needs a spreadsheet to explain, you have modeled the org chart of a company you are not serving.

2. Scope: whose records? The rep sees their accounts and their orders; the sales manager sees everyone's. This own-versus-any split must be enforced in the query — a WHERE owner = me composed into the SQL — never by filtering rows after fetching them, which leaks counts, corrupts pagination, and eventually leaks the rows too.

3. Field: which columns? Cost is the canonical case: the coordinator and owner see it, the rep and warehouse do not — and "do not see" must extend to every derived surface. A rep who can sort by margin, or read a grid's totals row, can binary-search a hidden cost out of the system without ever seeing the column. Mask at the point the view is constructed, including aggregates, or you have not masked at all.

The rhythms: a day, a week, a season

Load on an apparel ERP is not flat; it is tidal, and each persona brings a different tide. Daily: the warehouse and CS dominate — pick lists at 7 a.m., ship confirms until the trucks leave, the open-order review in between. Weekly: finance's invoice and remittance cycles; the coordinator's WIP roundup; the sales manager's Monday book review. Seasonally: everything crescendos twice — market (reps and orders, hundreds of writes a day for three weeks, half of them from terrible wifi) and the ship window (warehouse and CS, with finance a beat behind). The quietest week of the year for order entry is the loudest for production chasing.

This tide table is operational guidance, not trivia: schedule migrations in the slack (chapter 9), test your offline path before market (chapter R), and never — never — ship a breaking change to the warehouse screens during a ship window.

What this means for your ERP

The requirements this chapter has been accumulating, stated plainly:

• One screen per question, per persona. Owner: bookings/cash/exceptions. Rep: line, ATS, my orders. CS: open orders in window. Coordinator: cut sheet, WIP, receipts vs POs. Warehouse: today's picks; the four verbs. Credit: aging, exposure, holds. Each is a view over the same tables — the personas share one truth and see different projections of it.
• Reads and writes are different products. Read screens optimize for answer-in-seconds; write screens optimize for hard-to-err: staged edits, visible blast radius, reasons attached to consequential changes.
• Permissions: grain + scope + field, checked as permissions (never job titles), composed into queries (never post-filters), masked into aggregates (never just columns).
• Every consequential write carries who/when/why. The audit trail is not a compliance feature; it is how CS answers buyers, finance fights deductions, and the owner remembers their own hallway decisions.
• The outsiders get doors, not desks. Buyer portal scoped to one account; every order channel (portal, platform, EDI, email-keyed-by-CS) landing in one order table; exports to factor and accountant treated as contracts.
• Respect the tides. Offline-capable order capture for market; bulk operations for the window (nobody allocates one order at a time); no deploys onto a shipping warehouse.

Field notes & further reading

• O*NET: Sales Representatives, Wholesale and Manufacturing: the U.S. Department of Labor's occupational profile for the rep role — tasks, tools, and work context. Useful as a reality check that "writes orders and maintains account relationships" is the job, everywhere, not just in apparel.
• JOOR and NuORDER (Lightspeed): the two dominant wholesale order platforms. Browse their marketing pages as requirements documents — every feature they advertise is a question buyers and reps actually ask, and the list of retailers each claims tells you which majors push their vendors onto which platform.
• GS1 US, apparel and general merchandise: the identification standards (GTIN, GS1-128) behind the warehouse's labeling ceremony. The picker's persona is downstream of this document.
• Chapters H, I, J and K each cover one persona's domain in depth; this chapter is the map that places them around one table.