Winery Management Software: Fixing the Gap Between Cellar, Tasting Room, and Wine Club

Why winery management software makes or breaks a multi-site producer

A winery is four businesses stapled together: a manufacturer with an 18 to 36 month work-in-process cycle, a federally regulated excise filer, a hospitality operation, and a subscription commerce company. Almost nobody sells software that understands all four. So you end up with a stack. VinBalance or Vintrace or InnoVint for the cellar. Commerce7 or eCellar or WineDirect for DTC and club. ShipCompliant for state compliance and tax. Square or Toast in the tasting room if your DTC platform's POS (Point of Sale) is not good enough. QuickBooks or NetSuite underneath. Between each of those sits a spreadsheet and a person.

Here is the scene that repeats. Second week of the month, and your controller is building the TTB 5120.17 Report of Wine Premises Operations. Vintrace says you have 4,180 gallons of the 2023 Cabernet in tank 14. The bottling run log says you bottled 220 cases off it. Commerce7 says you sold 214 cases plus 9 that went out as club shipments plus 3 that a tasting room manager comped for a distributor visit and recorded as a $0 order. Somewhere in there, 40 gallons went to topping and 18 bottles went to the library, both recorded in a shared Google Sheet by a cellar hand who has since gone back to Argentina. Your controller spends two days reconciling. She does this every month. Price 24 days a year of your controller against her salary and it is real money, and that is only the visible cost. The invisible cost is that you cannot answer "what did the 2023 Cab actually cost us per bottle, landed, including the barrels and the two rackings and the tasting room pours" without another week of work.

The second scene: your club manager exports the April shipment list from Commerce7, runs it through a spreadsheet to strip out the members whose cards will fail, cross-references the states you cannot ship to this quarter, then manually adjusts about 140 allocations because Mrs. Kessler in Dallas gets two extra Reserve and the Napa restaurant group gets six. That spreadsheet is the allocation engine. It exists on one laptop.

Problem 1: Bulk wine and bottled goods live in two different universes

Vintrace and InnoVint are good at what they do: tank-to-tank movements, additions, work orders, barrel tracking, lot lineage. Commerce7 and WineDirect are good at what they do: SKUs, carts, subscriptions, fulfillment. Neither one owns the moment where 4,180 gallons becomes 1,760 bottles becomes 146 cases of SKU CAB23-750, minus the 22 bottles that go to library, minus the 14 that go to the lab and the sales team, minus breakage.

The off-the-shelf answer is a nightly sync that pushes a case count from the cellar system to the DTC system. That sync carries one number and no lineage. So when a club member calls in March 2027 and says her 2023 Cab is corked, you cannot walk backward from her order to the bottling run to the tank to the ferment lot in under an hour, and if you get a TTB audit or a recall question, you have a genuine problem.

A custom build gives you one ledger where the unit of account is a lot and a SKU is a view over lots. Every movement is an immutable event with a lot id, a volume or count, a reason code, and an actor. Bottling stops being a data entry event and becomes a transformation record that consumes gallons from lot X and emits N bottles with a bottling run id, a fill date, and a variance line. Comps, library pulls, samples, breakage, and staff pours each get their own reason code, because they hit your excise math differently and because "shrinkage" as one bucket tells you nothing. When you sell a case, the order line carries the bottling run id forward, so the path from Mrs. Kessler's order to tank 14 is one query. The 5120.17 stops being a reconciliation and becomes a report you run.

Problem 2: The club is where your revenue is, and the club software treats every member the same

Your club is the majority of your DTC revenue and it churns. Commerce7 will tell you a member cancelled. It will not tell you, in February, that this member is going to cancel in June, and that is the only information worth anything, because a save costs a phone call and a churn costs you the rest of that member's lifetime value. Compute that number from your own club history. It is never small.

The signals that predict a winery club churn are not in any one system. Months since last tasting room visit. Whether their last shipment was picked up or shipped. Whether they opened the shipment email. Whether the last two shipments contained a varietal they have never repurchased à la carte. Whether their card has soft-declined once. Whether their original signup was at a tasting room on a Saturday during a wedding or at a Tuesday seated tasting. That last one matters enormously and nobody tracks it. In the club data we have modeled, wedding-adjacent signups churn far faster than seated-tasting signups, and if you know which of your Q2 cohort came from which, you know where to spend your club manager's Tuesday.

