Werkbank

Order routing for furniture shops that run their own workshops. The shop owner types a customer request the way they would write a job slip. Werkbank sends it to the right workshop (carpentry, upholstery, polish and paint, metalwork), labels it with a job type, urgency and effort, and reports how confident it is. Requests it is not sure about wait in a review queue instead of going to the wrong bench. Every correction the owner makes retrains that shop's model.

Live demo: https://werkbank-gamma.vercel.app. Click Open the demo shop; no sign-up needed. The demo shop is fictional.

English and German UI, a quiet design on a warm wood palette, and a phone-first view for workshop staff.

Why this exists

The project started from a real client brief: a furniture retailer with three in-house workshops wanted orders to reach the right workshop automatically, with each workshop seeing only its own jobs. Werkbank generalises that brief into a multi-tenant product any shop can sign up for.

Existing tools in this space are manufacturing ERPs built for cabinet and joinery shops: cut lists, CNC output and job costing, priced around $50–$200 a month. None of them read a free-text repair request and decide which in-house workshop should take it. That gap is what Werkbank fills.

What it does

Owner	Workshop staff
Signs in with Google	Username and password, created and reset by the owner
Live preview of the routing while typing an order	Own login that only shows that workshop's orders
One board for all workshops, overdue orders highlighted	Urgent jobs first, then sorted by due date
Review queue for low-confidence orders, with the model's best guess	Three tabs and big buttons: Start, Mark done, plus an expected finish date
Reassigning an order teaches the shop's model	The board refreshes itself every few seconds
Splits one order across two workshops that work in parallel	Sees and updates only its own part of a split order
Reports: open, overdue, done and turnaround per workshop; monthly volume; CSV export
Router strictness (strict, balanced, relaxed) and plan selection

The whole interface is available in English and German. It installs as an app on phone and desktop (PWA), and all data is stored server-side in Postgres. Pricing is either a subscription (Starter €29/month, Pro €59/month) or a one-time licence (€790). Payments are not connected in this build: picking a plan only records it on the account.

How the routing works

flowchart LR
  A[Order text] --> B[Keyword layer<br/>EN + DE cue lexicon]
  A --> C[Naive Bayes<br/>seed model + this shop's corrections]
  B --> D{Blend + gate}
  C --> D
  D -- "conf ≥ 0.85, margin ≥ 0.5" --> E[Auto-route]
  D -- "conf ≥ 0.55" --> F[Route + flag 'check']
  D -- "low / layers disagree / unfamiliar words" --> G[Review queue]
  G -- "optional, ANTHROPIC_API_KEY" --> H[LLM must quote the request<br/>verbatim or its answer is discarded]
  G --> I[Owner assigns] --> J[(corrections)] --> C

• Capabilities, not workshop names. The model predicts one of four canonical capabilities. Each shop maps its own workshops onto them ("Polsterei" handles upholstery), so one model serves every shop.
• Cheap layers first. A weighted cue lexicon and a multinomial naive Bayes model run in under a millisecond. Naive Bayes was chosen because it updates incrementally: one correction just adds counts, with no training job.
• Calibrated confidence. Naive Bayes is notoriously over-confident. Its log-probabilities are tempered by a temperature fitted on held-out phrasings (scripts/train.ts). The UI never shows more than "99%+".
• Refuses to guess. The order goes to review if the request has almost no recognised words, if the keyword layer and the model strongly disagree, if the margin is thin, or if the shop has no workshop for the predicted capability.
• The LLM gets the residue only. It is called only for orders already in review. It must return a quote from the request, and if the quote is not literally in the text, its answer is thrown away. An LLM decision is never marked as fully automatic.
• Every decision is explainable. The order page shows the probabilities, the words that decided it, the gate, and a history of every routing and status change.
• Second-level labels. Job type (repair, custom, refurbish, assembly) comes from a second naive Bayes model. Urgency and effort are rules, because they depend on a few explicit words and the due date, and a shop owner can read a rule. "No rush" is handled before "rush".

Evaluation

There is no public dataset of furniture-shop job tickets, so the seed model trains on synthetic requests (scripts/generate-data.ts). To keep the numbers honest:

• the test set uses sentence templates and item and problem synonyms that never appear in training;
• a separate set of 60 hand-written messy requests (English, German, some deliberately vague) is used only for testing;
• gate thresholds were fixed before looking at test results. Searching for them on validation data collapsed to the minimum, so the search was dropped (the reason is noted in scripts/train.ts).

Results (full report: reports/eval.md, re-run with npm run eval):

Test set	Auto-routed	Auto accuracy	Sent to review	Accuracy of all routed
Synthetic, unseen phrasing (n=800)	18.9%	95.4%	36.1%	84.0%
Hand-written (n=60)	40.0%	95.8%	23.3%	93.5%

The feedback loop is the point. A shop whose staff phrase things differently corrects its first k orders; the model is then measured on 400 later orders:

Corrections	Top-1 accuracy	Auto-routed	Auto accuracy	Review queue
0	75.5%	20.8%	97.6%	34.8%
50	92.0%	63.7%	99.2%	12.5%
100	96.8%	82.5%	99.7%	6.3%

This is the beginning of the README. Read the rest at the original. Read the full README ↗