Pricing your labor and bench time

The labor library is where you keep every reusable task (soldering, setting, polishing, casting) with its rate and cost basis. Each piece picks from the library: the line itself just records "this much of this task." When you raise your hourly rate, every piece that uses an hourly library entry reprices automatically.

This guide covers the rate itself, how granular to make the library, and a naming convention so the library stays usable past the first twenty entries.

Labor rate

The hourly rate for in-house production work — bench work, stone setting, carving, polishing, or any other shop labor. This is what gets billed when a piece's labor line is "in-house," meaning you (or your shop) did the work, not an external service vendor.

Two things to know:

1. It's the rate the work commands, not your total income target. If you'd pay someone $60/hour to do the work, your in-house labor rate is $60/hour — even when you're the one doing it. Your time as the owner-operator (running the business, marketing, talking to customers) doesn't get rolled into this number. That income comes from markup and your margin target, not from inflating the labor rate.
2. External vendors don't use your labor rate. When a labor task on a piece points at an outside service (a stone setter, a polisher, a casting house), Pennyweight uses that vendor's billed rate, not your in-house rate. The labor library is where you store both.

If you don't know what to set, $50–$75/hour is a defensible starting range for production work done by a jeweler with 5+ years of experience. Below $40/hour, you're subsidizing your customers. Above $100/hour, you should have a clear reason: niche skill, signature technique, repair specialty.

How granular should the library be?

The labor library can hold one entry per piece-type ("Production - pendant, 90 min") or twenty entries that break out every step (sawing, filing, soldering, setting, polishing, finishing). Both work. The right level of detail depends on what you want to learn from your own data.

• Broad: one labor line per piece-type. Fast to enter. Accurate enough if your process is consistent and your intuition for "a ring like this takes me ~90 minutes" is good. The cost: every piece's labor is one bucket. You can't answer "where is my time actually going?"
• Granular: per-step entries. More setup time per item. Lets you spot inefficiencies, charge different rates for different operations (stone setting vs. bench sawing), and explain why one ring costs more than another. Worth it when you want to analyze your process, not just price it.

Start broad. Migrate to granular when you care. There's no cost to changing your approach later. The engine doesn't care whether labor is one line or eight.

Generic vs. item-specific entries

A separate axis from "how many steps." Should each labor entry be reusable across pieces, or specific to one item?

• Generic, reusable ("Polish & finish"). Stamp across many pieces. Fast, consistent. Good for steps that genuinely don't vary.
• Item-specific ("Hand-set 3mm sapphire in bezel, custom fit"). Describes exactly what happened. Useful for cost reports and wholesale justification ("here's why this ring costs more than that one"). Doesn't reuse.
• Mix: generic for the 80% of labor that doesn't vary (polishing, finishing, basic assembly), item-specific for the 20% that does (stone setting, custom fabrication, engraving).

The recommendation: default to generic, go specific when the labor meaningfully changes the price. If swapping a generic entry for a specific one wouldn't shift the retail by more than a few dollars, generic is fine. The labor library is designed for reuse, so use it.

Naming labor tasks so you can find them

A library that grows past about 20 entries gets hard to scan if names are inconsistent. A naming convention you can stick to is worth more than any specific format.

The labor table and the picker on a piece both show only the name and the vendor sub-label. Cost basis, hourly rate, and time aren't separate columns. If you want to tell a hand polish from a tumble polish at a glance, that has to live in the name.

Schema: [Operation] [Modifier when variants exist]

Lead with the operation. Add a modifier, separated by a dash, only when you have more than one variant of that operation. Single-variant operations get a bare name.

• Sawing
• Filing
• Soldering
• Engraving
• Polish - Hand
• Polish - Tumble
• Setting - Bezel
• Setting - Prong
• Setting - Pavé
• Casting Cleanup

Operation-first because that's how you think at the bench: "I need to do the setting work" gets you to every setting variant in one cluster. The modifier exists to disambiguate; skip it when there's only one kind of polish, soldering, etc.

Common naming slips

A few patterns that look fine on entry three and break by entry thirty.

Vague operations. "Bench work" or "Misc" tells you nothing in six months. The point of a library entry is to remember what the work was.

Time baked into the name. Time is a separate field. When a piece uses 45 min instead of the library default, the engine handles it without renaming anything.

Inconsistent separators. Pick one and use it everywhere. Mixing dashes, commas, and parentheses produces three different orderings in the table.

Vendor name in the entry name. Vendor is a structured field and shows in the picker as a sub-label. Repeating it in the name clutters the list without disambiguating.

The labor table is searchable, but a consistent name turns scanning into reading.

Where to go from here

• Pricing strategy: labor markup, the per-category markup table, and how the labor rate feeds the retail price.
• Materials: the parallel library, with its own naming conventions for material entries.
• Sales channels: why labor-heavy pieces are the most likely to lose money in wholesale, and what to do about it.