Our Story

Andrew Van Egdom - Organizer and key communicator

Sophia Rose Coffey - Manages the team and provides industry insight

Valery Delgado - Webmaster and artistic designer

Our team has experience working for world-class produce retailers.  We have worked with many existing inventory systems and we understand their limitations. We have firsthand experience handling the complications that are specific to produce inventory management, and have an in-depth understanding of how that impacts ordering.  We knew that a better solution was possible, so we set out to make it. The FreshScope design process is outlined below:

Produce is different than other forms of retail. Anyone who works with the product knows this, but existing inventory systems ignore it. 

We started out by outlining what makes produce so much more complicated: 

Shorter shelf life – The obvious one. This greatly increases shrink which is the leading cause of inventory counts sliding away from accuracy.

No barcode – Many produce items do not have a barcode or the sticker with the barcode falls off, which increases errors at the register.

Quality variability – This makes it hard to predict how much of each item the customers will buy which makes ordering difficult. 

Pound versus unit– Items are often sold to stores (and customers) by the pound versus by the unit. This makes getting accurate inventory counts trickier and more subject to human error.

Organic versus conventional – Many organic products are mistakenly rung up as conventional and vice versa. It is also common for customers to make use of SCO to intentionally ring organic products up as conventional in order to save money. This is difficult to notice and stop.

Overlapping product types – The wide selection of similar products also increases mistakes at checkout. Think envy versus fuji versus gala apples, cara cara versus navel oranges and red versus orange sweet potatoes. Customers often do not know which specific variety they are purchasing, stickers commonly fall off, and even when stickers are present cashiers often memorize a list of codes and use the closest match that comes to mind (rather than search their PLU book for the most accurate code). 

PLU versus SKU – An individual PLU often has tens of SKUs associated with it. Generally, retailers do not have control over which specific brand or source of a produce item they receive. Warehouses source products from many farms and distributors based on price and availability, and DMs typically order by PLU — meaning the warehouse fulfills the shipment with any available SKU that falls under that PLU's umbrella. Multiple SKUS are often present within a single display of an item. However, orders are sometimes placed for a specific SKUs depending on the nature of the item or the needs of the department. This variability creates additional opportunities for back-end accounting and inventory tracking errors.

Seasonal and regional variability – Produce availability changes significantly by season, and items frequently rotate in and out of the set. This makes historical sales data less reliable for auto-generated ordering than it would be for stable packaged goods with consistent year-round availability.

Backroom inventory tracking – Produce backroom stock is particularly hard to track because items are often partially used cases in various states of freshness. Unlike packaged goods where a case is either full or empty, a partial case of strawberries might be half gone and partially culled, making accurate BOH counts difficult even with a manual spot check.

Shrink velocity – Not all shrink happens at the same rate. A bag of apples and a container of raspberries both shrink, but at completely different speeds. Current systems don't account for item-level shrink velocity when calculating BOH or generating orders, which leads to inaccurate counts for highly perishable items even when everything is working correctly. 

Wet rack processing – Many items displayed on the wet rack are processed by store staff prior to being placed for sale. Leaf lettuces, kale, cabbage, celery, and root vegetables with attached greens are commonly trimmed, soaked, and labeled in store. For items sold by the pound — most commonly root vegetables, broccoli and cabbage — this creates shrink because the store is invoiced for the full weight of the product as received, but a portion is discarded during preparation before the item ever hits the sales floor. This means BOH counts for these items are effectively inflated from the moment they are received.

Reprocessing – Reprocessing is the act of removing damaged product from a package and combining the remainder with another partial package to reduce shrink and maintain a full unit for sale. This is common with berries, bagged items, kale, cilantro, and other bundled leafy vegetables. While reprocessing reduces physical shrink, it creates inventory tracking complications — the system still registers two units received but only one unit remains for sale, meaning BOH counts will reflect more sellable product than actually exists on the floor.

When we set out to build FreshScope we knew that there were realistic constraints to keep in mind. 

Time: We had about a week to design a solution 

Economic: We are doing this without financial backing

Resource: we have a team of only 3 people

Budget: We want to make it affordable for retail operations

