How to Build a Coin Shop SOP Manual That Staff Actually Uses

The real purpose of a coin shop SOP

Coin shops rarely fail because nobody knows how to do the ordinary version of a task. The risk appears when the shop is busy, the regular manager is away, spot is moving, a customer brings an unusual item, or a handoff crosses shifts. In those moments, experience that lives only in one person’s head cannot protect the business. A good SOP turns that experience into a repeatable operating decision.

The manual should answer four questions at the point of work: What must happen? Who is allowed to do it? What evidence must be recorded? What happens when the normal path is not safe or does not fit? If a procedure cannot answer those questions quickly, staff will replace it with memory, habit, or a message to the owner. That makes the owner the operating system and keeps the shop from scaling.

Treat the SOP library as part of the control environment, alongside cameras, vaults, insurance conditions, user permissions, and reconciliation. It should make correct work easier, expose exceptions earlier, and leave a record that another person can review. The goal is not paperwork for its own sake. The goal is fewer ambiguous handoffs, fewer silent adjustments, faster training, and a reliable answer to “why did we do it this way?”

Start with a risk map, not a table of contents

Many manuals begin with whatever topics are easiest to write: opening the door, answering the phone, or ordering supplies. Begin instead with the moments where an error can move metal, release money, expose customer information, or misstate the books. List the shop’s workflows from arrival to close and score each one for value at risk, frequency, reversibility, and reliance on a single person.

The first wave normally includes opening and closing, seller intake, identity and authority checks, testing, purchase approval, price locks, payment release, inventory receiving, location moves, shipping, refunds, cash drawer settlement, and physical counts. Add rare but consequential situations such as suspected counterfeit material, a customer dispute, a broken seal, a system outage, a robbery alarm, or an estate representative whose authority is unclear.

Then identify the control point in each workflow. A control point is the step at which the shop can still prevent or contain a loss: verify the lot before accepting custody, require approval before releasing a high-value payment, count a transfer before the sender and receiver separate, or quarantine a return before making it available for sale. Your manual should be deepest at those points. Routine navigation instructions can remain brief.

Prioritize the first ten procedures

• Score financial, custody, compliance, and customer impact.
• Mark every place where responsibility changes hands.
• Find steps that only one employee currently understands.
• Write high-value and hard-to-reverse workflows first.

Use one repeatable procedure format

Staff should not have to decode a new document style for every task. Give every SOP the same compact anatomy. Start with a plain-language purpose and the trigger that starts the procedure. Name the roles that may perform or approve it. List the tools or records required. Write the normal steps in order. Define the required evidence, the stop conditions, the escalation path, and the person who owns the procedure. Finish with a version number, effective date, and next review date.

Keep the action steps observable. “Check the item carefully” is not a controlled instruction. “Match the item description to the intake record, confirm the recorded weight on the approved scale, complete the required test method, and attach the result before pricing” gives a supervisor something to teach and verify. Where judgment is unavoidable, state the boundaries of that judgment and the condition that requires a second opinion.

Use links to system records rather than asking staff to retype the same information into a form, spreadsheet, and paper log. One transaction should connect the customer, appointment, quote, items, test evidence, payment, inventory status, and later movement. The SOP describes how that record advances. The system should preserve who advanced it and when.

Separate policy, procedure, checklist, and reference

These documents solve different problems. A policy states the rule: for example, no employee may approve a purchase they initiated above a defined risk threshold. A procedure explains how the work moves from start to finish. A checklist confirms that critical steps occurred during a specific event. A reference supplies supporting information such as approved test methods, location codes, carrier contacts, or escalation numbers.

Combining all four into a twenty-page document makes the important instruction difficult to find. Keep the procedure concise and link to the deeper policy or reference. Use a checklist only when missing one step would create real risk, not as a transcript of every mouse click. The opening checklist might verify alarms, vault access, starting cash, scale status, pending transfers, and unresolved exceptions. It does not need to explain the history of the alarm system.

This separation also makes updates safer. A change to an approved carrier list should not require rewriting the shipping procedure. A new approval threshold can update the policy and system rule while the overall purchase process remains stable. Smaller controlled documents are easier to own, test, and retire.

Write where the work happens

The best procedure writer is usually the person who performs the task well, paired with someone responsible for risk or reconciliation. Observe a real transaction. Record the actual sequence, interruptions, tools, decisions, and handoffs. Ask what changes when the amount is larger, the customer is new, the item fails a test, the network is unavailable, or the transaction continues into another shift.

Draft the procedure in the language employees use at the counter, then test it with a competent person who did not write it. If that person must ask the author what a step means, the document is not finished. If the written procedure differs from safe reality, decide whether the workflow or the document should change. Do not quietly preserve a fictional process because it looks more formal.

Place the final instruction inside the workflow when possible. A receiving screen can show the short checklist for seal verification. A high-value purchase can present the approval requirement before payment. A closing dashboard can show unresolved cash, unlocated items, open transfers, and exceptions. A searchable manual remains useful, but contextual instructions reduce the distance between the rule and the decision.

Design explicit handoffs

A coin shop handoff should transfer both custody and responsibility. “I left it for the afternoon team” is not enough. The record should identify the item or lot, current state, physical location, sender, receiver, time, and any open condition. The receiver should actively accept the handoff rather than becoming responsible by assumption.

