The system, by module
Three modules.
You buy the ones you run on.
Produccion is the record of what you grew, made and sold. Hospitalidad is every booking from every channel in one calendar. Restaurante is the point of sale, from the waiter's phone to the cash cut. Each one is a whole system on its own, and each one is sized to the operation in front of it.
Built to hold water
Every module has a published entry price, setup and monthly, and the combination and annual rules are stated as the policy they are. They all live on the pricing page.
Produccion
The record of the harvest, the cellar and the sale
The vintage is real and the record of it is not.
Weights arrive on a phone, lab results live in a notebook, tank movements are remembered rather than written, and the commercial side sits in a different file again. By the time anyone asks how this year compares with the last three, the answer has to be rebuilt from memory and from four exports that disagree.
Produccion is the winery's own record of what it grew, made and sold, dated and attributed, with the comparison, the report and the assistant built on top of it. One record, and every question answered from it.
What is built, by size
- Production record: schema, ingestion for the first two sources, and the core views, weights, lots, tanks, lab, barrel and bottling, dated and attributed
- Vintage comparison: any measure plotted against days post-veraison, this year beside prior years
- Commercial record: tasting room visits, club members, direct sales and distributor orders, next to production
- Historical vintage load: one prior vintage brought in from digital sources the winery already holds
- Monthly report generator: the plain-Spanish monthly report built from live data, with a delta section
- The assistant: grounded question answering over your own records, with an audit log and a refusal when the record does not hold the answer
- Training and handover pack: role-scoped Spanish documentation, recorded walkthroughs, credential handover and a competence check
- Two more data source connectors, each mapped and validated
- A second historical vintage
- A third extra data source connector, for five or more sources in total
- Prior vintages up to four seasons back
- A prediction or classification model tuned to house standards, harvest readiness or quality
- Finance workflow automation on your reporting
- An existing ERP integrated into the data-system features
- More than one production site
The sizes
Size is set per module, so an operation can be M on one and S on another.
- S
- One production site, one brand, one or two data sources, no more than about 20 lots. For a grower: one ranch, one or two sources, up to about 30 blocks.
- M
- Several lots and varietals, the tasting room and direct sales in the record, three or four data sources, an existing site that needs real changes. For a grower: two or three ranches, three or four sources, deliveries to more than one buyer.
- L
- Multi-origin, five or more data sources, a model and finance workflow automation.
Who it is for
Winemakers and grape growers. A grower gets a different feature set at the same rates, built around blocks, applications, irrigation and deliveries to buyers instead of tanks, barrels and a bottling line. It is another set of features, not a cut-down one.
- Vineyard block record: blocks, varietals, rootstock, planting dates and area, with every field event dated and attributed
- Maturity and phenology curve: sampling results plotted against days from budbreak, this season beside prior seasons
- Delivery and buyer record: loads by block and buyer, weights, sugar and pH at reception, price terms and payment status
- Applications and compliance log: sprays and doses, pre-harvest intervals, who applied, the evidence a certification audit asks for
- Irrigation and water register: irrigation events and water use, captured by hand when no controller exposes data
- Historical season load: one prior season brought in from digital sources the grower already holds
- The report generator, the assistant, and the training and handover pack, the same as the cellar set
A weather station or an irrigation controller is read as a data source when it already exposes its data. When it does not, the register is kept by hand. We do not buy, install, own or warrant hardware, and no quote carries a device that was not checked at the Diagnostico.
On Produccion we organise data, control and automation. We do not build a winery's sales. There is no version of this module that carries a site, conversion tracking or an ads build; those attach to Hospitalidad and to Restaurante, which are the modules that sell a thing a guest books.
Hospitalidad
Every booking in one calendar, and the day the property works from
Four channels, four calendars, and one room.
The bookings land in as many places as there are channels, the arrivals for tomorrow are counted by hand, housekeeping is told by phone, the guest who came last season is a name somebody half remembers, and the revenue by channel is a spreadsheet rebuilt at the end of every month.
Hospitalidad puts every booking from every channel into one calendar, with the day view the property actually works from, the state of each unit, the guest kept between stays, and occupancy and revenue that reconcile. One calendar, and a day that is already counted when it starts.
What is built, by size
- Unit and stay record: units, stays and guests, the schema every other feature reads, dated and attributed
- Two channel feed connectors: each booking channel read into normalised stays, deduplicated, with a freshness stamp
- Master calendar: units by days, each stay coloured by channel, month navigation, usable on a phone
- Day view: arrivals, departures, units occupied tonight and cleanings pending, on one screen
- Unit status board and housekeeping phone view: unit states, cleaning tasks generated from departures, marked done from a phone
- Guest record: notes and stay history attached to the guest, kept between stays
- Occupancy and revenue by channel: nights sold over nights available, revenue by channel and month, with the count of stays still missing an amount shown
- Monthly report generator, the assistant, and the training and handover pack for host, housekeeping and admin
- A third channel feed connector
- Direct booking capture: an enquiry or booking path captured straight into the stay record and tracked
- Channel manager connector: replaces the read-only feeds, bringing guest names, amounts and webhooks with it
- A prior season loaded from channel exports the property already holds
- A fourth channel feed connector
- A second prior season loaded
- Tasting room and event booking capture: visits, tastings and events booked into the same record and tracked, from M
- Automated follow-up on direct bookings, repeat guests and the wine club, from M
- A brochure or booking site wired to the stay record and to tracking, in Spanish and English
- Conversion tracking and GA4, owned by you
- A Google Ads build at any size, with its monthly management from M
The sizes
- S
- Up to 6 units, up to 2 channels, one property, no channel manager.
- M
- 7 to 20 units, up to 3 channels, one or two properties, a channel manager or a direct booking path.
- L
- 21 to 40 units across more than one property, 4 or more channels, a channel manager, direct booking and ads.
- Above 40
- Not a client we take. A property that size has a property management system, a revenue manager and a procurement process, and it is better served by them. We say so in the Diagnostico rather than quoting work we would not do well.
Who it is for
Properties with rooms, cabins or casitas, from a six-unit house up to forty units across more than one property. A winery with rooms, a tasting room and events belongs here too: this is the module that owns bookings and guests.
How the channel read works, said plainly. At the entry build we read each channel's calendar, so guest names and amounts are captured by hand until a channel manager is contracted, and the count of stays still missing an amount is shown on the occupancy view rather than hidden. The system never writes back to a channel. The cleaning task is generated from the departure date, and who cleans is the property's own arrangement.
Restaurante
From the waiter's phone to the cash cut
The order is written twice and the night is counted at midnight.
The order goes on a pad, then onto a ticket, then into a till. The kitchen works from paper and shouting. A table waits for a bill that has to be added up by hand, and a split one waits longer. At close, the cash is counted against a number nobody can rebuild, and the comps and cancellations are whatever people remember.
Restaurante is the point of sale: the order is born on the waiter's phone, travels to the kitchen screen, is paid at the table with the bill split and the tip kept apart from the sale, and the day closes with a cut that reconciles. Written once, at the table, and counted as it happens.
What is built, by size
- Menu, categories and modifiers: the menu tree, modifier groups and prices, with 86 marked from any phone and gone from every phone at once
- Order taking on the waiter's phone: by table and by seat, grouped by course, line notes, live subtotal
- Send to kitchen and course firing: a line or a whole course sent, sent lines locked, the waiter fires the next course
- Kitchen screen: queue oldest first, capture time, elapsed minutes, table and waiter, colour and text thresholds, bump and recall, and a warning when it loses sync
- Table map and host screen: zones and real table shapes, covers, arrival time, occupancy minutes, state and turn time
- Checkout with split and tip: whole bill, by seat, evenly between several or by amount, with the tip stored apart from the sale
- Cash and card recorded by hand: works on day one with no third party, cash received and change, card written down as taken
- Invoice request capture: RFC, razon social, regimen fiscal, uso de CFDI and email captured on the ticket
- Cancellations and comps log: every one with its reason and who authorised it, listed one by one
- Daily summary and cash cut: sale by category, hour and waiter, covers, average ticket, tips, the ten best sellers, opening float, declared cash and the difference
- Monthly report generator, the assistant, and the training and handover pack for waiter, kitchen, host and admin
- Station split: bar, hot and cold queues, with an expediter view over all three
- Payment link and QR connector, on the restaurant's own provider account
- Table reservation seating: the day's reservations by hour, with a seat button that opens the table session
- The menu and prior sales loaded from an export the restaurant already holds
- Card payment reconciliation: the day's card sales matched to the provider's transaction report by our own reference, gross reported against the deposit net of commission and tax
- A brochure or booking site wired to the record and to tracking, in Spanish and English
- Conversion tracking and GA4, owned by you
- A Google Ads build at any size, with its monthly management from M
The sizes
- S
- Up to 12 tables, up to about 80 covers a day, one station, up to 4 phones and one kitchen screen.
- M
- 13 to 30 tables, up to about 200 covers a day, two or three stations, up to 10 phones and two screens.
- L
- 31 to 60 tables, above 200 covers a day, three or more stations plus an expediter, more than 10 phones and three or more screens.
- The tie-breaker
- Covers a day decides when the tables and the devices point at different sizes, because what the month costs to run tracks service volume rather than furniture.
Who it is for
Owner-run dining rooms, from a twelve-table room up to sixty tables and three or more stations. One branch: a group running several is not what this module is built for, at any size.
Payments and invoicing, stated exactly. Cash and a card recorded by hand work from day one, with no third party involved, because a restaurant that cannot write down that a table paid by card has not bought a point of sale. Where the restaurant has its own payment provider account and can issue its own credentials, a payment link and its QR at the table is a connector quoted on top, one per provider, and the bill turns paid only when an authenticated status query returns the completed state. The invoice request is captured on the ticket; the stamping is done by your own invoicing provider and we never imply otherwise.
What this module does not do
Named here rather than discovered later: guest self-service ordering by QR, ingredient inventory and recipe costing, our own CFDI stamping, physical card terminals, thermal ticket printing, happy-hour price rules, payroll and tip distribution, and more than one branch.
The demos run on a made-up brand, and each one opens with a single module switched on. Each button opens the live demo in a new tab.
One, two or three, and what the bridges add.
Buy the modules you run on. A bridge is only built when both of the modules it joins are bought, and it is quoted on top of the two.
- On its own
Produccion
The record of what you grew, made and sold, the vintage comparison, the monthly report and the assistant over your own cellar.
- On its own
Hospitalidad
Every channel in one calendar, the day view the property works from, the unit board, the guest kept between stays and revenue by channel.
- On its own
Restaurante
The order on the phone, the kitchen screen, the table map, the table paid with the bill split, and a day that closes with a cut.
- One system
Produccion and Hospitalidad
One system and one login for both, and the shared service base is priced once whichever modules you add it to. The tasting room, the events and the club are still booked in Hospitalidad, and those visits already sit in Produccion's own commercial record on its own.
- The bridge
Produccion and Restaurante
The house wine list reads live from the cellar by vintage and varietal, so what the dining room offers is what the cellar actually holds. It reads only: the cellar record stays the cellar's.
- The bridge
Hospitalidad and Restaurante
Charges from the restaurant post to the room, and a guest's table booking shows on their stay, so the host sees the guest and the stay sees the table.
- The bridge
All three
Both bridges at once, under one system: the guest arrives, books a table, charges dinner to the room and drinks a wine the cellar knows by vintage, while the tasting room visit still sits next to the season that produced it.
The service base is charged once whatever the mix, and a module added to a client we already serve is a smaller build than the same module bought alone, because the training, the assistant frame, the report and the environment are already standing.
The Growth Diagnostic
Which modules, at which size, is a question the Diagnostico answers before anyone quotes anything. Ten working days going through your data, your bookings, your floor and your numbers as one system. You get a written memo: what is true, what is broken and what is worth building first.
Free. No retainer, no obligation. If the memo shows work worth doing, we propose the build and you decide.