Greenhouse and Nursery Software: Fixing Crop, Bench and Shrink Tracking at Scale

Why crop and inventory software makes or breaks a greenhouse operation

Every grower we have worked with has the same artifact somewhere: a whiteboard, a laminated bench map, or a workbook called something like AVAIL_MASTER_v7_FINAL_USE_THIS.xlsx. It is the real system of record. The software you paid for, whether that is SBI Software, Picas, MapsInfo, Agriware on Dynamics 365, or a nursery management package bolted onto QuickBooks, is where you type things afterward so the accountant has numbers.

The March scene that costs you most, and that nobody puts a line item on. Your head grower walks house 14, counts the 2 gallon hydrangea that are actually finishing, and finds 3,100 sellable where the system says 4,200. The gap is a mix of a January cold event, a botrytis pass in one bay, and 400 that got downgraded to seconds and were never written off. Meanwhile your account manager already sold 4,000 of them to a Home Depot program with a fill rate penalty. So you buy in 900 from a broker at $6.80 a unit against your $4.10 cost, or you short the order and eat the chargeback. Both outcomes hit the same P and L line and neither shows up as a software problem. It shows up as shrink.

Multiply that across 300 to 900 SKUs, two or three growing locations, and a season where most of your year's revenue lands in a 9 week window. The math on the workarounds is brutal: we see a crop manager spending 6 to 9 hours a week rebuilding availability by hand, an order desk that will not commit inventory because they do not trust the number, and a shrink figure you only discover at year end inventory count. We have seen operations at the $15M to $40M range carrying 11 to 18 percent unexplained shrink and having no way to attribute a single point of it to a cause, a house, or a decision.

Problem 1: availability is a guess, and everyone downstream knows it

The pain: your published availability list goes out Monday morning as a PDF or an Excel attachment. By Wednesday it is fiction. A rewholesaler pulls 600 units, a landscape contractor cancels, a grade change moves 800 from #1 to seconds, and none of that reaches the list until next Monday. So your sales team pads. They hold back 10 to 15 percent as a mental buffer, which means you finish the season with sellable inventory you never offered and it goes to the dump pile.

Why the off-the-shelf tool cannot fix it: SBI and Picas both model availability, but they model it as a periodic calculation against a crop plan, not as a live ledger. The projection assumes your ready dates and your shrink percentages are right. They are not, because the shrink percentage in the system is a number somebody typed in 2019. And the field data never arrives fast enough because the way you update it is a grower filling out a paper count sheet that gets keyed in by an office admin two days later.

What a custom build does differently: you build availability as an event-sourced ledger, not a stored number. Every event that changes sellable count writes a row: a count event from a mobile scan at the bench, a grade change, a spacing move, a pull for an order, a write-off with a cause code. Availability is the sum, computed live, with a confidence flag based on how stale the last physical count on that bench is. Then you give the head grower a phone, not a clipboard. He scans a bench tag, taps a count, picks a grade, done in 11 seconds. The order desk sees the change before he walks to the next bay. And you publish availability as a live feed with a token per customer, so your rewholesaler is looking at the same number your salesperson is looking at, instead of a PDF from Monday.

Problem 2: shrink is a year-end surprise with no cause attached

The pain: you know you lost product. You do not know where, when, or why. The finished goods count at year end says you are short 40,000 units against what the crop plan said you should have. Was it the cold night in February? The irrigation zone that failed? The variety that just does not finish in your climate? The crew that trashed a bay of tip-burned material without telling anyone? You cannot answer, so you cannot fix it, so next year you plant 12 percent extra of everything, which is its own $200,000 decision made blind.

Why the off-the-shelf tool cannot fix it: general inventory systems, and even most horticulture-specific ones, treat shrink as a single adjustment transaction. Quantity down 400, reason code "shrink." That is not data, that is a shrug. There is no place to attach the bench, the crop cycle week, the environmental context, or the person who made the call.

What a custom build does differently: make write-off a first class object with mandatory structure. Cause taxonomy that your growers actually use, not a generic list: cold damage, heat stress, disease pressure with pathogen field, irrigation failure, mechanical damage, grade-out, overgrown, customer reject. Tie every write-off to a location down to the bench or bay, a crop cycle, and a date. Then join it against the data you already collect and throw away: your Argus or Priva environmental logs, your irrigation controller runtime, your spray records. Now when 3,000 units of a variety die, you can see they all sat in bays 3 to 5 of house 14 during the week the vent motor stuck. That is a $12,000 repair decision you can now justify. We have seen this attribution alone move an operation from an unexplained 14 percent shrink to 9 percent explained shrink within one season, because half of it turns out to be three fixable things.

