top of page

Merch inventory and order tracking without the warehouse count

Writer: Juliana
Juliana
11 minutes ago
5 min read
Agent Stories are fictional scenarios inspired by client projects we’ve delivered. The businesses, people, data and workflows shown are independently created illustrations. Our clients’ systems belong to them, so we keep their actual systems, private data and proprietary implementation details confidential.

At Copper Finch Merch, a fictional print shop in Madison, Wisconsin, someone asks how many shirts are available, and somebody else walks into the warehouse to count them.

The shop prints shirts, mugs, pens and signage. That routine worked when most customers were across town. Now orders come from farther away, jobs overlap, and each count pulls a person off the press.


In this story we'd plan one merch platform in Softr, with a staff workspace and a customer portal reading the same records. Before building it, the team would settle how stock is counted and when an order counts as accepted.


On hand, reserved, available

"We have 40 mugs" can mean 40 on the shelf or 40 nobody has claimed. Copper Finch would keep three fields per product:

  • On hand: units physically in the warehouse.

  • Reserved: units held for accepted orders and not yet printed.

  • Available: on hand minus reserved.

Customer requests get checked against available. If 22 of the 40 mugs on the shelf are held for other orders, a new customer can have 18.

In Softr Databases, available would be a formula field. Reserved could be a rollup that adds up the quantities on linked reservation records, so nobody types it in. Softr's page on related record, lookup and rollup fields covers the setup.

Diagram titled "Three stock numbers, kept apart", with illustrative numbers for one fictional mug product. A stock movements log (delivery received adds, production use subtracts and releases a reservation, adjustment is a count fix with a reason) feeds On hand: 40. Reservations from accepted order lines feed Reserved: 22. Both lead to Available: 18, calculated as on hand minus reserved, the number requests are checked against. A small Softr logo sits in the corner.
Illustrative numbers only.

Logging every stock change

Typing a new on-hand number over the old one loses the reason it changed. Copper Finch would add a row to a Stock movements table each time instead: product, type, quantity, date, and who entered it.


Blank mugs arriving from the supplier get logged as a delivery and add to on hand. Printing 18 mugs for an order is production use; it subtracts 18 and releases the matching reservation. A dropped box or a recount is an adjustment, and staff type a reason.


On hand is then the sum of a product's movements. If a number looks off, anyone on staff can open the product and read its rows. Softr's expanded record view also keeps a revision history of field edits, and your plan sets how far back it goes.


We'd limit adjustments to one or two people. A wrong delivery is easy to trace to a supplier note; a wrong adjustment usually isn't.


Acorn Trail Coffee sends a request

Acorn Trail Coffee, also invented for this story, is opening a new café. In the portal they pick mugs and shirts, enter quantities and shirt sizes, upload their logo file, and submit an opening-day request.


Nothing is reserved yet. The Copper Finch team reads the request, checks available stock, and checks that the artwork and sizes are complete enough to print. When they accept it, reservations are created for each line.

Because "requested" and "accepted" are separate statuses, Acorn Trail never sees a date the shop can't hit, and the shop doesn't tie up mugs for an order that might still change.

Diagram titled "How an order request would move", using a fictional example in which Acorn Trail Coffee asks Copper Finch Merch for 24 mugs. Four numbered steps: Request, Stock check, Reservation (created only when staff accept the order) and Progress (portal shows the latest confirmed staff update). Below the stock check, a panel shows 24 requested minus 18 available equals 6 short. It says no date is set automatically, staff agree a restock with the customer first, and a person makes that call. A bottom row runs restock arrives and is logged, production resumes, human quality check, dispatch.
Fictional example. Staff agree a restock with the customer before any date is confirmed.

24 mugs requested, 18 available

Acorn Trail asks for 24 mugs. Copper Finch has 18 available, so the order is 6 short.


Mugs

Requested

24

Available

18

Short

6

In this design, the system doesn't hand out a delivery date. Someone at Copper Finch calls or emails Acorn Trail and they agree on a restock before anyone confirms a date. When the extra mugs arrive, staff log the delivery, available goes up by 6 or more, and printing resumes. A person checks the finished mugs before they ship.


Softr Workflows could flag the shortfall for that person. A workflow starts from one trigger, such as a record being added or updated, or a record meeting conditions you set, and then runs actions like updating a record or sending an email. A rule here might be: when an order line asks for more than the product's available count, mark the order "Needs restock" and email the team. The Softr Workflows docs list every trigger.


What Acorn Trail sees in the portal

After acceptance, the order moves through artwork approval, production, quality check and dispatch. Staff mark each step when it happens, and the portal shows the most recent one they confirmed. While the order waits on mugs, the portal says it's waiting on a restock.

In the story, Acorn Trail's owner sums it up: "I picked the merch, approved the design, and knew exactly where my order stood. It couldn't be easier." That's an imagined line from the fictional scenario, not a customer review.


Where each Softr piece would go

What you see in the video is a presentation of this plan. Nobody has deployed it.

The data would sit in Softr Databases: Products, Stock movements, Customers, Orders, Order lines and Reservations, joined with related record fields, with artwork in a file field on the order.


Two Softr interfaces (the apps people sign in to) would share that data. Staff get one workspace for stock, requests and milestones. Each customer gets a portal limited to their own orders, using user groups and data restrictions. Plans differ here. Softr's global data restrictions page says view restrictions work on every plan, while create, edit and delete restrictions need Business or above, and custom user groups start on Pro.


Workflows would do the follow-up: the shortfall flag, a note to staff when a request comes in, and order status updates as milestones change. Each plan has a monthly workflow execution limit, and workflows pause when you reach it, so count how many runs a busy week would need.


Questions to answer before building

Which items get their own stock record? Copper Finch would probably track each shirt size and color separately, and each mug style once.

What releases a reservation? Production use, a cancelled order and an edited quantity all should, and the team should agree how.

Who logs deliveries and production use, and who may adjust? What makes a brief complete enough to accept? Which updates does the customer see, and which stay with staff?

If linked records are new to you, our Airtable project tracker for beginners uses the same idea with simpler data. Boat assembly tracking without the paper chase is another Agent Story with human checkpoints on a workshop floor.


Growing beyond your hometown?

If stock answers at your shop still mean a walk to the shelf, start with the three numbers and a movement log. Let's build a system that grows with you.


Comments


bottom of page