A custom build gives you a member record that unifies POS visits, club shipments, e-commerce orders, email engagement, and reservation history into one timeline, plus a churn score trained on your own cancellation history rather than a vendor's generic one. It surfaces a work queue: 30 members this week, ranked, each with the reason ("no visit in 14 months, last shipment shipped not picked up, declined once in January"). Then AI does real work: draft the outreach in your club manager's voice, referencing the specific bottles that member has bought and loved, so a person sends 30 personal notes in 40 minutes instead of 30 templated ones in the same time. The model drafts. The club manager sends.

Problem 3: Compliance is a tax you pay in labor, and it should be a background process

ShipCompliant is the incumbent and it is good at what it does: it checks a DTC order against state rules, calculates the tax, and files the returns. It costs real money and it is worth it. ShipCompliant is not the problem. Everything upstream of it is.

Volume limits are the classic one. Texas caps how much a single household can receive from you annually. Ohio has its own cap. Your club plus your à la carte plus your library releases plus the case that customer bought in the tasting room and asked you to ship all count against the same household. If those four transactions live in four systems with four different customer records, and one of them spells her name "Kathy Kessler" and another "Katherine Kessler-Ruiz," you will blow the limit and not know until a state audit or a carrier rejection. Meanwhile your COLA label approvals, your state brand registrations, and your distributor price postings live in a shared drive with filenames like "FINAL_v3_use_this_one.pdf."

A custom build treats household identity resolution as a first-class feature, matching on address plus payment fingerprint plus fuzzy name, so a household is a household regardless of which channel the order came through. A volume ledger per household per state that every channel writes to before an order is accepted means the tasting room POS refuses the sale in real time rather than the compliance team catching it three weeks later. And a document layer where AI earns its keep: drop a COLA approval or a state brand registration PDF in, and extraction pulls the brand name, fanciful name, TTB ID, approval date, expiry, and the states it covers, then wires it to the SKU and starts a renewal clock. Nobody types that in. Renewals stop being something you remember in a panic.

Problem 4: The tasting room is a second business and your POS thinks it is a wine shop

At two or more tasting rooms, the operational reality is seated tastings with reservations, a walk-up bar, a private group in the barrel room, and a wedding on Saturday. Tock or Toast handles reservations. Commerce7 POS or Square handles the transaction. Your club signup happens on an iPad. These do not talk, so the single most valuable number in your business, revenue per visitor and club conversion rate per host, is not computable without a spreadsheet.

Off-the-shelf cannot fix this because Tock does not know what the guest bought and Commerce7 does not know how long they sat or who poured. The thing you actually need to manage, host performance, is invisible. Suppose Marisol converts 22 percent of her seated tastings to club and Daniel converts 9 percent. That gap is worth six figures a year and you should know it by Monday rather than by intuition.

A custom build keys reservation, visit, pour, transaction, and signup to one visit record with a host attribution. Now you get a real dashboard: conversion by host, by tasting flight, by day of week, by source. You find out that the seated flight converts to club at several times the rate of the walk-up bar and you stop optimizing for bar throughput. AI helps at the edges: an after-hours booking agent on your site and phone that handles the "do you have a table for four on Saturday" calls your tasting room misses between 5pm and 10am, checks real availability, and books. For a winery doing 30,000 visitors a year, the after-hours leak is measurable.

Problem 5: Nobody knows what a bottle actually costs

Ask your CFO what the 2023 Cab costs per bottle. You will get a number from a spreadsheet that allocated fruit cost, some barrel depreciation, and a guess at overhead. What it will not include accurately: the topping losses, the second racking labor, the 6 percent of that lot that went out as tasting room pours and comps, or the true cost of the two months the lot sat in a rented tank in Sonoma.