Problem 3: the bench map lives in the head grower's memory

The pain: your $22M nursery runs on one person knowing where everything is. He knows the Endless Summer moved from house 9 to the outside pad in April, that bay 2 of house 14 has the late crop, and that the tags on the north end are wrong. When he takes a week off in peak season, order fulfillment slows by 30 to 40 percent because the pick crew is walking around looking. When he retires, you have a genuine business continuity problem.

Why the off-the-shelf tool cannot fix it: MapsInfo and the mapping modules in the bigger systems do exist, but they were built around a static bench layout and a keyboard. Real growing is fluid. You space, you consolidate, you move outside, you jam a crop into whatever bay opened up. A system that requires a desk-bound user to record a move in a form will simply never be updated, which is why most nurseries who bought a mapping module stopped using it inside a season.

What a custom build does differently: model location as a hierarchy that matches your physical reality, site to house to bay to bench to lot, and make moves a two-scan operation on a phone. Scan the lot tag, scan the destination bench tag, quantity defaults to full lot, done. Support partial moves and splits, because that is what actually happens. Cache the whole map offline, because your greenhouses have concrete, steel, and wet plastic between the crew and the WiFi access point, and any system that requires connectivity at the bench will get abandoned in week two. Then the pick list generates in walk order, not SKU order, which alone cuts pick time per order by 20 to 35 percent in the operations we have measured.

Problem 4: order entry, allocation and the big box program are three different animals

The pain: you serve a garden center chain on a weekly program with an EDI 850, a landscape contractor who emails a takeoff spreadsheet, a rewholesaler who calls, and a store manager who texts your salesperson. Your system handles maybe one of those well. So orders get keyed twice, allocation happens in someone's head, and when you are short you find out at the loading dock at 4am.

Why the off-the-shelf tool cannot fix it: the big platforms handle the EDI path because that is who they built for, but they treat everything else as manual order entry. And the allocation logic is first come first served or a simple priority flag. That is not how you actually decide. You decide based on customer lifetime value, program penalties, whether this contractor pays on time, and whether the material will hold another week.

What a custom build does differently, and the part where AI stops being a demo: document extraction on the inbound side. Your contractor's plant takeoff arrives as a PDF exported from a landscape design tool, or a photo of a handwritten list, or an Excel file where the botanical names are misspelled and the sizes are written as "3g" and "#3" and "3 gal" in the same column. A model reads that, maps it against your SKU catalog including botanical synonyms and common misspellings, and produces a draft order with confidence scores. Your order desk reviews and confirms instead of typing. We see 15 to 25 minutes of keying per order collapse to 2 to 3 minutes of review. Second place it pays: after-hours quoting. A contractor emails a takeoff at 9pm in April. The system extracts it, checks live availability, and has a priced quote with substitution suggestions waiting when your salesperson opens their laptop at 6am, instead of that lead sitting until Thursday. Third: substitution intelligence. When you are short 400 of a variety, the system suggests what you have that is a real substitute based on your own historical acceptance data, which customer accepted which swap, not a generic similarity score.

On allocation, you build the rules engine to your actual policy, with a tiering model you configure, and a shortage workflow that fires when projected sellable drops below committed with enough lead time to buy in or call the customer. Not at 4am at the dock.

Problem 5: the crop plan and the reality never reconcile

The pain: you build next year's plan in a spreadsheet in August. Stick dates, pot up dates, ready dates, projected sellable. Then the season happens. Nobody ever goes back and compares plan to actual at the variety and week level, so next August you build the plan from the same spreadsheet with the same assumptions and the same wrong finish times.

Why the off-the-shelf tool cannot fix it: crop scheduling modules exist and they will compute a ready date from a stick date plus a duration. But the duration is a static input. Your actual finish time varies with degree days, light, and the specific bay. And the systems have no memory: they do not learn that this variety in your operation, at this pot size, in the west houses, consistently finishes 9 days later than the book says.

What a custom build does differently: close the loop. Every crop cycle records planned versus actual on stick date, pot up, first sale, ready date, and yield against stick count. Feed the environmental history from your climate controller against it. Then forecasting has something real to work with: a model that predicts ready week from stick date plus accumulated degree days plus house, trained on your own three to five years of history, not a generic table. That model is the piece almost nobody has, because it needs your data joined together, which is exactly what the off-the-shelf tools prevent. The output your grower cares about is simple: a ready date with a range, updated weekly, so sales knows whether to sell week 14 or week 16.

