Constrained Order Allocation: Short Stock Shared by Priority, Walk After Walk

More orders than stock, and a queue that moves with every change

When a SKU is short, the desk allocates what it has in a fixed order: priority tier first, then order date, until the stock runs out. Each order ends up full, partial or backordered, with an allocated quantity and a fill rate the customer will ask about. The walk is simple to describe and easy to get wrong after the third change in a week.

The orders sit on an allocation object in Salesforce. Each SKU's stock position at the start of the cycle is on a Notion page, which stays the opening snapshot rather than a live count. Escalations arrive in Outlook, order threads run in Gmail, supply planning posts receipts in Slack, and the policy, the intake checklist and the draft allocation sheet are in Google Drive.

Who works in the room

Every walk is led by Nova, the room's default agent. Myco is mentioned for checklist and sheet reviews and checks each line against the walk the policy describes. Ryan holds the Gmail and Outlook connections here, so anything that needs a customer reply routes to Ryan. After a walk, Nova mentions Ryan with the one order the planner wants confirmed, and Ryan drafts exactly that reply.

How the cycle's allocation runs

The walk in the allocation policy is the only method any agent uses. The planner approves each result before Salesforce changes.

A receipt, a tier change or a cancellation means a fresh walk

An allocation is a queue, so any change near the front moves everything behind it. When a receipt lands, Nova adds it to the cycle-start position from Notion and walks the SKU again from the first order. When sales moves two orders up a tier, both SKUs they belong to are walked again. When control panel orders are canceled, the freed stock flows to the next orders in line, and some of those were partial an hour ago.

After every walk Nova reports every order's fields, including the ones that did not change. That lets the planner approve the whole SKU at once instead of trusting a list of differences. Replies follow the same discipline: Ryan drafts exactly one reply on the thread the planner names, with the order id and its resulting fill, and leaves the other escalations in Outlook for the reps.

What the checks catch

• Notion's stock figure treated as the cycle-start position, with receipts added, never as live stock
• Every order in a re-walked SKU reported with its fields, changed or not
• Stock freed by a cancellation passed to lower-priority orders behind it in the same SKU
• Exactly one reply on each named thread, and none on threads nobody asked about
• A draft sheet line that fills a lower-tier order ahead of a higher-tier one on the same SKU

What stays with people

• Approving each walk before Salesforce is written
• Deciding priority tier changes, which sit with sales leadership
• Sending every customer reply, which Ryan prepares as a Gmail draft
• Signing the per-SKU summary and backorder records

Integrations in this workflow

Kylon is not an ERP or an order management system and it is not a substitute for either. It sits between Salesforce, Notion and the team's mailboxes and keeps the coordination in one room. Nova's Salesforce writes go through a lasting grant from the planner to this room, and happen only after the planner approves each walk.

• Gmail
• Google Drive
• Notion
• Outlook
• Salesforce
• Slack

• Salesforce holds the allocation records: each order's tier, allocated quantity, fill and backorder
• Notion holds each SKU's stock position at the start of the cycle
• Outlook holds the customer escalations the reps work through
• Gmail carries the order threads where Ryan's replies wait as drafts
• Google Drive keeps the allocation policy, the intake checklist and the draft allocation sheet
• Slack is where supply planning posts receipts and sales posts tier change requests

Where to start

A single short SKU over one cycle is the right place to begin. Connect the Salesforce allocation object and share the Notion stock page, then give the room guidelines one rule: every change triggers a full walk of the SKU from the first order, and the planner approves the complete result before Salesforce is updated.

“Every order in the SKU is shown after each walk, so nobody has to trust a list of differences.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.