Ahmad Dibo© Notice

A4

Operations and intake automation for Say Adios (now Zozy)

01 Problem

A customer fills a 50-pound bag with things they no longer want and a driver takes it away. From that moment the bag is identifiable. Somewhere in a warehouse it becomes thirty individual items that each need identifying, condition-judging, pricing against what comparable items actually sold for, and listing, while staying attached to the person whose garage it came from. Doing that by hand took a coordinator most of five minutes per item and produced different output depending on who did it. The premise of the business was volume, and the work scaled one item at a time.

02 Context

Say Adios sold convenience. A branded bag arrived within a business day, the customer filled it at their own pace, and a driver collected it; items were then either resold, donated, or disposed of. Every constraint followed from having no engineering function. The system had to be assembled from tools a non-engineer could operate and repair— a relational base, a workflow automator, a messaging platform, a hosted storefront, a model behind an API—and it had to keep running while real customers were mid-transaction. Every migration had to be additive and reversible, because there was no launch to build toward, only a moving operation to rebuild underneath.

03 My approach

Enrichment was the slowest step and the most obvious step to automate. Working through it, the constraint turned out to sit earlier: no identifier survived the journey from order to item. Faster listings that still could not be traced back to a customer would not have been worth much.

Automate the seams between systems, leave the work inside them alone. Photographing, judging condition, and approving a price are human steps that stay human. The handoffs where information got re-keyed or forgotten are the ones that are worth removing.

  • Additive and reversible over clean: a live operation cannot absorb a cutover
  • Messier data over slower intake: the team chose a freeform field over per-category forms, and they were right
  • Sold comparables over active listings

04 Key decisions

A customer keyed to the last four digits of their phone number, a bag keyed to the order number plus its sequence, an item keyed to its bag plus its own sequence. The scheme reads in both directions, so an item states which bag it came from and therefore which customer.

I iterated the intake form for weeks before replacing it with a voice and camera assistant. A coordinator states the bag identifier, narrates each item, and says when the bag is done. The job is performed standing up with both hands full, which no version of a form was going to address.

05 What shipped

An order flowed into a customer record without transcription, a bag carried a scannable state, an item entered the system by voice, and enrichment returned a listing a coordinator approved rather than wrote. A bag went from 30 minutes end to end to 5, timed on both sides of the change, an 83 percent reduction.

The pipeline outlived the business it was built for. A pickup run costed out at roughly $99 against a customer price of $79, where every completed run lost about $20 before a single item was listed. Leadership kept the bag business deliberately small and moved the company’s centre of gravity onto the categorization and valuation layer I had been building as plumbing.

Order → bag delivered → customer fills it → driver collects → voice intake → enrichment → coordinator approves → listed.

06 Key learning

The infrastructure I built for a business that could not work is the asset the successor business runs on. My objection was made with the clearest view of what a run involved and it was still the wrong call, while the system I built underneath that objection was the right one. Being wrong about the strategy and right about the system produced a usable outcome.