Jewelry Price Book: How to Set Org-Wide Gem Rates and Match Diamond Inventory

Ask five people on a jewelry team what a 1.5 carat, VS1, F-color round diamond should cost per carat, and you'll usually get five different numbers. One person is quoting from last quarter's memory. Another is guessing based on a supplier email from three weeks ago. That's the actual reason pricing goes sideways on custom orders, and it's exactly what a jewelry price book is built to fix.

If you've been pricing designs project by project in Diatech Studio, you already know the pain: someone enters a rate once, someone else enters a different rate for a nearly identical stone the next day, and now two client quotes for similar pieces don't match. A price book takes that whole guessing game off the table.

What a jewelry price book actually solves

The Price Book is an org-wide reference table for gem rates. Instead of every team member typing in per-carat prices from memory each time they price a design, admins set the rates once, and those rates automatically feed every AI pricing estimate across every project.

That's the real value here. It's not just a spreadsheet living in the app. It's the source of truth that Studio's AI pricing tool reads from when it looks at a design image and proposes a cost breakdown. Get the price book right, and every quote your team generates starts from the same numbers, whether it's the founder pricing a one-off commission or a junior designer running a batch of 40 SKUs.

Setting up your gem rate table

Admins can add rate rows for any combination of:

• Gem type (Natural Diamond, Lab Grown Diamond, Ruby, Sapphire, Emerald, Pearl, and others)
• Shape
• Color grade
• Clarity grade
• Cut grade
• Size range in millimeters

You can enter rows manually one at a time, which works fine if you're just getting started or making a small correction. But if you're setting this up for the first time, or updating rates after a market shift, the CSV import is the faster path. Download the template, fill in your rates, upload it, and preview the rows before anything gets saved. Nothing writes to the live table until you confirm it.

Changes also stay in a pending state with a visible "unsaved" indicator until you explicitly save. That matters more than it sounds like it should. Nobody wants a half-finished rate update accidentally going live because someone navigated away from the tab.

Why blank fields aren't a bug

Here's the part people usually miss the first time they set this up. You don't need a rate row for every single combination of gem type, shape, color, clarity, cut, and size. Leaving a field blank makes it a wildcard, meaning that rate applies across all values for that field.

So you could set one broad rate for "Natural Diamond, Round, no other filters" as a fallback, and then add a much more specific row for "Natural Diamond, Round, VS1, F color, Excellent cut, 1.5mm-2.0mm" that only applies to that narrower case. When Studio calculates a price, it always picks the most specific matching rule. The broad rate acts as a safety net, and the specific rates take over wherever you've bothered to define them.

This is the difference between a price book that's actually usable and one that requires you to manually enumerate hundreds of rows before it does anything useful. Start broad, then get specific where it actually changes the number.

Where AI pricing estimates plug in

Once your price book has rates in it, the "Estimate Pricing" tool inside any project reads the design image, identifies the visible metals and stones, and auto-populates a full cost breakdown using your organization's rates instead of some generic market average. That's a meaningfully different thing than a pricing tool trained on public data. It's pricing based on what you've told it your actual costs look like.

From there, the Pricing panel in the sidebar shows the line-item breakdown, and the Pricing Manager lets you edit any field or override the AI estimate manually. Once someone confirms a price by hand, that confirmed value gets used as context in future AI generations for that project, so iterative design refinements stay consistent with real, verified costs rather than drifting back toward an estimate.

Checking inventory before you quote

Pricing is only half the problem. The other half is knowing whether you can actually source the stone you just quoted. That's what the Diamond Inventory Matcher is for.

When a design's pricing includes diamond specs, the matcher checks your connected gem inventory against those specs, searching by shape, carat, color, clarity, and cut grade. It shows available carats, piece counts, and average price per carat, with a simple green or red status telling you whether there's enough inventory to fulfill the requirement.

This closes a loop that a lot of jewelry teams handle badly: quoting a client on a stone that turns out to be a six-week special order once someone actually checks the vault. Running the match before the quote goes out means you're not walking back a price or a delivery date after the fact.

Keeping the price book accurate over time

A price book isn't a set-it-and-forget-it thing, gem rates move with the market. The good news is that updating it doesn't mean re-entering everything. Use the CSV import again for bulk rate changes when metal or diamond prices shift, and the preview step will show you exactly what's about to change before you commit.

Non-admin team members can view the table but can't edit it, so there's no risk of someone accidentally overwriting a rate mid-quote. If your organization hasn't set any rates yet, non-admins are pointed to contact their admin rather than hitting a confusing empty state.

If your team has been going back and forth on pricing discrepancies, or you're tired of double-checking whether a stone is even in stock before you send a client a number, this is worth setting up properly. Head to the Price Book from your admin settings, import your current rate sheet, and let the AI pricing tool do the rest.