Our research started with our firsthand experience. We had an existing understanding of the industry and the problems within it, but we don't know everything.  We dug into the available systems. We looked at what they do well and where the pain points are. 

Oracle – This platform is a beast. It is one of the biggest and most common inventory tracking systems. It shines in supply chain management and it provides valuable financial data for corporate overview. But it is prohibitively complex and expensive for store-level use cases. It is difficult to implement the useful components of the program without inviting in the entirety of its complexity into your store. It is powerful but not simple to use. It is also designed for use in all retail markets, not specifically grocery. Because of that it is not geared for highly perishable departments such as produce and does not have any tailored features for perishable inventory tracking. 

Thinstore – A browser-based pricing and inventory management solution built around centralized execution of store tasks. It is primarily a task execution tool rather than an intelligent ordering system. Ordering can be done with Thinstore, but it is done manually and lacks ML-driven forecasting, perishable-specific logic, and produce-oriented features. That said, Thinstore has strong picklist integration. It maintains some information about display size and allows inventory to be scanned in and organized by backroom section. Because of this, it generates accurate picklists using live sales data — it knows what is in the backroom and what is on the sales floor, and when a unit sells it is automatically added to the picklist so the team can restock without creating a manual list. This is particularly valuable in grocery and other non-perishable departments, though it has useful applications in produce as well.

Relex – One of the more advanced competitors, and it does address fresh inventory fairly well. It has space planning and planogram functionality — and it integrates with the store's inventory and ordering tools. This is genuinely a strong feature compared to other competitors. That said, there are still meaningful gaps. Relex itself acknowledges that produce is frequently sold loose, creating immediate difficulties in monitoring, and that each item spoils at a different rate even within the same batch. Their solution leans heavily on AI automation and supply-chain-level forecasting, placing planners in a unified cloud system — but this top-down approach means it's still oriented toward corporate planning teams rather than store-level department managers doing hands-on ordering. Adaptive prompting and role-based floor-level tools are not available on this platform.

Next, we outlined our requirements: 

Ease of use — the system must be intuitive for store-level employees with minimal training required

Adaptive prompting — the system should intelligently prompt users to perform key functions based on inventory data and time thresholds, while still allowing department managers to initiate any action on their own as well

Data accuracy — inventory counts must be highly accurate, with mechanisms to account for produce-specific sources of error such as PLU miskeying, weight-based pricing discrepancies, and organic/conventional misrings

Perishable-specific inventory logic — account for shelf life, cull events, and variable product quality when calculating BOH and recommended order quantities

Shrink reduction — enable tighter, more accurate orders to minimize expired and damaged product loss

Machine learning + user override — leverage ML for order recommendations and trend analysis while preserving the ability for managers to adjust without friction

Robust reporting — must provide key financial data (shrink rates, order history, waste trends) accessible to store leadership and above, with the ability to cascade down to the departments

Integrated platform — combine schematic/space planning, inventory tracking, and ordering under one unified application

Warehouse/invoice compatibility — support importing from common warehouse and invoice systems to reduce manual data entry

Cross-platform support — functional web-based application with full support for handheld devices used on the floor

Scalability — affordable and adaptable for retailers of varying sizes, from single locations to multi-store chains

We threw everything we wanted down on paper:

DM v SM views – Separate views for departments versus store leaders versus corporate.

Units v. Dollars – DM view shows product data in terms of units/lbs/cases, store leader view displays it in terms of dollars. This goes for sales and shrink, inventory levels are displayed both ways.

Corporate view – Tracks company wide trends for shrink, sales and variability between predicted inventory levels and spot-checked values. 

Intelicounts – The system generates a prompted spot check (similar systems exist) but in this case DMs can add items to the Intelicount. These items can be added as persistent, one-time, or the DM can set a frequency. 

PLU variants on Intelicount –  Intelicount smartly prioritizes goods with the most subtypes. Items like apples (many PLU variants) get counted more frequently because misrings are more common.

Picklist integration – Longer shelflife items (salad toppers, fruit bars, berry boxes, dried fruit, jarred ginger/garlic and dried herbs) can be scanned in to backstock within the system and a picklist can be generated. Items that are sold by pound or are highly perishable are clunky in picklist systems so are excluded. 

