Capitolato Queue
What this mockup is modeling
Maurizio's EuroComponents_flussocommerciale_AI.pdf — 4 steps Capitolato → Descrittivo → Preventivo → Offerta. v1 system replaces Steps 1 + 2 only; Steps 3 + 4 stay manual (see Phase 3 + 4 screens off Handoff).
| Fit | Code | Project | Customer | Country / Lang | Docs · Pages | Units / Typ. | Received | Effort |
|---|---|---|---|---|---|---|---|---|
| / | ||||||||
| No capitolati match these filters. | ||||||||
Click a row to open. Esc closes any modal. placeholder keyboard navigation not wired.
Source documents
AI triage summary
Units check 15 per typology · 50 minimum total
| Typology | Units | Rule |
|---|---|---|
| ≥ 15 < 15 · drop? | ||
| Total | ≥ 50 no offer |
Rule is undocumented but sacred (call-notes.md:82–85). EUR 6K design cost per typology = uncompetitive below 15.
Country regulation profile
- ·
Rule tables maintained by Maurizio's ufficio tecnico. System applies; does not research.
Language flow
DeepL Pro hard-locked (round-trips Excel/Word with format preserved). Brand/model/SKU codes untranslated.
Confidence per row
Caveat — this mockup: the green / yellow / red chips on each row are hand-authored in the demo data to illustrate the UX. The real rule for what tips a field from green to yellow to red has not been defined yet — open architecture question for v1 build (likely Riccardo + Maurizio joint call).
Source linking
Each row carries a ⓘ DOC N · p.X chip pointing back to the document and page where the value was extracted. Clicking opens the source preview pane on the right. Per-typology quantity cells have their own chip when the count was read from a drawing.
DOC numbers are decoded in the legend banner under the classification strip (collapsible — click "Source documents").
Field grounding (where each value comes from)
- cited — value was extracted from a specific document + page (most row-level fields)
- inferred — value derived from context, no direct citation. Lower confidence by definition.
- default applied — EC internal standard used because the spec was silent (e.g. scarico, adduzione). UI affordance for this is not yet built; would render as a third state, neither flagged-missing nor fully cited.
Open decisions — questions for Maurizio
Nine questions Maurizio's input unlocks. Each shapes the v1 architecture. Even half-answers move the build forward.
B · Extraction — where does the AI pull info from?
- Posa when the client doesn't specify it. Audit of the 5 real descrittivi showed row 11 is empty for Brixton, Lucens, and 068-26 — the client never specified. When that happens, where do you look it up? Project briefing? RFP cover note? Inferred from the drawings? Phone call to the client? Or doesn't it always matter at the descrittivo stage?
- Brand vs Model. When the capitolato says only "lavabo Valdama," is Valdama the brand or the model? Do you have an internal convention to disambiguate, or does the preventivista decide case by case?
- Per-typology quantities. Counts like "75 of T01, 213 of T02" — read from the drawings, derived from the client's BoQ, or applied as a rule (e.g. "one fixture per bathroom × N bathrooms")? We need to know where the AI should read those numbers.
- Capitolato language. Capitolati arrive in IT / DE / FR / EN / SV / NO. Should the system (a) extract in the source language first and then translate into Italian, or (b) translate the document first and then extract? Matters most for technical specs where a nuance in wording can change the product.
C · Conflicts between multiple sources
- Capitolato vs drawing — same item, different specs. When the capitolato text and a pod drawing disagree on an item (e.g. the schedule says faucet model X, the accessible-bathroom drawing shows model Y), what's the current practice? Capitolato wins? Drawing wins? Do you flag back to the client? What would you want the system to do?
- Capitolato vs drawing — item in one but not the other. Different case: an item appears in the capitolato but in no drawing (or vice versa). What do you do today? Include it anyway? Flag it?
- Revision diff. When a client sends Rev 01 after you've already worked Rev 00, would you prefer the system (a) figure out what changed and re-process only those parts, preserving the judgments already made, or (b) re-extract everything from scratch every time?
D · Defaults + operational rules
- Fields with internal EC defaults. In Call 4 you cited scarico and adduzione as fields where you apply "nostro standard" when the capitolato is silent. What other fields do you regularly handle with an internal default? We need this to avoid the system raising false "missing field" alarms on them.
- Confidence rule (green / yellow / red). Each row in the mockup has a colored chip showing how confident the AI is. For now we've set them by hand to illustrate the UX. When we start building for real, what should tip a field from green to yellow to red? Number of text matches? Multi-way ambiguity? Missing citation? Your intuition here shapes the rule we design.
This list lives in the mockup itself so it's visible during pressure-test reviews instead of buried in call notes. Update as questions get answered.
Already resolved during the 2026-05-20 audit: structure detection (extract from xlsx row 18 directly — well-grounded in all 5 packages); section nav (real template is a flat 76-row list, no sidebar needed).
Confidenza per riga
Nota — questo mockup: i chip verde / giallo / rosso su ogni riga sono inseriti a mano nei dati demo per illustrare la UX. La regola reale che decide quando un campo passa da verde a giallo a rosso non è ancora definita — questione di architettura aperta per la build v1 (probabilmente call congiunta Riccardo + Maurizio).
Collegamento alla fonte
Ogni riga ha un chip ⓘ DOC N · p.X che punta al documento e alla pagina da cui è stato estratto il valore. Cliccando si apre il pannello di anteprima fonte sulla destra. Le celle quantità per tipologia hanno un chip dedicato quando il conteggio è stato letto da un disegno.
I numeri DOC sono decifrati nel banner di legenda sotto la striscia di classificazione (richiudibile — clicca "Source documents").
Origine del campo (da dove viene ogni valore)
- citato — il valore è stato estratto da un documento + pagina specifici (la maggior parte dei campi a livello riga)
- dedotto — valore derivato dal contesto, senza citazione diretta. Confidenza più bassa per definizione.
- default applicato — standard interno EC usato perché la specifica taceva (es. scarico, adduzione). Affordance UI non ancora costruita; verrebbe renderizzata come terzo stato, né mancante-segnalato né completamente citato.
Domande aperte — decisioni da prendere
Nove domande su cui ci serve il segnale di Maurizio per sbloccare la build v1. Anche risposte parziali fanno avanzare il lavoro.
B · Estrazione — da dove l'AI prende le info?
- Tipo di posa quando il cliente non la specifica. Guardando i 5 descrittivi reali, ho visto che in Brixton, Lucens e 068-26 la riga 11 ("Tipo di posa") è vuota — il cliente non l'ha indicata. Quando capita, dove vai a recuperare l'informazione? Brief di progetto, cover dell'RFP, deduzione dai disegni, telefonata al cliente? Oppure a livello di descrittivo non sempre serve specificarla?
- Brand vs Modello. Quando il capitolato dice solo "lavabo Valdama", Valdama è il brand o il modello? Avete una convenzione interna per disambiguare, o il preventivista lo decide caso per caso?
- Quantità per tipologia. I conteggi tipo "75 pezzi di T01, 213 di T02" vengono presi dai disegni, dal BoQ del cliente, o c'è una regola tipo "un elemento per bagno × N bagni"? Voglio capire da dove l'AI dovrebbe leggere quei numeri.
- Lingua del capitolato. I capitolati arrivano in italiano, tedesco, francese, inglese, svedese, norvegese. Quando il sistema gira, preferite che (a) estragga prima nella lingua originale e poi traduca in italiano, oppure (b) traduca prima il documento e poi estragga? Conta soprattutto per le specifiche tecniche dove la sfumatura della parola può cambiare il prodotto.
C · Conflitti tra fonti multiple
- Capitolato vs disegno — stesso elemento, specifiche diverse. Quando il capitolato testuale e un disegno di pod non concordano su un elemento (es. lo schedule dice rubinetto modello X, il disegno del bagno accessibile mostra modello Y), qual è la prassi oggi? Vince il capitolato? Vince il disegno? Lo segnalate al cliente per chiarimento? Cosa vorreste che il sistema facesse?
- Capitolato vs disegno — elemento in uno ma non nell'altro. Caso diverso: un elemento è presente nel capitolato ma non in nessun disegno (o viceversa). Cosa fate oggi? Lo includete comunque? Lo segnalate?
- Diff revisione. Quando un cliente vi manda Rev 01 dopo aver già lavorato il Rev 00, preferite che il sistema (a) capisca cosa è cambiato tra le due versioni e re-elabori solo quelle parti, preservando i giudizi già dati sul resto, oppure (b) re-estragga tutto da zero ogni volta?
D · Default e regole operative
- Campi con default EC interno. In Call 4 hai citato scarico e adduzione come campi dove applicate uno "standard nostro" quando il capitolato non specifica. Quali altri campi del descrittivo lavorate regolarmente con un default interno? Ci serve per evitare che il sistema vi segnali quei campi come "mancanti" quando in realtà avete già un default che applicate.
- Regola di confidenza (verde / giallo / rosso). Nel mockup ogni riga ha un'etichetta verde/giallo/rosso che indica quanto l'AI è sicura. Per ora le abbiamo messe a mano per illustrare la UX. Quando partiamo a costruire davvero, cosa dovrebbe far passare un campo da verde a giallo a rosso? Numero di match nel testo? Disambiguità multipla? Citazione mancante? Sentire la tua intuizione qui ci serve per disegnare la regola.
Questa lista vive dentro al mockup stesso, così è visibile durante le review di pressure-test invece di essere sepolta nelle call notes. Da aggiornare man mano che le domande trovano risposta.
Già chiuse durante l'audit 2026-05-20: rilevamento struttura (estrazione diretta da riga 18 — ben fondata in tutti i 5 pacchetti); nav sezioni (il template reale è una lista piatta di 76 righe, nessuna sidebar serve).
| L. | Fit | Action | Materiale (IT) | Cheaper alt. (EC) | Reg. | Note Aggiuntive | ||
|---|---|---|---|---|---|---|---|---|
|
|
default applied
|
—
|
Propose alt.
|
— |
Descrittivo ready for preventivista
| Output file | 40 cols × 76 rows · 3 typology columns |
| Cells confirmed | green · yellow (preventivista review) · red (flagged) |
| Language | Italian (preventivista working language) |
| Cheaper alternatives | proposed (Maurizio's "alternativa simile più economica") |
| Regulation profile | |
| Downstream | → Preventivista (Phase 3 split + 34% ricarico) → Commerciale (Phase 4 +Margine k) — out of v1 scope |
Capacity note
1 preventivista is the explicit bottleneck (call-notes.md:299). Today's pace: 2 / 4 descrittivi shipped to preventivista. Faster Phase 1+2 → more full quotes vs budget estimates → conversion lift.
⚑ rows flagged from Phase 2
Read each BO note, then Resolve the row — confirm AI's brand+model, pick a substitute, or add a missing line. All flagged rows must be cleared before pricing the split. Pings to BO / Ufficio Tecnico / Maurizio happen out-of-band; the preventivista owns resolution either way.
Resolve options: confirm AI's brand/model, pick a substitute, or add a missing line. Per Maurizio's Call 4 feedback (2026-05-19), there's no separate "escalate" path in the system — the preventivista owns the decision and pings BO / Ufficio Tecnico / commerciale out-of-band when needed.
Preventivo split — 11 sections
Today: ~3 hr per project · preventivista works in Excel template, saves as locked PDF
| # | Section | Price source | Cost |
|---|---|---|---|
| Σ | Cost basis (somma sezioni) | — | |
| +R | Ricarico standard +34% (preventivista margin · per flussocommerciale_AI.pdf) | Fixed | |
| = | Preventivo subtotal (to Backoffice + Commerciale for Phase 4) | Locked PDF |
What's manual here (and stays manual in v1):
- · Preventivista fills lighting / mirrors / faucets / sanitary brand+SKU by hand.
- · Scocca + struttura priced from EC's internal factory costs.
- · Database lookups for supplier prices (valid if updated within last 6 months).
- · If price stale → request supplier preventivo, type in manually.
- · Locks the file as PDF on save to prevent mid-pipeline edits.
Commercial discretion. "Carica il 3% / 5%" (call-notes.md). Stacked on top of preventivista's +34% ricarico. Final = cost × 1.34 × (1 + k/100). Direzione approves above 5%.
Mocked equivalent (what the v1 system would produce — Phase 4 manual)
| Tipologia | Unità | €/unità | Totale |
|---|---|---|---|
| Totale offerta | — |
Prezzo cost basis (somma sezioni preventivo): €
Ricarico preventivista (+34%): × 1,34
Margine commerciale (+%): ×
Cost × 1,34 × =
What's manual here (and stays manual in v1):
- · Commerciale picks Margine k (3–5% usual, 6%+ requires direzione approval).
- · Backoffice translates IT offerta back to client's original language with DeepL Pro.
- · Build final Word file → export as locked PDF.
- · Send to client via email (or via HubSpot, the existing flow).
- · Commerciale runs negotiation.
v1 stopping line is at Handoff.
Phases 3 and 4 above remain manual. v2 surfaces (Phase 3 split automation + Phase 4 final-offer generation) are scoped separately and not part of the v1 commercial agreement.
History
| Status | Code | Project | Customer | Country | Units | Last update | Reviewed by |
|---|---|---|---|---|---|---|---|
| No history matches. | |||||||
Real EC archive: ~240 RFQs / year, 3–4% conversion baseline, 40% fall back to "budget estimates". placeholder drill-down not wired.