Two good systems that disagree about something
Vintrace is real winery software built by people who understand winemaking. It runs in hundreds of wineries and covers production thoroughly. If you are evaluating it, you are evaluating a serious product, and we are not going to pretend otherwise.
We win deals against Vintrace and we lose deals to them, and the pattern is consistent enough that we can usually tell you in advance which one you are.
The difference is not a feature checklist. It is a disagreement about whether software should define your process or reflect it. Vintrace mostly believes the first. We mostly believe the second. Almost everything below follows from that.
Structure and flexibility
Vintrace is a structured system. There is generally a defined way to accomplish a given task, the workflows are specific and numerous, and the system checks in as you go. Are you sure you want to do this. Confirm before proceeding.
Blended is more generalized. The workflows are broader, and there is usually more than one legitimate route to the same outcome. These are not workarounds or clever tricks. They exist because wineries do the same job differently, and we would rather the software bend than argue. We also almost never ask if you are sure. If you told the system to do something, we assume you meant it.
We are not arguing against structure. Process matters enormously in a winery. You should have a defined way of handling additions, a standard for what gets recorded at press, a clear chain for who approves what. Wineries that run on improvisation make expensive mistakes.
Our disagreement is narrower: what should enforce your process.
We think that is a human responsibility. It belongs to your winemaker, your cellar master, your SOPs, and the way you train people. Software should record what happened faithfully and show you clearly when something is off, so the people responsible can hold the line. It should not be the thing standing in the doorway.
Here is why. When software becomes the enforcer, three things happen.
The encoded process goes out of date. It reflects how you worked when it was configured, and your practice moves. Improving how you work becomes a request rather than just working differently.
People route around it. When the system will not let someone record what genuinely happened, they do not go find the correct sequence. They write it on a whiteboard and deal with it later. The process looks enforced while the data quietly stops being true.
And confirmation prompts stop being read. Ask often enough and the answer becomes reflex. What the prompt actually trains is clicking through warnings without looking, which is worse than never having warned at all. That is why we almost never ask.
You can absolutely run a tight, standardized operation on Blended. Set your standards, train to them, and use the system to see whether they are being followed. What you will not get is software that refuses to record reality because reality did not match the configured path.
If you want the software itself to be your forcing function, that is a legitimate preference and Vintrace is built for it. We are not, deliberately.
Data entry, and what it actually costs you
Vintrace asks for more. More fields, more required fields, more confirmations per action.
Blended asks for less. We keep required fields to a minimum and ask the fewest questions that still produce a correct, compliant record. That bar is not negotiable. Your TTB reporting has to be right, your audit trail has to hold up, and your record has to reflect what actually happened in the cellar. We are not trimming fields that matter. We are trimming the ones that do not.
That sounds like a matter of taste until you do the arithmetic.
Extra fields multiply clicks. Recording one addition might take four fields in one system and eleven in another, plus the tabs, dropdowns, and confirmations that come with them. Call it thirty seconds on a single task. Now run it through a real week: dozens of operations a day across dozens of lots. Additions, movements, analyses, topping, work orders. That overhead compounds into hours a month of somebody filling in forms rather than making wine, and harvest is worse, because volume peaks exactly when time is shortest.
Then there is what you stop recording altogether. Every hour spent satisfying required fields is an hour not spent capturing something that would inform a decision. We talk to wineries who have stopped entering analyses, never got to lot level costing, or let barrel detail lapse. Not because that information is unimportant, but because they were already at capacity keeping up with what the system demanded, and the valuable data was the part that was optional.
So they meticulously record the fields somebody made mandatory in a configuration meeting, and estimate the numbers that determine whether a lot is profitable. That is an expensive trade to make by accident.
And what does get recorded arrives late. When entry costs too much, crews stop recording things as they happen. Work goes on a whiteboard and gets typed up Thursday from memory. The record is not just thin, it is approximate, and nobody can tell you which parts.
Both failures share a source. Time spent on data entry is finite, and every field you add spends some of it. The question is not whether your system captures a lot of data. It is whether it captures the data that changes what you do.
What you get back when entry is cheap is a record that is current and complete. You can answer what a lot cost without reconstructing it. You can see analysis trends across a vintage because somebody actually entered the analyses. The value of winery software is almost entirely downstream of whether the record is accurate and current, and the surest way to guarantee it is neither is to make every entry expensive.
Lots and vessels
Blended is lot centric. The lot is the primary object, and vessels are simply where that lot happens to be sitting.
Vintrace is vessel centric. The vessel is the primary object, which means that to do something to a lot, the lot has to be in a vessel, and in the right one.
That requirement is the whole issue, and it shows up in three ways.
Everything has to be entered in the order it happened
If the system needs a lot in the correct vessel before it will let you record an action, your data entry has to follow real world chronology exactly. The problem is that information does not arrive in that order.
A lab result comes back three days late. Nobody logged the press because it happened at eleven at night during crush. A delivery needs recording, but the tank it is going into still shows the previous lot sitting in it.
Each of those leaves you two options in a vessel centric system, and both cost you. Wait until the missing earlier entries get made, which holds up everything behind them. Or unwind what has already been entered, redo it in the correct sequence, and re-enter everything that followed. This is the situation when things are busiest, which is exactly when you can least afford either one.
In Blended the lot exists independently of where it is sitting. Record the lab result when it arrives. Record the press when you get to it. The history assembles correctly without requiring perfect order.
Phantom tanks
The clearest evidence the model does not fit reality is that wineries invent tanks to get around it. Ask around and you will find them in a lot of vessel centric systems: a tank with an absurd capacity that exists nowhere on the property, there to absorb wine the system insists must be somewhere. Sometimes a lot is split across a dozen containers and nobody wants to model all of them. Sometimes nobody is certain where the wine actually is, and work cannot continue until somebody picks a location.
So someone fabricates a container, puts real wine in it, and moves on. Everyone knows it is fake, and it is now part of your permanent record. That is not a user problem. It is what happens when software demands information the person does not have.
In Blended none of that is necessary. If you do not want to assign a wine to a vessel right now, leave it in space. The lot exists, it has volume, it has history, and you can act on it. We are a software system, not a warehouse. We do not need a fictional tank to keep our bookkeeping happy.
Sometimes you want less vessel detail, not more
Sparkling producers raise this constantly. Once wine is in tirage, the specific bin is not information anybody acts on. Tracking it is administrative work that generates no decision, but a vessel centric model wants it because the vessel anchors everything else.
Lot centric means you carry the lot at whatever level of vessel fidelity is actually useful. Track barrels in detail where it matters, and stop tracking bins where it does not.
Finding your data
This is the difference people underestimate before they switch and talk about constantly afterward. It is also the thing we care most about.
Most winery software treats data like a vault. You spend years putting information in. It comes back out in two forms: a compliance filing, or a spreadsheet report you requested because you already knew exactly what you were looking for.
That is a narrow return on an enormous amount of work. Your team enters every addition, movement, analysis, barrel, and bottling run for years, and the way you get to use it is by knowing the precise question in advance, finding the corresponding report, running it, exporting it, and doing the actual thinking in Excel.
Notice what that rules out. It answers specific, tactical, anticipated questions. It does not support discovery, does not let you follow a hunch, and does not let one answer suggest the next, because every question costs a report and an afternoon. So people stop asking. They estimate, or go without, or promise themselves they will look into it after harvest and never do.
We think that is backwards and we are trying to change it. We will not claim we have finished the job, but the direction is deliberate.
Data should be live, dynamic, and useful in the moment you have the question. Not after a report request. Not after an export. In the moment, and cheap enough that being curious is not a decision you have to justify.
Verifying a number on your TTB return. You are reviewing your 5120.17 and the loss figure looks off. In a report driven system you generate a loss report for the period, export it, and reconcile it against the return line by line. In Blended you click the cell. It expands into the lots that produced the number, and you either find the error or confirm the figure, in seconds, without leaving the return.
Understanding cooperage in a blend. You want the barrel breakdown by cooper. In a report driven system you run a vessel report and reassemble the oak profile yourself, matching barrels to coopers and working out percentages by hand. In Blended that data already lives in a table you can group by cooper, and the percentages are simply there.
Neither is an exotic request. They are ordinary questions a winemaker has on an ordinary Tuesday. The difference is not whether the information exists in the system. It is whether getting to it costs thirty seconds or half a day, because that cost determines whether you ask at all.
Visuals do a lot of the work here. A number tells you what happened. A visual shows shape, outliers, and proportion, faster than reading, and it produces the next question. You see one lot sitting away from the others and want to know why. You notice one cooper is a larger share of a blend than expected and go look. That chain of one answer leading to a better question is most of what useful data actually is, and a static report ends it every time.
We have reports too. Compliance output has to be exact, repeatable, and defensible, and that will always be a report. But reports should be the floor, not the ceiling. When the everyday experience of using your data is open rather than gated behind a request, the same information you were already collecting becomes worth far more. You are not entering all of that just to file it.
Customer success
We have customer success here. What we do not have is a ticket system standing between you and it.
When you need us, you reach out to a real person you already know. Email, call, or text, whichever is easiest. They know who you are, they know your winery, they know how you are configured and what you were working on last time. You are not opening a case, you are not in a queue, and nobody is reading your account history for the first time while you wait.
That is deliberate. Support in software is usually treated as a cost center, something to be deflected, automated, and measured on how few interactions it takes to close a ticket. We think that is backwards for a system this operationally central. If our software is where your production lives, your ability to get a real answer is part of the product, not an expense attached to it.
It also means the conversation is not limited to what is broken. If something is unclear, tell us and we will run a training session. That is not an escalation or a paid add on, it is a normal thing to ask for. If something is not working well for you, that is an even better conversation, because there is usually another way to accomplish what you are after and talking through alternative workflows is a large part of what we do. And if the software genuinely should do something differently, that reaches the people who build it directly.
Everyone on our team is based in the US. We respond quickly, and during harvest that matters more than any other time of year. When something goes wrong at six in the morning on a crush pad, a same day response is not a response.
We are trying to be a partner rather than a vendor with a support address. Over time that compounds. The second year is easier than the first, because we are not starting from zero every conversation and we already understand why your process is the way it is.
Who should choose which
We would rather you get this right than get you into an implementation that does not fit.
Vintrace may be the better fit if:
- You want the software itself to enforce a single defined path, and you would rather have guardrails than latitude
- You need international or multi language operation
- You want production, distribution, and other beverage categories under one platform, which is what Encompass is built to provide
- You are already on Vintrace and it is working well. Migration costs real money and real time, and marginal improvement is not a reason to spend either.
Blended is likely the better fit if:
- Your team has a way of working they would rather keep than replace, and you want the software to reflect your process instead of dictating it
- Data entry is eating too much of your team's time, and the information you actually want is the part that never gets entered
- Mistakes and mismatches are generating rework. The cost is not the original entry, it is the unwinding, the re-entering, and the workarounds that stay in your data afterward.
- You want your data to answer questions, not just file reports. Clicking into a number, grouping a table, and knowing what a lot actually cost should be everyday things rather than projects.
- You want a partner who picks up the phone and is ready to dig in and help you get the most out of your system
If you are somewhere in the middle, the fastest way to find out is to look at it. We will tell you honestly if we are not the right fit, and we would rather do that on a first call than in month four.
Talk to us
Thirty minutes with the person who built the company. No qualification call before the real call.
.webp)