Handheld ordering – Orders are started on the handheld and finished on the computer. Handheld ordering is used to verify accurate inventory counts on sale items and top movers etc… The computer is used to review the total order and finalize before submission. 

Auto-submitted orders – Our system will utilize this feature of many other systems. The system generated order will automatically submit at the time it is due regardless of if it has been edited.

Spot checks within handheld ordering – Ordering mode allows spot checks to be performed. Any count changes trigger a live update to the recommended order quantity. 

Inteli-orders – The handheld intelligently prompts the user to perform case orders for certain items. It automatically adds items that are high shrink, merchandise that is commonly trimmed or reprocessed and items that have not been spot checked for 3 days or more. Top selling items are also added to the Inteli-order for case ordering. DMs can also add items of their choice to consistently show up on the inteli-order. Like the Intelicount, these items can be added as persistent, one-time, or they can set a frequency.

No scanned shrink – Eliminate the need for scanning out non-food-donation shrink. Food donation can be scanned out to help track company goals related to waste reduction but shrink scans are not needed for inventory tracking.

Spot check account for shrink – Performing a spot check automatically categorizes any unsold merchandise as shrink. 

Space planning integration – Built-in integration with schematics and space planning allows for accurate picklist generation and reduces the need for double-counting (sales floor + backroom). Multiple display locations are grouped but distinct, enabling simpler counting. Display size auto-populates minimums for ordering. 

Counts performed in a single location – Counts performed in the back room automatically add the quantity displayed on the sales floor. The system knows how much is stored on the display so counting from the sales floor in addition to the backroom becomes unnecessary for items with backstock. This saves time when performing spot checks. Items that are present in the backroom can be counted exclusively on the sales floor. 

2 Intelicounts – A backroom Intelicount is generated based on products with predicted backstock. A second sales floor count is generated for items that are not in backstock.  

Dual count exclusion – Store leaders or company policy can exclude certain items from the backroom count system so that daily backroom counts can be performed to true up numbers without needing to count all items in the backroom and to keep longer shelf life items from being added to the Intelicount. This will primarily be used for items included in the picklist system. 

Introduces “shedding” – inventory for high-shrink items automatically reduces over time. For instance, inventory levels for wet rack items that are priced per pound are automatically reduced by, say, 5%  at delivery to account for trim. Which items are included and shedding rate can be adjusted by the company, store leaders or DMs. 

Register error catching – If more of an item is scanned at checkout than is present in the current inventory, this item gets added to the Intelicount automatically. Same for items that are undersold. 

Register error-catching logic – If more of a given item is sold than is currently reflected in inventory, the system checks two conditions before allowing the BOH to go negative: whether a spot check has been performed on that item within the past 24 hours, and whether a similar item exists in the set. If both conditions are met, the system assumes a misring has occurred — inventory for the similar item is automatically reduced instead of item A going into the negative, and a spot check is recommended for both items. 

Shorts and longs – Any variation between the order and the load is automatically updated in the inventory system, assuming the variation is documented on the invoice. 

Undocumented mispicks – The system cannot automatically guess at mispicks, but DMs can scan a mispicked item into the count when they catch them. Mispick detection is a known limitation of the system.

We doodled and drew up plans: 

We reviewed our ideas. We liked a lot of them but some needed refining. 

We decided to eliminate the corporate-specific desktop view. Our product is primarily for produce retailers at the store level and we decided to place our focus on the components that best serve store-level teams. 

Another weak point is adjusting the shedding rate to accurately reflect trim and perishability. The company, SM or DM needs to be able to adjust the shedding rate or turn it off entirely to give more control. This feature will be most effective for trim produce items that are sold by weight but can be implemented to reflect general perishability for highly perishable items such as berries, grapes and leafy greens. 

The hardest problem to solve is catching mispicks. Ramping up self correction within the tool through prompted spot checks will help reduce this but not eliminate the issue entirely as the system may not prompt a spot check on the mispicked item in a timely manner. 

Some features of the system, such as picklist integration, may slightly alter the workflow for some teams. These features should be optional and the program should work seamlessly without them. Integration of these features should also be intuitive and readily available. 

FreshScope began to come into view. We started work on finalizing our designs. Our current in-progress prototype can be explored on the Using FreshScope page.