Automating the SKU pipeline by staying close to the people who run it
Every customer catalog request means looking up each SKU by hand, reconciling its attributes against product rules, and re-keying the result into PIM: 33 SKUs for one customer, about 1,500 for another. Shelby Corbitt is building the pipeline that does this on Claude Managed Agents, with a person approving every record, and building it alongside the team that does the work today.
The work today
When a customer needs its products set up for ordering, the customer success team and the dealer send a SIF file or an Excel list of SKUs, and it lands as a Wrike ticket for Angie Lindberg’s B2B team. The team adds the SKUs to the customer’s view in Airtable, looks each one up in the Pub Layer to gather its attributes, reconciles them against product-specific rules (which finishes go with which Aeron chair, for example), and uploads the result into PIM through Excel templates and several manual steps.
A request can be 33 SKUs, as it was for the City of Tacoma, or about 1,500 across five phases, as it was for CSU. It is recurring, high-volume work, and exactly the kind of busywork that leads to burnout.
What’s being built
The pipeline starts from the Wrike ticket. It reads the customer’s file, checks each SKU against Airtable to decide whether it is new or an update, and stages it for review. SKUs that PIM already has skip the Pub Layer lookup entirely. The rest are enriched from the Pub Layer by an agent on Claude Managed Agents, applying the combination rules the team curates.
Nothing is published on the agent’s word alone. A person will review every record in Airtable and approve it before it goes to PIM, and a rejected record goes back to the manual process, so nothing half-right moves forward. Today the pipeline runs end to end against test systems, from the Wrike ticket through Airtable and the Pub Layer, and it builds the PIM import workbook in the exact shape the PIM team already uses.
Built alongside the business
The design came out of a working session on August 14 with Angie Lindberg, Chris Miller, Michael Pietrangelo and Shelby Corbitt, and the build has stayed close to the business since. Kathy Clark walked Shelby through how records are actually imported into PIM, and the import workbook is built to match the files her team imports. Angie’s team settled what each PIM status (Hold, COM, Obsolete) means for the pipeline. Where Shelby had to make a call the business hadn’t made yet, she recorded it as her inference and flagged it to revisit.
Where the right value isn’t known yet, the pipeline leaves it blank and says why, rather than inventing it. Four columns of the PIM import are blank today on purpose, each with the question already with Kathy’s team. It is the same rule that made the Scott AFB bid work: at this scale, a confident guess is more dangerous than a visible gap.
Guardrails from day one
The agent reads files that come from outside MillerKnoll, so it was scoped tightly from the first design review. It can reach only Wrike, Airtable, the Pub Layer and PIM. It has no shell access. The product rules it applies are curated by people and mounted read-only, so no run can rewrite its own rules. SKUs it can’t match are skipped and reported back on the Wrike ticket, not written as a best guess.
What’s next
Next are the review gate that turns an approval in Airtable into the PIM upload, and the remaining PIM columns once Kathy’s team confirms how they are derived. The pattern itself (start from the ticket, enrich from the Pub Layer, a person approves) fits other recurring catalog work across the business.