Client Request
Email, xlsx or PDF requests become structured demand: client, product/EAN, quantity, deadline and priority.
CASE FILEAIRTABLE LOGISTICS OSAGENT-READY OPS
Savimpex
An Airtable Logistics OS that turns client requests, supplier offers, commercial proposals, purchase orders and shipments into one agent-ready operating system.
CLIENT: SAVIMPEX · INTERNATIONAL FREIGHT & PROCUREMENTSYSTEM: AIRTABLE LOGISTICS OS · CR / PRODUCTS / SO / CP / PO / SHIPMENTSDELIVERABLES: ENTITY MODEL · USER GUIDE · SETTING MODE · AI ROADMAPSTATUS: BONES BUILT · BRUTTO ROADMAP READYPLANNED SCALE: UP TO 1M RECORDS · 100 USERS Y1
Savimpex needed more than a cleaner database. The team needed one operating layer where client requests, product records, supplier offers, commercial proposals, purchase orders and physical shipments could move through controlled states. We designed the entity model, gates, repair paths and documentation dashboard first, so automation can attach to a system that already knows what good data looks like.
OPERATING SYSTEM MAP
From request to received goods
- 01Productscatalogue
- 02Source Offerssupplier pricing
- 03Client Proposalcommercial offer
- 04Purchase Orderconfirmed order
- 05Shipments IN/OUTphysical movement
- 06Closedreconciled delivery
Problem tabs / gates
Every risky transition has a visible check: missing products, invalid categories, DDP errors, quantity mismatches and shipment warnings stop before they spread.
BRUTTO agent hooks
The same stages expose safe attachment points for intake parsing, offer validation, proposal drafting, PO watching and shipment notifications.
Public view of the operational spine. Sensitive field names, margins, supplier data and internal admin procedures are intentionally abstracted.
REQUESTS · OFFERS · ORDERS · SHIPMENTS
The situation
The operational pain was not one broken tool. It was the absence of a trusted sequence. A request could arrive in any format, product records could drift, supplier offers could be stale, proposals depended on manual choices, and purchase orders or shipments were hard to control once the deal moved from sales to logistics.
Client requests arrived as email, spreadsheets or PDFs with no structured intake.
Products and Source Offers were the hidden foundation, but one invalid category could break downstream pricing.
Client Proposals depended on manual offer choice, finance parameters and file generation.
Purchase Orders and Shipments needed controlled status logic, not direct spreadsheet edits.
PROCESS TRANSFORMATION
Before & after
Before
Email → xlsx → manual lookup → stale offer → copied proposal → shipment tracker
Every handoff created another place for context to drift. Product lookup, offer freshness, proposal quantities and shipment progress lived across separate files and conversations.
WHY THE BONES CAME FIRST
Structure before agents
Automation is only safe when the operating system already defines canonical records, statuses, gates and repair paths. The first deliverable was the bones: an entity model and workflow discipline that makes later AI useful instead of dangerous.
- one canonical record per request, product, offer, proposal, order and shipment
- status transitions with explicit readiness checks, not colour-coded spreadsheet memory
- problem states that stop corrupted rows before they enter commercial decisions
- proposal and shipment workflows that can be assisted by agents without bypassing human approval
BACKGROUND DATA · DEAL EXECUTION
Two operating flows
Products → Source Offers
Background data preparation. The team keeps the product catalogue clean, loads supplier offers, validates categories, handles Problem views and makes pricing/DDP ready before a live client deal needs it.
Client Request → CP → PO → Shipments
Deal execution. A client request becomes a structured demand record, selected offers become a commercial proposal, confirmed quantities become a purchase order, and logistics closes through Shipment IN/OUT.
Merge point: Client Proposal. This is where live Source Offers become a client-facing commercial proposal, with one Actual offer per product and clear gates before PO creation.
ENTITY FLOW · CLICK TO EXPLORE
Operational pipeline
SELECT A STAGE TO SEE ROLE, SCREEN, GATE, FAILURE MODE AND BRUTTO HOOK
Client Request
Captures who is asking, which product/EAN or description they need, quantity, deadline, priority and comments before the team starts building an offer.
WHAT MUST BE TRUE BEFORE THE NEXT STEP
Control gates
CRCP
EAN matched and manager approval captured.
ProductsSO
Valid EAN/category and no blocking product problem.
SOCP
Offer valid, DDP calculated and validity window current.
CP DraftCP Sent
One Actual offer per EAN and finance checked.
CPPO
Qty Ordered and Qty Placed confirmed.
POShipments
PO Created and Placed qty greater than zero.
INOUT
Received stock available for client shipment.
OUTClosed
Received quantity reconciled and warnings handled.
PROOF OF OPERATING SYSTEM
System artifacts
Entity architecture
CR, Products, Source Offers/SOL, CP/CPL, PO/POL and Shipments mapped as one connected operating model.
Status model
Draft, Sent, PrePO, Active, Planned, In Transit, Received and Closed states define where work really is.
Role views
Procurement, commercial, logistics, management and admin surfaces let teams see their slice without forking the truth.
Documentation pack
User guide, entity docs, dashboard and Setting Mode turn the system into something people can operate and repair.
WHAT BREAKS · WHERE TO LOOK · HOW TO FIX
Setting Mode
The knowledge base does not only describe the happy path. It documents public-safe examples of failure modes, where operators notice them, and the repair logic that keeps the system trustworthy.
Product not found
- SIGNAL
- Source Offer cannot connect to a product record.
- REPAIR
- Create or correct the canonical product before using the offer in CP.
Invalid Category / DDP Error
- SIGNAL
- Pricing is missing, blocked or visibly abnormal.
- REPAIR
- Fix category and logistics inputs, then re-check the affected Source Offer rows.
Multiple or missing Actual offers
- SIGNAL
- CP file would include duplicated, missing or wrong product lines.
- REPAIR
- Keep exactly one Actual offer per EAN before the proposal moves forward.
Missing Qty Ordered / Qty Placed
- SIGNAL
- The next CP status or PO creation cannot proceed cleanly.
- REPAIR
- Confirm client order quantity and supplier placed quantity before Create PO.
PO edited directly
- SIGNAL
- Order records no longer match the proposal source.
- REPAIR
- Return the change to CP and update the order from the controlled source.
Q_OVER_SHIP / SHIPPED > LEFT
- SIGNAL
- Shipment quantities exceed placed or received stock.
- REPAIR
- Correct shipment quantities or update the order through CP before closing.
BRUTTO · AI ROADMAP READY
BRUTTO runs on the same bones
BRUTTO is the Savimpex operations bot layer. It is designed to attach to the existing Airtable OS, not replace it. The roadmap keeps humans in approval loops for commercial and customer-facing actions while agents handle parsing, validation, monitoring and drafts.
- same Airtable operational layer
- human-in-the-loop approvals
- confidence and audit logging
- no side spreadsheets
CR Parser + Product Matcher
Read inbound requests, extract structured demand and suggest product matches for review.
Product Validator + Deduplication
Catch invalid categories, duplicate EANs and catalogue health issues before offers depend on them.
Offer Extractor + DDP Health
Normalize supplier files and flag missing products, expired offers or pricing problems.
CP Builder + Letter Drafting
Prepare proposal drafts and client emails while keeping approval gates in place.
PO Watcher + Supplier Confirmation
Track supplier confirmations, quantity changes and action-needed order states.
Shipment Tracker + Customer Notifier
Monitor shipment events, surface delays and draft customer updates for review.
BONES · BOTS · SKIN
BnB layers on this build
BONES
Entity model, gates, statuses
CR, Products, SO, CP, PO and Shipments with problem tabs, readiness gates and controlled transitions.
BOTS
BRUTTO roadmap and attach points
Parser, validator, proposal, PO and shipment agents designed around the same operating system.
SKIN
Dashboard, guide and case visuals
User guide, entity documentation, Setting Mode and diagrams that make the system legible.
PROCESS DISCOVERY
What we mapped first
- how client requests enter the business and what fields must be captured before pricing
- where Products and Source Offers fail: missing EANs, categories, duplicates and pricing errors
- how CP moves from draft to sent proposal to PrePO and PO creation
- why PO should be an operating record created from CP, not an editable side spreadsheet
- how Shipment IN/OUT status and warnings should determine order closure
SYSTEM DELIVERABLES
What we built
- Airtable Logistics OS architecture from Client Request through Shipments
- entity documentation for CR, Products, Source Offers, CP, PO and Shipments
- unified dashboard and knowledge base for the operating system
- gates and problem-state logic for product, offer, proposal, order and shipment quality
- Setting Mode diagnostics for public-safe repair paths and failure handling
- BRUTTO AI roadmap with agent attach points across the same operational spine
WHAT THE SYSTEM CAN NOW HOLD
Structural proof
7connected operational stages from CR to Closed
2operating flows: background data and deal execution
8control gates protecting downstream work
1unified documentation dashboard for operators and roadmap work
From scattered operations to an operating system.Bones built. BRUTTO roadmap ready.A logistics workflow with a body, gates and repair paths.