Intake and sales
- Customer enquiry
- Sales points
- Specification
- Assignment to managers
Executive summary
1. What the review found
A jewelry order is a long cycle with a high cost of error and a strongly invested customer. The piece takes weeks to make, is expensive, and is often made for a date. The customer remembers that date and asks about progress.
The review found that office, sales points, order managers and production work in separate streams. Orders are assigned by hand, status is chased through messages, and sketches, CAD files, estimates, invoices and the history of decisions are not gathered around one object. The order context has to be reassembled every time someone asks about it.
A separate problem is the promised date. It is quoted before the load on the production stages is known, so the deadline is a wish rather than a commitment — and cannot be checked until it arrives.
| Finding | Statement |
|---|---|
| Primary constraint | The order context — requirements, images, approvals and documents — is spread across communication channels rather than attached to the order. Answering the customer requires manual assembly. |
| Recommended first step | Build an order record: customer, piece, specification, sketch and CAD versions, estimates, invoices and history in one object. Then introduce a production route with owners and dates. |
| Expected effect | Fewer manual status requests, a verifiable promised date, a traceable link between the design version and the production order. Quantitative effect is assessed after rollout. |
Areas reviewed
Design and estimating
- Sketch
- CAD files
- Version approval
- Estimate and payment
Production
- Route across stages
- Bench workload
- Materials and stones
- Quality control
Customer and service
- Status for the customer
- Handover
- Repair
- History of the piece
Starting position
2. Baseline capture of current work
The review starts by capturing how an order travels today. For each operation we record who performs it, how often, which carrier holds the data, and whether the same data is moved again. Everything else in this document rests on this table.
| Operation | Who performs it | Frequency | Where the data lives | Re-keyed |
|---|---|---|---|---|
| Taking the customer enquiry | Sales point assistant or manager | Per enquiry | Messenger, email, paper form | Yes — requirements are rewritten when passed to the office |
| Assigning the order to a manager | Office lead | Per new order | Verbally or in a shared spreadsheet | Yes — manager workload is estimated from memory |
| Drafting the specification | Order manager | Per order | A separate document | Yes — parameters are moved out of the correspondence |
| Sketch and CAD | Designer | Per new piece | File storage, messenger | Yes — versions are forwarded and lose their numbering |
| Approval with the customer | Order manager | Several iterations | Correspondence | Yes — approval is recorded in words rather than as a mark |
| Estimate and invoice | Manager and bookkeeping | Per order | Separate accounting software | Yes — order contents are entered again |
| Handover to production | Order manager | Per confirmed order | Paper job sheet or message | Yes — the specification is copied onto the job sheet |
| Movement through stages | Bench jewellers | Several times per order | Workshop log | Yes — the status for the customer is compiled separately |
| Issuing materials and stones | Storekeeper | Per stage | Paper log | Yes — the booking happens after the event |
| Answering the customer about status | Order manager | Per request | A walk to the workshop, a call to the bench | Yes — the context is reassembled |
What follows from thisIn ten operations out of ten the data is moved again. The most expensive is the last: to tell a customer one sentence about progress, the manager physically walks to the workshop. That is not a communication problem — it follows from the order state not being recorded anywhere.
Diagnostic panel
3. State of the operational system
Losses occur between office, sales points and workshop — and between the date promised to the customer and the actual load in production.
47/100average process maturityManual reconciliation risk high
10points of re-keyingCandidates for removal
7critical data handoversNeed an owner
2priority pilot flowsOrder record + route
Process maturity
Expert assessment on a 0–100 scale. Higher means a more resilient process.
Structure of operational risk
Distribution of recorded observations by type.
16observations
40% — scattered data32% — losses at handover28% — unclear ownership
The numbers on this demonstration panel are illustrative. In a paid review the assessments are derived from interviews, a sample of orders, workshop observation and an agreed 0–100 scale.
Process map
4. Current process and handover points
The chain describes the typical route of an order for a new piece. A repair follows a shortened version of the same route. It is a process model, not a snapshot of any particular client system.
Enquiry
The customer describes the piece at a sales point or to the office.
Specification
Requirements, metal, stones, size and date.
Sketch and CAD
The designer prepares versions for approval.
Estimate
Price and deposit are confirmed by the customer.
Production
The order moves through stages with owners.
Quality control
The piece is checked before handover.
Handover
The customer receives the piece and the documents.
Repair
The request is linked to the original piece.
Risks at the handover points
| Handover | What can be lost | Consequence | Priority |
|---|---|---|---|
| Customer → sales point | Requirements, size, date, preferences on the stone | The specification is queried again and the deadline slips | High |
| Sales point → office | Images, what was agreed, the promised date | The manager starts the order with incomplete context | Critical |
| Designer → customer | Which sketch version is approved | The wrong version goes into production | Critical |
| Approval → production | The link between the approved version and the production order | The piece is made to an outdated specification | Critical |
| Production → store | Actual consumption of metal and stones | Retrospective booking, cost unknown | High |
| Stage → promised date | Actual bench workload and queue | The date is promised without regard to capacity | Critical |
| Handover → repair | History of the piece, materials used | The repair is done without data about the original | Medium |
Risk heatmap
| Area | Likelihood | Impact | Detection | Result |
|---|---|---|---|---|
| Design version not linked to the production order | Medium | Critical | At quality control | Critical |
| Date promised without regard to stage load | High | High | A few days before the date | Critical |
| Materials booked retrospectively | Medium | High | At stocktake | High |
| The customer chases status manually | High | Medium | Continuously | High |
| Order assigned without regard to manager workload | Medium | Medium | On a delayed reply | Medium |
Root causes
5. Why this happens
Slipping dates, rework and constant status requests share the same structural causes.
A. The order has no recordRequirements, images, approvals, estimates and invoices are held apart from the order — in correspondence, file storage and accounting software. The full context exists only in the manager’s head.
B. Approval is not versionedSketches and CAD files are forwarded as files rather than as versions carrying an approval mark. So the question "which version did we make it to" is settled by argument rather than by a record.
C. Load does not enter the promiseThe date is quoted to the customer before the queue at each stage is known. The production plan and the commercial promise are two independent facts that meet only when the date is missed.
D. The history of the piece stops at handoverA repair is not linked to the original order, so data on metal, stones and the bench that made it is re-collected on a second visit, or not collected at all.
Decision principleIn jewelry manufacturing what needs automating is not the workshop but the approval. The main losses sit before the first action at the bench: in the specification, the design version and the promised date. A workshop connected to an unresolved input simply produces scrap faster.
Responsibility zones
6. Who does what — and how much of it is moving data
An order travels through the office, the sales point and the workshop, and at every seam somebody reassembles its context. Below is where work is duplicated and where a role does not decide anything but moves data between channels.
| Role | What it does today | How much of that is moving data | Review observation |
|---|---|---|---|
| Sales point assistant | Taking the enquiry, advising, passing it to the office | Retelling the requirements to the office in their own words | The enquiry is captured in structured form on the spot; the role keeps the work with the customer |
| Office lead | Assigning orders, watching deadlines | Manual assignment based on remembered workload | Assignment becomes a rule based on load; the role keeps resolving exceptions |
| Order manager | Specification, approvals, invoices, answering the customer | A substantial share of the time is assembling context and walking to the workshop | Status comes from the route; the role keeps approvals and customer work |
| Designer | Sketch, CAD, revisions against comments | Forwarding versions and tracking which one is approved | Versions live on the order; the role keeps the design |
| Bench jeweller | Executing a stage, marking the workshop log | Keeping the log duplicates the order state | The stage is marked once; the role keeps making and quality |
| Storekeeper | Issuing metal and stones, keeping the log | The booking is made again and later than the event | Consumption is recorded at the moment of issue against a stage |
The organisational conclusion stays with the companyThe review shows which part of the work is moving data and which part is deciding. What happens with the time freed up — redistributing tasks, retraining people or changing the structure — is the owner’s call. In this kind of manufacturing the manager’s freed time usually goes into approvals and customer work, where it earns more.
Customer status is not a showcase, it is reliefA portal showing order status is often treated as an image feature. On the baseline it is the most loaded point in the process: answering "what is happening with my ring" requires a physical walk to the workshop. Showing the customer a safely filtered status removes less of the customer’s inconvenience than of the manager’s daily load.
Target operating model
7. States, boundaries and rules
The order passes through explicit states. Each defines an owner, the required data and the condition for moving on. The customer is shown a safe projection of these states, without internal information.
| State | Owner | Required information | Transition condition |
|---|---|---|---|
| Accepted | Sales point assistant or manager | Customer, type of piece, metal, stones, size, requested date | Specification complete across the required fields |
| Design | Designer | Sketch or CAD version with a number | Version sent to the customer for approval |
| Approved | Customer and manager | Approval mark against a specific version | The approved version is attached to the order |
| Estimated and paid | Order manager | Price, deposit, invoice | Payment confirmed, the date recalculated from load |
| In production | Bench jeweller for the stage | Stage, owner, actual material consumption | Stage closed with a timestamp |
| Quality control | Inspector | Conformity to the specification and the approved version | Check passed, or the order returned to a stage |
| Ready and handed over | Order manager | Documents, actual properties of the piece | The history of the piece is closed and available for repairs |
Boundaries of automation
The system should determine
- Which design version is approved and attached to the order
- Whether the date is realistic given the queue at each stage
- Whether the specification is complete enough to start production
- Who performs the next stage and how long it has already run
- Which materials and stones have been booked against the order
The system should not decide
- Whether to accept a piece that deviates from the specification
- Whether a repair is under warranty or chargeable
- Whether to grant a discount or deferred payment
- Whether to substitute an equivalent stone
- Which bench takes on a difficult stage
Rules, deadlines and escalation target
A rule without a deadline and an addressee does not work. Below is the minimum set that makes a stalled order visible before the customer asks about it.
| Rule | Deadline | Escalates to |
|---|---|---|
| An order does not go into production without an approved design version | At the moment of release | Blocking rule, no escalation needed |
| New order not assigned to a manager | 1 working day | Office lead |
| Version sent to the customer, no reply | 3 working days | Order manager, then office lead |
| Stage not started after the previous one closed | 2 working days | Production manager |
| Stage running longer than its standard time | The stage standard | Production manager, then management |
| Order returned by quality control to a previous stage | At the moment of return | Bench jeweller for the stage and production manager |
| Less than half a stage duration remains before the promised date | Automatic, by calculation | Order manager |
Priorities and sequence
8. What to do and in what order
The sequence is built so that each stage delivers value on its own and does not require the next one to be finished.
| No. | Recommendation | Why now | Acceptance criterion |
|---|---|---|---|
| 1 | The order record | Brings customer, piece, materials, images and documents into one object | Answering a question about an order needs no workshop walk and no search across channels |
| 2 | Versioned approval of sketch and CAD | Ends the argument about which version was made | A specific approved version with a timestamp is attached to the order |
| 3 | A production route across stages | Makes the age of an open stage visible | The order is traceable from acceptance to handover through closed stages |
| 4 | Load reflected in the promised date | Turns the deadline from a wish into a commitment | The date is computed from the queue at each stage rather than set by hand |
| 5 | Customer status | Takes daily progress requests off the manager | The customer sees approvals, payments and a safe status without the manager |
| Later | Automatic assignment and analysis of repeat enquiries | Useful once the route is stable | Order history is reliable across an agreed horizon |
Do not start with the workshopDigitising workshop logs before the approval process is in order produces an accurate record of misunderstood orders. Specification, version and date first; stages and materials second.
Rollout plan
These durations are indicative for a demonstration sample. A real estimate is formed after access to a sample of orders, the files, the stage standards and the integration constraints.
| Stage | Duration | Outcome | Checkpoint |
|---|---|---|---|
| Route capture and order model | 2–4 weeks | States, roles, required fields, stage standards, exceptions | Office and production approve the model |
| The order record | 4–6 weeks | One record with specification, files, estimates and history | The manager answers the customer without leaving the record |
| Approval and versions | 2–3 weeks | Sketch and CAD versions with an approval mark | Production starts only against an approved version |
| Route and load | 3–5 weeks | Stages, owners, queue, date calculation | The promised date is computed from load |
| Customer status and repair | 2–4 weeks | Status portal, history of the piece, repair linked to the original | Manual status requests stop being a daily occurrence |
Measuring the outcome
9. Metrics, reporting horizon and next step
This sample claims no numeric effect. In a real review the baseline is recorded first, then the metrics are compared after an agreed period of use.
| Metric | How it is calculated | How to capture the baseline | Direction |
|---|---|---|---|
| Share of orders with a complete specification at intake | Orders needing no clarification after intake / all orders × 100 | A sample of thirty orders from the correspondence | Up |
| Returns to a previous stage | Returns per period / orders per period | The workshop log for a quarter | Down |
| Variance against the promised date | Actual handover date − promised date, in days | A sample of orders over a quarter | Down |
| Age of an open stage | Mean time an order spends on a stage | Manual measurement across orders currently in work | Down |
| Manual status requests | Customer status enquiries per order | A count from the correspondence over two weeks | Down |
| Variance between estimated and actual material consumption | (Actual − estimate) / estimate × 100 per order | Stocktake against the issue log | Down |
Horizon: from the order to the annual report
A review does not end when the piece is handed over. Order data has to reach management and annual reporting without being entered again — otherwise profitability by product type stays unknown.
| Level | What must arrive without manual assembly |
|---|---|
| Day | Closed stages, quality control returns, materials issued |
| Week | Queue per stage, orders at risk of missing the date, bench workload |
| Month | Orders handed over, material consumption, payments and receivables |
| Quarter | Profitability by product type, share of repairs, causes of returns |
| Year | Management reporting across production and sales points on one data model |
If profitability by product type is unknown, the cause is usually not the bookkeeping but that actual material and time consumption is not tied to the order at the moment of the event.
Questions to settle before development
- What counts as the customer approving a design version?
- What standard times apply to each stage, and who sets them?
- Who may change the specification after production has started?
- Which order data may be shown to the customer, and which is internal?
- How are customer-supplied materials and stones accounted for?
- What data does the accounting software accept, and in what format?
Recommended next decisionCapture ten closed orders from enquiry to handover: correspondence, file versions, job sheets, material issue logs and actual stage dates. Output: a data model, stage standards, a role matrix and the pilot scope.
This document demonstrates the structure and level of detail of the deliverable of the “Process review” service. It is based on the mechanics of a delivered, anonymised platform for jewelry manufacturing, is not legal, tax, valuation or industry advice, and contains no confidential client information. Maturity scores are illustrative. Recommendations for a specific manufacturer depend on the capture, the jurisdiction, the contracts and the existing systems.