--- title: "Subscription Box Allocation and Packing Manifest | Kylon" description: "How a fulfillment team allocates a monthly subscription box under a stock-limited walk order, absorbs recalls, retries and top-ups, and approves every packing change." url: "https://kylon.io/use-cases/subscription-box-allocation" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Subscription Box Allocation: Scarce Stock Goes to the Right Subscribers, in Order Use Case8 min read # Subscription Box Allocation: Scarce Stock Goes to the Right Subscribers, in Order Every month someone decides who gets packed, who is skipped and who gets the last units of a scarce variant. In a Kylon room, agents run that allocation in walk order and check the packing manifest, and the fulfillment lead approves before the warehouse packs a box. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## Who gets the scarce variant this month Every month the box should go to the people who are due one, in the variant they chose, as long as stock lasts. A subscriber who asked to skip is skipped. One whose payment failed is held until the retry clears. When a variant runs short, the policy walks subscribers in a fixed order, earliest start date first, and gives the scarce stock to each in turn until it runs out. Everyone after that point moves to a second choice or is held with an out-of-stock reason. The subscriber base is in Airtable, payment status and retries are in Stripe, skip requests arrive by email in Gmail, and the warehouse posts stock counts and recall notices in Slack. The allocation policy and the packing manifest sit in Google Drive. When a recall lands or extra stock arrives, the walk is usually redone by hand, and that is where the scarce units end up with the wrong people. ## Who works in the room People - Fulfillment lead Owns the monthly allocation, approves every disposition and signs off the packing summaries - Warehouse lead Confirms stock counts, reports recalls and top-ups, and packs from the approved manifest - Customer care Works held subscribers by follow-up tier and sends every reply to subscribers Agents - AdaAllocation runner Sets each subscriber to pack, skip or hold, gives out scarce variants in walk order and proposes follow-up tiers AirtableStripeGoogle Drive[Slack](https://kylon.io/integrations/slack) - MycoManifest checker Compares the packing manifest line by line with the approved allocation and lists every line that disagrees Google DriveAirtable - NovaSubscriber correspondence Reads skip requests and drafts replies for customer care to send [Gmail](https://kylon.io/integrations/gmail) Each box cycle gets its own room. Ada owns the allocation and is the default there, so stock and disposition questions go to it. Myco reviews the manifest whenever the allocation changes, and Nova handles subscriber email. After a reassessment, Ada mentions Myco in the same thread with the list of changed subscribers, so the manifest check starts from the right list. When a skip request arrives, Nova hands the subscriber ID to Ada before drafting any reply. ## A month of packing, in order The walk order is written into the room guidelines, so every reassessment uses the same sequence as the first pass. ```mermaid flowchart TD stock["Warehouse lead confirms
the stock counts"] walk([Scarce variants go out in walk
order, earliest start date first]) skip["Nova hands each skip request
to Ada before drafting a reply"] alloc["Ada sets each subscriber to
pack, skip or hold"] approve["Fulfillment lead approves
before Airtable is updated"] tiers["Ada gives held subscribers a
follow-up tier, others NONE"] manifest["Myco checks the packing
manifest line by line"] wh["Warehouse lead corrects it,
fulfillment lead confirms"] recall["Ada reassesses everyone
allocated the recalled item"] retry["Ada reassesses holds
whose retry cleared"] topup["Ada reassesses only
out-of-stock holds, in order"] recheck["Myco checks the manifest again"] approve2["Fulfillment lead
approves the changes"] close["Ada writes one packing summary
per box variant"] sign["Fulfillment lead signs off"] stock & skip --> alloc walk -.- alloc alloc --> approve --> tiers --> manifest --> wh wh --> recall & retry & topup recall & retry & topup --> recheck recheck --> approve2 --> close --> sign class skip,alloc,tiers,manifest,recall,retry,topup,recheck,close agent class stock,approve,wh,approve2,sign person class walk event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Allocation | Each subscriber is set to pack, skip or hold, and scarce variants are given out in walk order until stock runs out | Ada, from Airtable and Stripe | The fulfillment lead approves before Airtable is updated | | Follow-up tiers | Held subscribers get a follow-up tier, and everyone else is reported with tier NONE | Ada | Customer care confirms the tiers and the fulfillment lead approves them | | Manifest review | The packing manifest is compared line by line with the approved allocation | Myco | The warehouse lead corrects it and the fulfillment lead confirms | | Recall | Subscribers allocated the recalled item are reassessed for a substitute or a hold | Ada, then Myco | The fulfillment lead approves the changes | | Payment retry | Held subscribers whose retry cleared in Stripe are reassessed against the stock that is left | Ada | The fulfillment lead approves | | Stock top-up | Only subscribers held as out of stock are reassessed, in the original walk order | Ada, then Myco | The warehouse lead confirms the count and the fulfillment lead approves the changes | | Close-out | Four packing summaries are written, one per box variant, from the final Airtable records | Ada | The fulfillment lead signs off | Stages of a monthly box allocation. Subscriber IDs, variants and counts in this example are illustrative. ## When stock and payments move after the walk The warehouse posts that sixty more units of the amber variant have arrived. The tempting fix is to hand them to whoever is listed first. Ada does something narrower: it reassesses only subscribers held with an out-of-stock reason, in the original walk order, and stops when the new units run out. Subscribers held for payment are not part of that run, and nobody who is already packing moves. A recall works the other way. The supplier withdraws a batch of one item, so every subscriber allocated it needs a substitute from the policy's list or a hold. Ada proposes the changes, Myco checks the manifest again, and the fulfillment lead approves before the warehouse sees the new list. For a skip request, Nova drafts one reply on the subscriber's own thread with the subscriber ID and the skip confirmed, and customer care sends it. ## What the checks catch - Top-up stock given out of walk order, so a newer subscriber gets a unit ahead of someone who started earlier - Subscribers held for a failed payment pulled into a top-up that only applies to out-of-stock holds - A second reply on a skip thread that was already answered - Blank tiers for subscribers who are packing normally, where the report expects NONE - Skipped subscribers still on the packing manifest, or held ones listed with a variant ## What stays with people - Approving the allocation and every reassessment before Airtable changes - Confirming stock counts and the scope of a recall with the warehouse - Sending every reply to a subscriber, which Nova prepares as a Gmail draft - Signing off the four packing summaries ## Integrations in this workflow Kylon is not an order management or subscription billing system, and it does not try to be one. It works alongside the base, the payment records and the warehouse channel, and keeps the month's allocation decisions in one place. - Airtable - [Gmail](https://kylon.io/integrations/gmail) - Google Drive - [Slack](https://kylon.io/integrations/slack) - Stripe - **Airtable** holds the subscriber base, dispositions, tiers and the packing summaries - **Stripe** shows payment status and retry results, which Ada reads and never changes - **Gmail** carries skip requests and the replies customer care sends - **Google Drive** keeps the allocation policy, the walk order and the packing manifest - **Slack** is where the warehouse posts stock counts, top-ups and recall notices ## Where to start Run one box cycle in the room. Connect the Airtable base and Stripe, put the policy in a shared Drive folder, and write the walk order and one rule into the room guidelines: Ada proposes every allocation and reassessment, and the fulfillment lead approves before the base is updated or the warehouse gets a manifest. If stock counts live in a sheet the warehouse edits, a Kylon App can hold them instead, so the warehouse lead and Ada read the same number. > “The top-up went to the next subscribers in line, which is what the policy said all along.” ## 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. Set-up prompt Set up our subscription box allocation desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Airtable, Gmail, Google Drive, Slack and Stripe. Tell me which ones still need connecting. 2. Ask me who works this desk: the fulfillment lead, the warehouse lead and customer care. Help me invite them to this Room. 3. Build a Box Allocation App with Subscriber, Variant, Disposition and Status, one record per subscriber. Fill it from the current Airtable base. 4. Set each subscriber to pack, skip or hold. Read skip requests from Gmail and payment status from Stripe. Give scarce variants out in walk order, earliest start date first, until stock runs out. Assign a follow-up tier to every held subscriber and NONE to everyone else. Show me blank tiers, skipped subscribers still showing a variant and payment-held subscribers pulled into an out-of-stock top-up. 5. Compare the packing manifest in Google Drive line by line with the approved allocation and list every line that disagrees. Draft each subscriber reply in Gmail for customer care to send. Never update Airtable or send any reply until the fulfillment lead approves. 6. Write the walk order and the approval chain into this Room's guideline so every reassessment after a recall, a top-up or a payment retry follows the same sequence as the first pass. 7. After one clean cycle, offer to turn the allocation run into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Card Chargebacks: Every Dispute Represented or Accepted on Its Evidence, Not Its Deadline Each chargeback is represented, partly represented or accepted on what its Box evidence and Outlook refund history show, analysts are assigned by tier, and late evidence re-runs the rules. The disputes lead approves every status before Attio changes. Retail & e-commerceFinance operations ](https://kylon.io/use-cases/card-chargebacks)[ ### Crowdfunding Reward Fulfillment: Pledges Placed in Waves That Stay Right as Holds Clear Backer pledges are walked into fulfillment waves or holds in one Kylon room, with shipping and add-on amounts on each Notion page. Declines, shortfalls, rate changes and clearances re-run the whole walk, and the fulfillment lead approves every move. Retail & e-commerceSupport & customer success ](https://kylon.io/use-cases/crowdfunding-reward-fulfillment)