The harvest window everyone built the week around just moved. A block that was supposed to be ready Thursday needs a few more days of heat. Two of your regular pickers did not show, so the crew you planned for is short. A retailer pulled its order forward by a day, and the lot you were going to pack for it is sitting on a quality hold while the lab confirms a result. Sales still needs to tell that retailer what is coming and when. Production still needs to know what runs down the packing line tomorrow morning.
None of this is unusual. It is a normal week in a business that grows, packs, or makes food. The plan is not wrong because someone made a mistake. It is wrong because the world moved after the plan was written, and the plan had no way to move with it.
That is the real problem behind production and harvest planning, and it is why a spreadsheet rebuilt every Monday never quite fixes it. The spreadsheet is where the pressure becomes visible, but the pressure comes from somewhere else. Demand, supply, capacity, and quality all change on their own schedule, and the plan has to keep answering one question through all of it: what can we actually do this week, and what should we promise?
This guide is for the people who own that question. Production and harvest planners, operations managers, supply and demand planners, and the COOs and founders of grower-packers, fresh-produce businesses, and food manufacturers who work with agricultural inputs. It is written to be useful whether you run planning off a whiteboard, a shared sheet, an ERP module, or all three at once.
Pick one planning decision before you touch a system
The instinct when planning feels chaotic is to reach for a bigger system: a new forecasting tool, an ERP module nobody switched on, a scheduling platform someone demoed last quarter. That almost always makes things worse first, because you end up modeling everything and deciding nothing.
Start smaller. Pick the single planning decision that changes the most and costs the most when it is wrong. In most food and agriculture businesses it is one of these: what to harvest and in what order, what to pack on which line, what to hold, what to substitute when a lot fails grade, or what to promise a customer for the coming week. Each of those is a real decision someone already makes, usually under time pressure, often with incomplete information.
Choosing one decision does two useful things. It gives the work a finish line, so you can tell whether the planning actually got better. And it forces the honest question underneath all planning software: when this decision has to be made on Wednesday afternoon, what does the person making it need in front of them?
Planning is not the same as forecasting
Teams often buy a forecast when what they need is a plan, so it helps to keep the two apart. A forecast is a prediction about what demand or yield will be. A plan is a decision about what to do now that reality has changed. You can have an excellent forecast and still make poor weekly calls, because the forecast does not tell you which order to protect when a field comes in light or a line goes down.
A production and harvest planning workflow has to answer four questions every cycle, and fast enough that the answer still matters. Is the demand real, is the supply there, is capacity tight, and is the quality clear? Each question points at different data and a different owner, which is exactly why they are hard to see together.
| Question the plan must answer | What you are actually checking | Where the answer usually lives |
|---|---|---|
| Is the demand real? | Firm orders against forecast, customer priority, margin, and any order changes for the week. | Sales orders, CRM, forecast, retailer portals. |
| Is the supply there? | Field yield estimates, expected ready dates, inventory on hand, and shelf life. | Crop or farm management, grower updates, inventory, WMS. |
| Is capacity tight? | Confirmed labor, line hours, equipment, packaging, cold storage, and transport slots. | Scheduling, labor plan, maintenance, logistics bookings. |
| Is the quality clear? | Holds, grade results, certificates, and release rules. | Quality system, lab results, release certificates. |
None of those four is the finish line. The output is a decision, with an owner, communicated to the teams it affects. A workflow that produces analysis but no decision, or a decision nobody hears about, has not done the job it exists for.
Follow one order from field to customer
Before you change any tool, trace one real order the way it actually moves, not the way a process document says it moves. Pick a single order from a retail customer and follow it backward through the week.
In a lot of grower-packers the path looks something like this. Sales takes the order, or the retailer drops it through a portal, and it lands in the ERP or a sales sheet. Someone checks it against what the fields are expected to yield, using grower updates that may already be a day or two old. The order gets slotted into a packing schedule that assumes a certain crew size and a certain line speed. Overnight, a field agronomist flags that a block is not ready. In the morning, QA puts a hold on a harvested lot pending a lab result. The packing supervisor reshuffles the run. Someone calls the retailer to renegotiate quantity or timing. And the master plan, the one everyone looked at yesterday, now describes a week that no longer exists.
The point of tracing this is not to assign blame. It is to see where the order loses information. A quantity leaves the field as an estimate, gets treated as a commitment in the schedule, runs into a quality hold nobody upstream can see, and finally reaches a customer conversation where the person on the phone is working from whatever version they happened to print. Most planning pain is not bad math. It is good information arriving at the wrong step, too late to change the decision.
Make the first version dependable, not complete
Good production planning does not mean every field, product, and line is modeled in one system. In a seasonal business with weather, biology, and labor in the mix, that model would be out of date before you finished building it. A dependable first version is smaller and more honest. It makes one planning cycle visible enough that the team can decide from it instead of rebuilding it.
At a minimum that means five things sit in one place for the decision you picked: a view of demand for the week, a view of what supply looks likely, the capacity constraints that actually bite, current quality status including holds, and a short list of the exceptions that need a human call. The exceptions list is the part people skip and the part that matters most, because senior planners do not need to re-read the whole plan every day. They need to know what changed and what decision it forces.
Keep the first version deliberately plain. A plan a supervisor can open on a Tuesday and act on beats a beautiful dashboard that needs three people to explain it. The value shows up when the same view works every week without a scramble to assemble it.
Build one shared planning view everyone trusts
The core piece is a single planning view that holds demand, supply, capacity, and quality next to each other, plus the exceptions that fall out of putting them side by side. When those four sit in separate systems and separate heads, every planning meeting starts by rebuilding a shared picture from four partial ones. When they sit together, the meeting can start at the decision.
You do not need one platform to own all four. You need one place where they are read together and kept current enough to trust. That can be a well-structured sheet, a lightweight app, or a module you already pay for. What makes it work is less the tool and more the discipline that each part has an owner and a last-updated time, so nobody is arguing from a stale number.
A useful test for the shared view is whether it surfaces the conflicts, not just the numbers. Demand of 400 cartons against a likely supply of 300, on a line that can only run 250 before the transport cutoff, with 80 of the crop on a quality hold, is four facts. The planning value is the one sentence they add up to: you are short, and you have to choose who gets served, who gets delayed, and what you tell them today.
Keep a decision log so the plan can teach you something
When the team moves a harvest date, substitutes one lot for another, reallocates inventory, or delays a run, write down why in one line. This sounds like overhead. It is the cheapest way a planning function ever gets smarter.
Without a log, every week feels like fresh bad luck and nobody can tell whether the plan keeps breaking for the same reason. With a log, the pattern shows up fast. If half your changes trace back to grower updates that arrive after the schedule is set, the fix is the update timing, not the schedule. If most substitutions come from one crop or one grade line, that is where the yield or quality problem really lives. The log turns a stressful week into something you can act on next season.
Keep it light. A date, the decision, the reason in plain words, and who made the call. If capturing the reason takes more than a sentence, the log will not survive a busy week, and a log that does not survive is worse than none, because people stop trusting it.
Fit the data and systems to the decision
Food and agriculture businesses are rarely short of systems. There is usually an ERP, a farm or crop management tool, a packing or production scheduler, inventory or a WMS, a quality system, procurement, sales orders, maybe a forecasting tool and a BI layer on top. The mistake is starting from the system with the most fields and asking what it can show. Start from the decision and ask what it needs.
For a weekly harvest-and-pack decision, the short list is usually demand by customer and product, forecast confidence, field yield estimates and expected ready dates, inventory and shelf life, line and labor capacity, quality status, packaging on hand, and the outbound logistics window. Most of that already exists somewhere. The work is pulling the few fields that change the decision into one current view, not integrating every system end to end.
Timing is the part teams underestimate. Data has a shelf life just like the product does. A field update that lands after the packing schedule is locked is not planning information, it is a postmortem. When you map the data, map when it arrives as carefully as where it lives, because a perfectly accurate number that shows up an hour after the decision changes nothing.
A worked example: a grower-packer in a short week
Say a grower-packer supplies two retail chains with leafy greens and packs on two lines out of a single site. This is an illustrative example rather than a real client, and the shape will be familiar. On Monday the plan looks fine: firm orders from both chains, three fields expected ready midweek, both lines crewed, cold storage with room.
By Tuesday, three things have moved. A heat spell has pushed one field's ready date from Wednesday to Friday, so the midweek supply is lighter than planned. QA has placed a hold on a harvested lot while a lab confirms a result, which takes one line's Thursday morning run off the table. And Chain A has pulled its Thursday order forward to Wednesday to cover a promotion.
Individually, each of these is a phone call. Together they are a planning decision: there is not enough of the right product, ready at the right time, on an available line, to serve both chains as promised. Someone has to decide what to protect. The useful version of the workflow does not hide this behind a green dashboard. It puts the conflict on an exception board where the decision, the owner, and the next action are explicit.
| Exception | What it hits | The decision | Owner | Next action |
|---|---|---|---|---|
| Field ready date slips to Friday | Wednesday and Thursday supply for both chains | Reallocate the lighter supply or delay one order | Supply planner | Confirm revised yield with the field team by 9am |
| Quality hold on a harvested lot | Thursday morning run on Line 1 | Substitute a cleared lot or move the run to Line 2 | Quality lead | Chase the lab result; hold packaging until release |
| Chain A pulls its order to Wednesday | Wednesday line capacity and cold storage | Serve the promotion or protect Chain B service | Sales lead | Confirm margin and service trade-off with commercial |
With the conflict framed this way, the Wednesday planning call takes ten minutes instead of an hour, because everyone is looking at the same three decisions rather than reconstructing what happened from their own inbox. The plan changed, but the change is visible, owned, and communicated, which is about all a plan can honestly promise in a business this exposed to weather and biology.
Where AI actually helps here
Once the planning view has some structure, AI can take real work off the team, mostly in two places: turning messy inputs into planning signals, and helping review exceptions faster.
On the input side, field notes, grower texts, and sales updates often arrive as free text. A model can read those and pull them into structured signals: this block moved to Friday, this customer changed quantity, this lot is on hold. It can compare the week's demand against likely supply and flag where the two do not reconcile. It can draft the planning commentary a supervisor would otherwise write from memory, and it can sketch scenarios when weather, labor, quality, or demand shifts, so the team is choosing between options instead of building them from scratch under pressure.
The rule that keeps this safe is simple. AI prepares the decision; people make it. The model should never quietly overwrite a yield estimate, release a lot, or commit product to a customer. It should make the current picture faster to see and leave the assumptions, the source data, the suggested options, and the final call visible to the person who owns the outcome. If you cannot trace a suggestion back to the field update or order it came from, do not act on it.
Where people still have to make the call
Some judgments in food and agriculture do not move to software, and pretending otherwise is how planning tools lose trust. Whether a field is truly ready is an agronomy call. Whether a borderline lot ships is a food safety call with real liability behind it. Which customer to protect when supply is short is a commercial call that weighs margin against a relationship you plan to keep for years.
The workflow's job is to bring those calls forward with the right information attached, not to make them. When a planner decides to delay Chain B rather than break a promotion commitment to Chain A, that decision should be easy to make and easy to explain later, because the numbers and the trade-off were already in front of them. Good planning tooling removes the scramble around the decision. It does not remove the decision.
What usually goes wrong
Most production and harvest planning breaks in a handful of predictable ways. Naming them makes them easier to catch before they cost you a shipment.
| What goes wrong | Why it happens | What to do instead |
|---|---|---|
| The plan is built too early and never updated | It is set right after the prior week closes, before fields and orders move | Treat the plan as a living view with a midweek exception step, not a document |
| Field and grower updates arrive after the schedule is locked | Update timing is not designed; it depends on who remembers to send what | Fix the timing of the few updates that change the decision, not the whole integration |
| Too many products and lines in the first version | The team tries to model everything at once | Start with one decision, one product group, one site; widen once it holds |
| Quality holds are invisible to planning | QA and planning live in different systems and different meetings | Put current holds on the same view as supply, so a hold reads as a supply gap |
| Labor is assumed, not confirmed | Crew size is planned optimistically from a roster, not a confirmed show-up | Plan against confirmed or historically likely crew, and flag the gap as an exception |
| Decision rights are unclear when supply is short | Nobody owns the "who do we serve" call, so it gets made late or by default | Name the owner for each type of shortfall decision before the week starts |
| Nothing is written down | Every change is verbal, so the same failure repeats unlearned | Keep a one-line decision log and review the pattern each season |
Set a weekly cadence that protects decision time
A planning function needs a predictable weekly cadence, or every week turns into a fresh argument about deadlines and who owes what. The point of the cadence is not more meetings. It is to move the team out of collection and into decision before the week gets away from them.
| When | What happens | Output |
|---|---|---|
| End of the prior week | Confirm firm orders, forecast, and expected field ready dates | Draft plan for the coming week |
| Start of week | Lock the base plan; publish what each line and crew is expected to run | A base plan the team can act on |
| Midweek check | Pull field, quality, labor, and order changes into the exception view | A short list of decisions that need a call |
| Midweek call | Decide the exceptions; reallocate, substitute, or renegotiate | Updated plan with owners and customer commitments |
| End of week | Log what changed and why; note the repeat causes | Decision log entry and next-week inputs |
The exact days depend on your crop, your customers' order windows, and your close. The discipline is what matters: a base plan the team trusts, a designed moment midweek to catch what moved, and a quick decision step so changes are made on purpose rather than discovered at the loading dock.
A first 30, 60, and 90 days
If planning is painful today, do not try to rebuild it all at once. A narrow first version that ships beats a complete one that never does.
In the first thirty days, pick one planning decision, one product group, and one site. Map how demand, field ready dates, capacity, quality, labor, and logistics change that decision through a real week. Build the exception view and run one planning cycle from it, even if half of it is still a shared sheet. The goal is one week that runs from the view instead of from a rebuilt spreadsheet story.
In the next thirty days, connect the few data sources that keep the view current: the sales, field or production, inventory, quality, labor, and logistics fields that actually move the decision. Tighten the exception step and the decision log so the midweek call gets faster and less contested.
In the following thirty days, add AI where the workflow is stable enough to trust it, for variance summaries and scenario drafts, and only then consider widening to more products, lines, or sites. Keep going if late changes, waste, missed commitments, and planning arguments are getting easier to see and act on. Narrow it if the product scope or the decision rights are still too broad to hold.
How Ubisar would implement this workflow
In week one, Ubisar would choose one planning cycle and one product group, then map how demand, field ready dates, capacity, quality holds, labor, and logistics change the plan. The first output would be a planning exception board with the reason for each change, the affected orders, links to the source, the decision owner, and the next action.
In weeks two and three, we would connect the minimum sales, crop or production, inventory, quality, labor, and logistics data needed to keep that board current. AI would come in after the weekly cadence is agreed, to help with variance summaries and scenario notes, while planners and commercial owners still decide the trade-offs. By week four, the weekly planning review should run from the exception board instead of a rebuilt spreadsheet, and you keep going only if late changes, waste, and missed commitments are getting easier to handle.
If production and harvest planning is eating your week, Ubisar can help you pick the first decision to fix, build the data and view around it, and add AI where it earns its place. You can see how a month works on the AI, Data & Tech Implementation page, or tell us the workflow that is slowing you down through contact us.
Where to go next
For more on this sector, the food and agriculture page covers the workflows that come up most often in growing, packing, and food manufacturing. If you are weighing this against inventory, quality and compliance, procurement, or traceability work, the workflow guide library lays them out side by side. If you are still deciding where to start, how to choose the first workflow to improve with AI is a good next read.
If you need to make the business case first, the cost of manual work and implementation cost guides help, and if you are comparing a consultant, an agency, or software, the comparison guide is written for exactly that choice.
Sources and useful references
For background while you design your own planning cycle, the FAO post-harvest guidance at fao.org/4/y4358e/y4358e00.htm covers handling and loss, the USDA WASDE reports at usda.gov/oce/commodity/wasde track supply and demand estimates, and the GS1 traceability standards at gs1.org/standards/traceability are the reference for lot and product identification. Use them as background, and design the planning cycle around your own products, timings, and constraints.