What this costs and how long it takes

These are our own delivery bands across 2,000+ projects, not market averages.

A focused first release, meaning one problem solved end to end, typically runs $60,000 to $130,000 and ships in 12 to 16 weeks. For a grower that is usually bench-level inventory with mobile counting, live availability, and structured shrink capture. That is the release that pays for itself fastest because it attacks the number you cannot currently see.

A full platform, meaning crop planning, availability, order management, allocation, pick and load, customer portal, and integrations, runs $150,000 to $400,000 phased over 6 to 12 months. Phased, always. Anybody quoting you a big bang go-live for a seasonal business is telling you they have not done this.

What drives price up specifically in this category. Multi-site with different physical models, a mix of greenhouse, field, and container yard, roughly adds 20 to 30 percent because your location hierarchy and your counting method both fork. EDI to the big boxes: Home Depot, Lowe's, and each regional garden center chain has its own spec, its own labeling and pallet requirements, and its own certification process, so budget $15,000 to $30,000 per trading partner and expect 6 to 10 weeks of calendar time you do not control. Offline mobile is not free, plan on 15 to 20 percent on top of a connected-only build, and it is not optional in a greenhouse. Integration to environmental control systems: Argus and Priva are workable, older or proprietary controllers may need a data broker in the middle. Phytosanitary and shipping compliance, meaning state nursery certificates, quarantine restrictions such as boxwood blight or sudden oak death, and interstate shipping documentation, adds real scope if you ship across state lines. And migrating a decade of crop history out of an SBI or Picas database is usually 3 to 5 weeks on its own, sometimes more if the data was maintained loosely.

The one that saves money: do not build accounting. Integrate to QuickBooks, Sage, or whatever you run. Nobody has ever been glad they built a general ledger.

Build versus buy: where we actually land

Buy, and stop reading, if you are a single-site operation under roughly 5 to 8 acres under cover, shipping under about $5M, with under 200 active SKUs and no EDI programs. SBI or Picas will hold you, and the reason your current system feels broken is probably process and data discipline, not the software. A custom build will not fix a nursery where nobody counts.

Build when three or more of these are true. You are running multi-site and the sites do not share a location model. Your unexplained shrink is above 10 percent and you have no mechanism to attribute it. You have two or more big box programs with fill rate penalties, which means availability accuracy is directly a cash line. Someone in your operation spends more than 5 hours a week rebuilding a number the system already claims to have. Your head grower's memory is a single point of failure with no backup. Or you have already paid for a module, mapping, scheduling, whatever, and your team stopped using it within a season, which is the clearest signal that the tool does not match how you actually grow.

Our position: the hybrid is usually the right answer and almost nobody proposes it because it is less profitable to sell. Keep your accounting where it is. Keep SBI or Picas as the financial and order backbone if it is working there. Build the grower-facing layer, mobile inventory, live availability, shrink attribution, on top of it and integrate. That is a $60,000 to $130,000 project, not a $400,000 one, and it attacks the part that is bleeding.

How to choose a developer for greenhouse and nursery software

Ask them to model your inventory on a whiteboard before they quote. Not screens, the data model. If they cannot articulate the difference between a crop, a lot, a location, and a sellable unit, and how a lot splits when you space it across two houses and half of it grades out, they are going to build you a retail inventory system with plant names in it. That is the single most expensive mistake in this category and it is fully detectable in a 90 minute conversation.

Make them explain their offline strategy in technical terms. Ask what happens when a grower scans 40 benches with no signal and two of those lots were also modified by the order desk. If the answer is not a specific conflict resolution policy, they have not built for a greenhouse. They have built for an office and will discover the concrete and the wet plastic during your peak season.

Ask what they have integrated to on both ends. Named systems: QuickBooks or Sage on the finance side, Argus or Priva on the environmental side, the specific EDI specs for whichever retail programs you run. "We can integrate with anything" means they have not done yours. Ask specifically about EDI 850, 856 and 810 flows and whether they have been through a retail partner certification, because that process is a calendar risk more than a technical one.

Check whether they understand your season is a cliff. Ask when they would freeze deploys. A vendor who is willing to push code in week 12 of a March to May season does not understand your business. The right answer is a hard change freeze through peak, heavy training in the slow months, and a go-live in your off-season with a full season of parallel running before you turn the old system off. And get code ownership and a database schema handover in the contract, in writing, before the first invoice.