Short answer: read the requirement's wording first, then ask which of four owners could actually resolve it. If the answer already exists as a browsable attribute, it is a catalog filter. If it changes the physical nail or a brand asset produced for that nail, it is a custom specification. If it changes what surrounds the nail at unboxing, it is packaging scope. If it changes who packs, ships or hands off the order, it is a fulfillment rule. The rest of this guide walks one mixed request through that test. The buyer scenario below is hypothetical and is used only to illustrate the classification logic.
Start with the wording, not the wishlist
Requirement wording is the first decision element because buyers often blend several asks into one sentence. Split that sentence until each clause names a single thing that can be accepted or rejected on its own.
Three wording tests do most of the work:
- Attribute vs. change. "Short almond, glossy finish" reads like an attribute; "shorter than your standard short almond by two millimeters, matte top" reads like a change request.
- Nail vs. surroundings. Anything describing the nail itself points to product scope; anything describing the box, insert, label or card points to packaging scope.
- Decision vs. destination. "Which styles are available at my volume?" is a decision question; "ship direct to my customers" describes a destination and belongs to fulfillment.
Write each clause on its own line with the exact wording the buyer used. Do not polish it yet — the raw phrase is the evidence you will use to justify the routing.
Hypothetical request used in this guide
Assume a buyer sends a five-line email. (Hypothetical example; not a real customer conversation or a 365nails case.) The lines are: "we want short almond glossy styles"; "can you do a shape that is flatter at the base"; "we need our logo on the box"; "inserts in two languages"; and "can you ship each order directly to our customers." Five lines, four buckets — and one line is really two requirements.
Bucket 1: catalog filter
A requirement is a catalog-discovery dimension when the buyer can narrow an existing range by a value the supplier already publishes. The 365nails catalog hub organizes product discovery by product type, craft and MOQ, with HTML, PDF and XLSX formats and human product matching. That set — type, craft, MOQ, format — is where browse-style questions belong.
- "Show me short almond glossy styles" → filter by product type and craft.
- "What can I order at my volume?" → filter by MOQ.
- "Send the list as a spreadsheet" → filter by format, answered with the XLSX version.
If a buyer's line can be answered by pointing at a hub dimension, do not open a custom brief for it. Human product matching is the bridge when the buyer cannot name the attribute; it is still catalog discovery, not a new specification.
Bucket 2: custom specification
A requirement is a customizable product or asset element when no catalog attribute can satisfy it. 365nails custom projects can cover nail shapes, lengths, colors, artwork, finishes and branded packaging, subject to feasibility and the confirmed quote.
Two conditions travel with every custom line: feasibility is assessed first, and the confirmed quote is the authority — never an estimate given mid-conversation. "Flatter at the base" is a shape change; it moves to custom review and does not become a promise in the reply email.
Bucket 3: packaging scope
A requirement is a packaging component when it names a physical part of what the buyer receives around the nail: box, sleeve, insert, label or unboxing card. Branded packaging sits inside the customizable list above, so packaging is custom work — but it belongs on its own line because different people approve artwork, copy and structure.
Keep product specification and packaging specification as separate rows in the same request. When the buyer says "logo on the box," record the component (box), the asset (logo), the placement and who signs off. A packaging line should never be merged into a nail-style line, even when both end up in one quote.
Bucket 4: fulfillment responsibility
A requirement is a fulfillment responsibility when it changes who packs, ships or hands off. 365nails combines ready-stock products, custom manufacturing, packaging support, dropshipping fulfillment, and real human 1V1 video selection — dropshipping is one supported route, not a default.
Treat "ship direct to our customers" as a route question to be confirmed, not an entitlement. Do not attach timing, stock or cost assumptions to it; those belong only to terms confirmed for that specific order.
Classification table
- Catalog filter — wording: browse or volume question. Owner: catalog discovery. Output: shortlist and format.
- Custom specification — wording: changes the nail or a brand asset. Owner: custom review. Output: feasibility plus confirmed quote.
- Packaging scope — wording: names a component around the nail. Owner: packaging support. Output: component, asset, sign-off.
- Fulfillment rule — wording: changes who packs or ships. Owner: fulfillment route. Output: route decision, no assumed timing.
Tie-breakers for mixed lines
Some lines fit two buckets. Use these order rules:
- Attribute before change. If a published attribute resolves it, it stays a filter even if the buyer used custom-sounding language.
- Nail before box. If the line changes both, split it; the nail specification and the packaging component get separate rows.
- Route last. Confirm the product and packaging scope before treating a shipping line as a rule, because a route decision depends on what is being shipped.
The test is resolution: whichever owner could close the line without asking another owner first is the bucket it belongs to.
365 Take
Most messy B2B requests are not messy requirements — they are unlabeled ones. The four buckets only work if the reply keeps them visible: quote the buyer's clause, name the bucket, and say who will respond. That single habit prevents the common failure where a packaging aside quietly gets treated as a product change, or a catalog question spawns a custom brief nobody asked for. Classification is cheap; rework is not.
Operator Move
Before replying, split the email into clauses and tag each one. Route filters through the catalog hub, push genuine changes into custom review with feasibility and the confirmed quote flagged, list packaging components on their own rows, and hold fulfillment lines as route questions. Then send the buyer a one-screen summary that shows every clause with its bucket and owner. When the mixed request is genuinely commercial — a blend of product, branding and shipping asks — contact sales to have the classification reviewed against the confirmed scope.
