If Amazon Ran a TCG Singles Business (Part 5)

This post is guest written by Jason Garvin from Total Escape Games.

Steps to Create a Chaotic Warehousing System for Magic Singles

Let’s assume we have everything we need to create a chaotic warehousing system for Magic singles: the software is available and runs smoothly, and you’re ready to change your in-store infrastructure to support using bins instead of sorting by set.

What would that system look like?

Well, I experimented with this process, from the sorting and filing process to how singles might get managed by a software system, and all the way through to pulling mock lists. Here’s what I discovered.

The Experiment: Bin Sorting a New Buy

Originally I came into this idea with a few key metrics to determine whether bin sorting had a chance of being a better system than alphabetical:

• Does it reduce the time it takes to process card buys?
• Does it match (or improve) the time it takes to pull cards for lists?
• Is it an extensible system with flexibility?

To test-drive this new approach, I took a small collection we’d just bought plus some unsorted bulk that’s been sitting around the store, to create a separate library of cards for this test.

This would become the new library as I fed it into the CardBot in different quantities and ways.

I tested a lot of different sizes to see what was the quickest and most painless to process and pull cards from. In the end, the optimal bin size for my needs seemed to be between 200 and 300 cards.

Table 1 - Cards sorted by the CardBot, time taken, and success rate

I chose that range because of the amount of time the CardBot took - not too little that my team has to focus on it constantly, but not so much that it gets forgotten after over an hour of processing. Also, at that range, it was quick to validate the scans and make sure everything was imported correctly without my attention slipping. 

At the higher card ranges, validating the scans and even alphabetically sorting the cards became disproportionately more tiring. Mental fatigue is the enemy of a smoothly-functioning workplace, so that wasn’t going to work.

Results

Based on the tests I ran, this is the system I landed on:

• Feed a stack of 200-300 cards into the CardBot and let it pluck away (20-30m).
• Review the results, put back the cards it rejected, and confirm conditions and printings (5-10m). 
• Accept cards into CardCastle inventory and tag with bin identifier (1m).
• Alphabetize the cards within the bin (2-3m).

All in all, it took 30-40 minutes per bin. I often was working on alphabetizing cards while the bot was scanning the next bin, which increased efficiency a bit. I think if I were to spend more time optimizing my system and getting used to the CardCastle interface, I could get this down by another 5 minutes per bin.

Bin Identifiers

To categorize the cards going into the library, I created a unique identifier for each bin:

A-BB-CCC.

The A is a cabinet identifier. If the bin is in the first cabinet, it would be labeled as “A,” then “B” for the second cabinet, and so on. Note that in the case of a large number of cabinets or shelves, switching to two digits of numbers would work just as well. I chose letters to distinguish the cabinet information from the rest of the code for readability.

BB, then, is the drawer number. Our cabinets have 12 drawers each, so this would range from “01” at the top, to “12” at the bottom, but it can go far beyond that in case you use dozens of shelves per unit.

Finally, CCC represents the position in the drawer, with the lowest value towards the left and the highest value to the right. 001 is the first bin in the drawer, whereas 122 might be towards the middle or back. 

This works so that even as bins decrease, you can choose to add a new bin to a drawer that suddenly has space without running out of classification values. If I notice drawer B-11 is getting emptier, I can choose to append bins at -133 and -134 to that rather than to the full end of the catalog in cabinet C. This keeps things modular and flexible.

While each bin could just appear numerically (Bin 14423, for instance), this can lead to constant relabelling of cabinets and drawers as the bins shift around. It’s also really user unfriendly, and can be difficult to read and understand. 

A single numeral fails to tell my staff where, roughly, to find that card at a glance so they can keep moving. It requires system knowledge and an implicit understanding of where each bin is in physical space based on how deep into the numbering it is.

Putting Cards Away

This was by far the biggest improvement. Instead of putting away each card in a massive alphabetical sort, or having to find and categorize each card to its set, the bins just got appended on the end of the sort.

The only part that took any time at all was done mostly by the CardBot, with a small amount of time spent validating the inventory before committing it. In comparison to our existing processes and the amount of steps, this was trivial.

Additionally, only having a handful of cards to sort kept the alphabetization process lean, and reduced errors. It’s common to go into a high-volume box of cards in our current library and find small sections out of place as the team works quickly to get things in and out of the library. This system reduces a lot of that friction.

Pulling Cards

As opposed to our real library, I had to get a bit creative when testing card lists from the bin-sorting system.

Especially since there was no software system to automate the process, I made a few assumptions about the card list output:

• The list would display the cards in order of location in the bin sort from front to back
• The list would be generated using the first available printing of a card in the sort
• The list would include the exact bin identification number to locate the card

I found this went about as quickly as any pull list that’s accurate. The alphabetical printout from TCGplayer Kiosk, for instance, takes about the same amount of time. 

Both point to the location of the card and ensure I only have to look in one place. Both organize the list to move through the library in order without having to backtrack. Overall, there wasn’t much improvement, which is in line with my expectations.

If the output of the pull list differs, we get into uncharted territory, and I’ll outline some of my worries in the next section (spoiler: I’m not nervous about dropping boxes, but I am worried about my team finding the cards effectively in the first place).

Takeaways

Bin sorting was a fascinating experiment and I learned a lot throughout this process.

When I test this process again the next time, I’m going to have 1-2 members of staff help me so I can better understand how it feels for them to learn a new system, how complex this feels to them, and how many errors they make.

I also think it’s beneficial to run this experiment on a larger scale. Having only a couple of 5-rows filled with cards meant that while it’s an effective simulation, it doesn’t come close to replicating what it’s like to use our actual, live system.

I want to understand where this system runs into problems at scale, and that’s going to require more testing.

Lastly, I’d love to experiment with how pull lists are generated for bin-sorting. I made a lot of assumptions with how I made my fake pull lists, but I’m not convinced that’s the optimal approach.

For example, what if instead of finding the first card in the system, the software governing the system could intelligently find where several cards from the list all exist in one box? Or in one cabinet? 

I’m really interested in just how much more streamlined this process could become with intelligent software solutions, and I’m excited to keep experimenting with it.

We’ve already decided to someday adopt bin-sorting once the software catches up, and I’m hopeful we’ll be able to greet that day with a wealth of experience and carefully-tested systems.

If you'd like to get in touch with Jason or read more of his writing, head to jasongarvin.com.