Why it took me weeks to fill out a simple vendor form
I just wrapped up one of the most painful vendor applications I've ever encountered. Chewy's 150-column spreadsheet was genuinely one of the worst forms I've seen in years of business operations.
But the real problem wasn't their terrible form design. The real problem was us.
The Information Hunt
We had no single place to find comprehensive product information. I could locate some details in old emails, had to ask team members for others, and found myself constantly texting our CEO with questions like "What's the case pack quantity for the 60-day Free Range?"
This violated a fundamental operational principle:
There should be one and only one place to look for information.
Why This Gets Complex
Consider our product "Free Range"—it actually has 6 variants:
30 Servings
60 Servings
Bulk (buckets): three of these
Multiply that across 10+ products, and the data relationships become intricate quickly.
Some information stays consistent across all variants: formulation, usage instructions, nutritional specifications.
But each variant has unique dimensions, weights, serving counts, case pack details, and multiple SKUs (Shopify, Amazon, Chewy).
Thanks for reading Deacon’s Notes on Ops! Subscribe for free to receive new insights on ops.
The Spreadsheet Trap
When you're small, spreadsheets seem like the obvious starting point. Most companies begin there. But you eventually face an impossible choice: repeat identical product information for every variant, or fragment related data across multiple tabs where nobody can locate anything efficiently.
Some businesses migrate to specialized software, but that gets expensive fast. Plus, you always need to customize it to match exactly how your operation functions.
A Better Structure
What you actually need is a relational database. Think of it this way:
a product can have one or more variants
a variant only belongs to one product
Shared information lives at the product level. Variant-specific details connect to individual variants. When you need product information, you access the product directly. When you need variant specifics, you drill down accordingly.
I built ours in Notion because it requires no developer, adapts as we grow, and integrates seamlessly with our existing team documentation. More importantly, now that this database structure exists, anyone on our team can edit and input data as needed.
The Operational Payoff
With the framework in place now we’re back-filling the data as we can. The next vendor application will require an afternoon, not weeks of detective work.
If you're managing multiple products with various configurations and constantly asking "where did we store that specification?"—you need this organizational foundation.
The best systems often appear deceptively straightforward once implemented.
If you're wrestling with similar operational challenges, I'm always interested in discussing strategy specifics.
To your growth,
Deacon Bradley
P.S. Want to see our actual Notion structure? Just reply and I'll share some examples.
Thanks for reading Deacon’s Notes on Ops! Subscribe for free to receive new posts and support my work.