Write sender and receiver duties separately. The sender completes and labels the record, stages the property in an approved location, and describes unresolved work. The receiver verifies the identifier, seal or contents as required, accepts custody, and either continues the workflow or raises a variance. For transfers, shipments, high-value purchases, and vault moves, decide when two-person verification is required.

Use status names that describe reality: awaiting test, awaiting approval, payment authorized, quarantined, ready to stock, in transit, received with variance, or reconciled. Avoid a generic “pending” state that hides the responsible party. Every incomplete state should have an owner and an aging clock. That makes the morning review useful and prevents metal from living indefinitely on a desk.

Build the exception path before it is needed

A procedure that covers only the happy path transfers the hardest decisions back to improvisation. For each critical step, define reasons to stop: identity cannot be verified, the customer’s authority is uncertain, test results conflict, weight differs from the record, spot feed is stale, payment fails, a seal is broken, a count varies, or a required approver is unavailable.

A safe exception path has five parts. First, contain the physical and financial risk: pause payment, quarantine the item, or prevent inventory from becoming sellable. Second, preserve evidence such as images, test data, timestamps, and messages. Third, assign the exception to a person with authority. Fourth, record the decision and reason. Fifth, define the corrected exit state. “Manager handled it” is not an auditable resolution.

Not every exception deserves the owner’s attention. Create tiers based on value, type, and reversibility. A missing optional photo might return to the employee for completion. A payment-name mismatch or a failed assay may require management. A credible safety or security threat follows an emergency plan. Clear tiers keep the process moving without normalizing risk.

Control versions and retire old instructions

Put one person in charge of each procedure and one person in charge of the library. The procedure owner understands the work; the library owner ensures consistent naming, approvals, publication, archiving, and review. Every live SOP needs an identifier, version, effective date, approver, and review date. Staff should see only the current approved version during normal work.

When a process changes, record what changed and why. Notify affected roles, update linked checklists and system prompts, and confirm that old printed copies are removed. Archive prior versions rather than deleting them; a historical transaction should be evaluated against the rule that was effective when it occurred. The archive must be clearly marked so nobody follows it by mistake.

Use event-driven reviews as well as calendar reviews. Revisit a procedure after a meaningful variance, insurance requirement, tool change, new location, role change, or repeated employee workaround. A quarterly owner attestation can confirm that the process still matches reality. High-risk workflows may deserve monthly exception review even if the full document changes less often.

Train for decisions, not signatures

Reading a document and signing an acknowledgment does not prove competence. Training should combine explanation, observation, supervised performance, and a scenario that includes an exception. A buyer might demonstrate a routine intake and then explain what happens when identification, authority, or test results do not align. A closer might complete a normal settlement and then resolve an unexplained drawer variance without deleting or overwriting evidence.

Maintain a role-based training matrix. It should show which procedures each employee must learn, when training occurred, who observed competence, and when recertification is due. Limit permissions until training is complete. Temporary coverage should be explicit; a person filling in for one shift should receive only the access and instructions required for that assignment.

Managers should watch for workarounds. A workaround can signal poor training, but it can also reveal that the approved process is slower or less accurate than the real one. Ask why it exists before disciplining the symptom. Then fix the design, retrain, or enforce the rule as appropriate. The manual earns trust when staff see that feedback produces controlled improvements.

Measure whether the manual changes operations

Page views and signed acknowledgments are weak outcome measures. Track the operational signals the procedure should improve: unresolved handoffs at close, transactions returned for missing evidence, approval turnaround, inventory adjustments, cash variances, items in quarantine, transfer aging, repeat exceptions, and time to train a new employee. Review both volume and severity.

Do not aim for zero reported exceptions. A healthy control system may report more issues at first because staff now know where to put them. The important questions are whether exceptions are caught earlier, resolved consistently, and used to improve the process. Watch for procedures that generate repeated overrides; either the rule is poorly designed or the business is accepting a risk it has not formally addressed.

Include a short SOP review in the daily or weekly operating rhythm. Discuss one open exception, one aging handoff, and one proposed process improvement. Monthly, review access, overdue training, and procedures nearing their review date. This keeps the manual connected to the floor rather than preserved as an annual compliance exercise.

A practical 30-day rollout

1. Days 1–5: Map the shop’s end-to-end workflows, rank risk, and select the first ten procedures. Name an owner for each one.
2. Days 6–12: Observe actual work and draft the normal path, evidence, permissions, handoffs, stop conditions, and exception route.
3. Days 13–18: Test each draft with a different employee using realistic scenarios. Correct ambiguous instructions and system gaps.
4. Days 19–24: Approve versions, place instructions in the workflow, archive obsolete documents, and configure matching roles and statuses.
5. Days 25–30: Train by role, observe performance, launch the exception review, and establish the first set of operating measures.

Start small enough to finish, but do not stop at documents. The manual, system permissions, screen prompts, physical labels, management reviews, and training records should all describe the same operating model. When they disagree, staff will follow the fastest signal—usually the software or the person standing next to them.

The best SOP manual is visible in the quality of the shop’s records: every ounce has a state, every dollar has an authorization, and every exception has an owner.

Put the procedure inside the transaction

bullionOS connects appointments, intake, inventory, invoices, payments, locations, and reconciliation so staff can follow one controlled record instead of rebuilding the story from separate tools.

Connect this workflow in bullionOS

Bring this operating process into one connected dealer record. Explore Coin Dealer Software & POS, or visit the bullionOS dealer operations resource hub for related guides.