QuickBooks cannot do this because it has no concept of a wine lot. Vintrace tracks the operations but not the money against them. NetSuite can do it in theory, if you spend a full implementation budget configuring it and hire someone whose job is NetSuite, and at that point you have built custom software with worse ergonomics and a permanent license fee.

A custom build accrues cost to the lot at every event. Fruit contract cost at intake. Labor at each work order, pulled from the same work orders your cellar team already logs. Barrel cost amortized per lot per month of occupancy. Glass and dry goods at bottling. Non-revenue depletions charged back to marketing or hospitality rather than hidden in COGS. Per-bottle cost becomes a query rather than a project, and your release pricing conversation is grounded. This is the feature CFOs cite most often when the build gets justified to a board.

What this costs and how long it takes

Across 2,000-plus projects, our delivery pattern for this category holds: a focused first release runs $60k to $130k and ships in 12 to 16 weeks. For a winery, the right first release is almost always one of two things. Either the lot-to-bottle ledger with the 5120.17 and household volume compliance on top, or the unified customer and club engine with allocation and churn scoring. Pick the one currently costing you the most in labor and risk. A full platform covering cellar, cost accounting, compliance, DTC, club, and tasting room runs $150k to $400k phased over 6 to 12 months.

What pushes price up in this category. First, migration off Commerce7 or WineDirect with 15 years of order history and duplicate customer records: identity resolution on a messy 60,000-record customer base is real work, budget 3 to 5 weeks. Second, keeping Vintrace or InnoVint in place and syncing bidirectionally rather than replacing it, which is usually the right call and is harder than replacing it, because their APIs vary in quality and you need a conflict resolution policy. Third, every additional state you ship to adds rule surface, though you should keep ShipCompliant for the actual tax filing and integrate rather than rebuild that. Fourth, multi-entity: if you run three brands under two bonded premises with a custom crush client, the ledger model gets meaningfully more complex. Fifth, and people underestimate this one, offline-tolerant POS. Your tasting room is in a valley and the internet drops. If the POS cannot take a card and enforce a volume limit while offline, it is not a POS.

Build versus buy: where the line actually sits

Buy. If you make under 8,000 cases, run one tasting room, ship to under a dozen states, and your club is under 800 members, Commerce7 plus Vintrace plus ShipCompliant is a good stack and a build is a vanity project. The vendors have solved your problems and their per-order fees are cheaper than your engineering. Do not build. Spend the money on fruit.

Build. The signals are concrete and you probably have three of them already. A named person spends more than 20 hours a month reconciling between systems. Your allocation logic lives in a spreadsheet only one person can run. You have paid a state penalty or eaten a carrier rejection because a volume limit was blown across channels. Your DTC platform's percentage-of-revenue or per-order fees are now above $80k a year, which at scale is a build every 18 months, forever. Or the decisive one: you tried to answer a board question about per-bottle margin by vintage and it took two weeks.

The position I will take: at high volume, the club and customer layer is where custom pays first and hardest, not the cellar. Vintrace is good and you should keep it. Commerce7 is a good storefront and a poor system of record for a business where a customer is a household with a 20-year relationship, a compliance ceiling, and a taste profile. Build the customer and lot ledger. Integrate the rest.

How to choose a developer for winery management software

Ask them to model bulk-to-bottle on a whiteboard before you sign anything. If they draw a products table with a quantity column, they have never seen a winery. The right answer involves lots, transformation events, and variance. This one question eliminates most firms in ten minutes.

Ask what they will do about ShipCompliant, Vintrace, and your accounting system. The correct answer is integrate rather than replace. A developer who wants to rebuild compliance tax tables from scratch is either naive or padding. Ask specifically whether they have handled a bidirectional sync with a cellar system and what their conflict resolution policy is when both sides changed the same lot.

Ask them to explain the difference between the 5120.17 and the 5000.24 and what a bonded premise transfer in bond means. You are not testing trivia. You are testing whether they will need you to teach them your regulatory model on your dollar for the first six weeks.

Ask who owns the code, the repository, and the deployment on day one, in writing. You should own all three from the first commit, hosted in your organization, with your team having admin. If a firm hedges on this, the software is a subscription with a build fee attached, and you already have enough of those.