Slab management software has a different job from a generic product catalogue. Two slabs from the same stone type can differ in dimensions, pattern, finish and condition. A buyer may reserve a particular piece after seeing a photo, while the yard team knows it by its physical position. I have built a system for slabs and blocks, and the central design challenge is to keep those commercial and physical identities aligned.
The model below is a practical way to scope stone operations. Exact units, cutting processes and sales terms belong to each business and need to be mapped before a build.
Give each physical item an identity
Start by deciding what the team sells and moves: an incoming block, a processed slab, a bundle of slabs or an individual selected piece. A block can become several slabs, so the relationship between parent material and resulting pieces should be recorded. That lineage helps the team answer which stock came from a particular block without relying on someone remembering the yard.
For each item, consider identifier, material or variety, dimensions, thickness, finish, condition, photos, current location, status and source. Define units clearly. Length, width, area, weight and saleable quantity are not interchangeable; conversion or pricing assumptions should be visible to the salesperson and reviewer. Measurements may change after processing, so preserve the measurement event and its date rather than silently replacing the original.
| Physical moment | Software question | Failure to test |
|---|---|---|
| Block received | What arrived and where is it stored? | Supplier label differs from yard label |
| Cutting or processing | Which slabs came from this block? | Output pieces lack lineage |
| Inspection | What condition and dimensions are approved? | Damage or measurement change is hidden |
| Customer selection | Which exact piece is being discussed? | Photo and stock record refer to different slabs |
| Reservation | Is the piece held, until when and for whom? | Two salespeople promise the same slab |
| Dispatch | What left the yard and what remains? | Record changes before physical handover |
Make the photograph part of the record
For visual products, a stock list without current imagery can be technically accurate and commercially useless. Photos should be tied to the specific item, with capture date and useful labels. The system should distinguish representative material photos from photos of the exact slab being offered. A customer should not interpret a sample pattern as a promise about a unique piece.
Image workflow needs ownership: who captures a new photo after cutting or polishing, who approves it for customer use, and what happens when a slab is sold or damaged? If photos are simply dropped in a shared folder, identification work returns to WhatsApp and phone calls. Privacy, storage cost and image quality should be scoped before promising instant media access everywhere.
Model reservation as a controlled state
“Available” should mean more than “not invoiced.” A slab may be in inspection, on hold for a customer, awaiting balance payment, or physically inaccessible. Define reservation expiry and who may override a hold. A salesperson should see both the status and the reason. That prevents a sale being confirmed against stock that looks free in one view but is committed in another.
When a reservation ends, record whether it was converted to an order, extended or released. Avoid automatically deleting the history. A release reason can explain why the same piece reappeared on the available list. For multi-yard operations, transfers need an in-transit state and a receiving confirmation, not a single location edit.
Separate operational measurement from commercial pricing
Pricing may depend on material, quality, finish, dimensions and negotiated terms. The software can calculate a proposal from approved inputs, but a quote still needs a visible rule and authority for overrides. A measurement correction after the customer selects a slab may require review before the quote is final. Do not let the interface hide this behind a recalculated total.
An effective screen for the sales team might prioritise a photo, exact identity, dimensions, available status, location and next action. A yard view might prioritise location, movement and inspection. These are different tasks; forcing both teams into one dense grid is often why a custom system feels difficult despite containing all the fields.
Pilot with one block and one difficult reservation
Before importing the whole yard, test one block from receipt through processing and sale, plus a slab that was photographed, reserved, released and re-reserved. Can the team trace every state change? Do the commercial and physical counts agree? Can a person unfamiliar with the transaction identify the exact piece from the record?
Useful measures are unidentified stock, reservations past expiry, items missing current photos, measurement corrections and dispatch mismatches. These are diagnostic signals, not a promised outcome. The site's broader warehouse software roadmap covers stock movement principles; a slab-and-block build adds unique-piece identity and visual selling. For a custom workflow discussion, bring one block record and the story of a slab that was hard to find or promise confidently.
Frequently asked questions
Can a generic inventory system manage slabs and blocks?
It can handle some stock movements, but unique-piece identity, block-to-slab lineage, changing measurements and photo-led selection may require custom fields or workflow. The choice is not automatically “build from scratch.” First test whether the existing product can preserve the identity and reservation rules without workarounds that put the real process back into spreadsheets.
What is the minimum useful pilot?
One material type, one yard area and a complete movement from block receipt to slab dispatch. Include a damaged piece and a reservation that expires. If staff can identify the exact slab, see its current location and explain its commercial status without asking the person who handled it last, the pilot is proving the right thing.
Automation Systems Architecture
For teams where leads, orders, operations, or reporting still depend on memory, WhatsApp nudges, and manual sheet updates.
