{"id":11547,"date":"2026-10-19T14:16:48","date_gmt":"2026-10-19T05:16:48","guid":{"rendered":"https:\/\/blog.themusio.com\/?p=11547"},"modified":"2026-10-19T14:16:49","modified_gmt":"2026-10-19T05:16:49","slug":"how-a-building-materials-firm-closed-its-catalog-coverage-gap","status":"publish","type":"post","link":"https:\/\/blog.themusio.com\/?p=11547","title":{"rendered":"How a Building Materials Firm Closed Its Catalog Coverage Gap"},"content":{"rendered":"\n

A composite scenario. This story is illustrative, built from how EOS actually works. It isn’t a report on a specific customer, and its quotes are illustrative, not verbatim.<\/em><\/p>\n\n\n\n

The head of sales enablement had assumed the hard part was over.<\/p>\n\n\n\n

Her company had just onboarded a new training platform. She pasted the website URL, and within minutes, reps were practicing against live products. Sessions were running. It felt like a fast start.<\/p>\n\n\n\n

Weeks later, a regional sales manager asked a simple question: “Is the new composite decking line in the system?”<\/p>\n\n\n\n

She checked. It was, sort of. It was sitting on a Pending Approval tab, alongside most of the rest of the catalog, none of it reviewed.<\/p>\n\n\n\n

The platform had auto-approved five core products on day one. Everything else, including the specialty items, the accessories, the regional SKUs, and the breadth of what her reps actually sold, was waiting for someone to click Approve.<\/p>\n\n\n\n

Nobody had.<\/p>\n\n\n\n

This is the story of how a building materials company could discover that a fast onboarding start and full catalog coverage are not the same thing, and what it would do about it.<\/p>\n\n\n\n

The setup: a catalog too large to vet in one pass<\/strong><\/h2>\n\n\n\n

The company manufactures and distributes exterior building products (decking, railing, siding, and trim) through a network of dealers and direct sales reps. Its catalog is enormous: many product families, each with multiple SKUs, finish options, dimensional variants, and regional availability.<\/p>\n\n\n\n

The sales team handles quotes, specs, and project consultations. Every conversation involves product claims: dimensions, load ratings, warranty terms, compatibility with existing systems. A wrong spec can mean a failed inspection, a costly reorder, or a builder who never calls again.<\/p>\n\n\n\n

The platform turns product documentation into practice conversations and claim-level verification. And it did, for the five products it auto-approved on day one. The rest sat in a queue nobody owned.<\/p>\n\n\n\n

The problem: a knowledge base that covered only what got approved first<\/strong><\/h2>\n\n\n\n

The auto-approval logic is straightforward. On first onboarding, EOS approves up to five core products, meaning the customer-facing offerings, not supporting or ancillary items. If a catalog has more than five core products, the system ranks them and selects up to five, and the rest land pending. Supporting items, such as accessories and sub-components, always start pending, whatever the catalog size.<\/p>\n\n\n\n

That auto-approval happens once. It isn’t a standing rule that quietly approves every new item added later.<\/p>\n\n\n\n

For this company, that meant five products were approved and the rest were waiting. Pending products aren’t part of the approved knowledge base. In normal practice, a rep’s claims are checked against approved products only, so a claim about a pending product tends to come back Unsupported. It isn’t marked wrong. It simply has nothing to be checked against.<\/p>\n\n\n\n

Nobody traced it to the queue. The session list didn’t flag which products were still unapproved, so lower product-knowledge results on certain lines read as reps not knowing their products, when part of the cause was that those products had never been approved.<\/p>\n\n\n\n

“We thought we were training on our whole catalog. We were training on five products and hoping the rest would sort itself out. It didn’t.”<\/em><\/p>\n\n\n\n

What the gap looked like in the field<\/strong><\/h2>\n\n\n\n

The first signs came from the field, not the dashboard: quotes that needed correcting on product lines nobody had reviewed, and warranty callbacks tied to coverage terms that reps had stated incorrectly on products that had never been through approval.<\/p>\n\n\n\n

The pending count was visible the whole time. The Pending Approval tab carries a badge, and the Knowledge Hub home view shows approved and pending counts. But no one owned the number, so no one was looking at it.<\/p>\n\n\n\n

\n

Is your catalog actually covered, or just auto-approved?<\/strong> Our 12-page report, Beyond Roleplay: The Rise of the Sales Knowledge Engine<\/em>, covers the architecture behind claim extraction and verification, the same engine that has to keep up with your product list as it grows. [Download the whitepaper \u2192]<\/strong><\/a><\/p>\n<\/blockquote>\n\n\n\n

The fix: a deliberate review process, not a one-click finish<\/strong><\/h2>\n\n\n\n

The company built a review workflow around the way EOS is designed to work. It wasn’t a workaround. It was the process the product supports.<\/p>\n\n\n\n

Assign an owner.<\/strong> Approving or rejecting products requires admin or owner access, so the company made the sales enablement lead the reviewer. The queue now had a clear owner instead of floating between trainers and managers. Trainers could see the review tabs but couldn’t act on them.<\/p>\n\n\n\n

Work the queue page by page.<\/strong> Approve All clears the current page of the pending list, not the entire queue. For a large catalog spread across many pages, that meant using it once per page, not once in total.<\/p>\n\n\n\n

Reject what doesn’t belong.<\/strong> Not every pending item deserved training. Discontinued accessories, duplicate entries, and products the team didn’t actually sell were rejected, which removed them from the queue entirely.<\/p>\n\n\n\n

Watch the badge and the counts.<\/strong> The Pending Approval badge and the approved and pending counts on the Knowledge Hub home view became a weekly check. If the number climbed faster than it was being reviewed, that was the early warning, visible before it became a real gap.<\/p>\n\n\n\n

Treat manual entries as a deliberate shortcut.<\/strong> A product added by hand in the interface is saved as approved immediately, with no pending queue and no review step. The team agreed that only the enablement lead would add products that way, since those entries skip the check everything else goes through.<\/p>\n\n\n\n

The company worked through the queue in batches until it was clear. After that, the process became routine: products extracted from the website or from uploaded documents landed pending and went through the same approve-or-reject flow, and the queue stayed small. When someone edited an approved product, saving triggered a full background resync of that product’s knowledge. The product stayed approved and usable throughout, though very recent edits could take a little while to be reflected in verification.<\/p>\n\n\n\n

What changes once the catalog is covered<\/strong><\/h2>\n\n\n\n

Two things shift once the queue is cleared.<\/p>\n\n\n\n

Claim-level feedback reaches every product line.<\/strong> Reps practicing on specialty decking, regional railing variants, and trim accessories start getting the same kind of verdicts, Correct, Partially Correct, Incorrect, or Unsupported, with the reasoning behind each, that the first five approved products had received from day one.<\/p>\n\n\n\n

The most common errors turn out to be in the long tail.<\/strong> The products that had been sitting in the queue weren’t the flagship items everyone knew cold. They were the specialty SKUs, the regional variants, and the accessories, exactly the items reps are most likely to guess on. Those guesses can finally be checked.<\/p>\n\n\n\n

“The first five products got us practicing fast. That was real. But the value of the platform didn’t show up until every product our reps sold was actually in the knowledge base. Fast start and full coverage are not the same thing, and the gap between them is where the mistakes live.”<\/em><\/p>\n\n\n\n

The takeaway for sales leaders<\/strong><\/h2>\n\n\n\n

If you’ve recently onboarded a training platform and the dashboard looks green, ask one question: how many of your products are actually approved for verification?<\/p>\n\n\n\n

A fast start is designed to get you practicing quickly, with up to five auto-approved core products and sessions running within minutes. That’s the point. It isn’t meant to cover your full catalog in one pass.<\/p>\n\n\n\n

The rest is a deliberate, reviewable process, built for exactly the catalogs too large to fully vet on day one. Knowing where that line sits, and how to move products across it efficiently, is what keeps a large catalog from quietly becoming a knowledge base that only covers what happened to be approved first.<\/p>\n\n\n\n

For a building materials company where a wrong spec can fail an inspection or end a builder relationship, that distinction isn’t administrative. It’s the difference between a training program that covers what reps sell and one that covers what happened to be auto-approved on day one.<\/p>\n\n\n\n

\n

Fast start. Full coverage. Not the same thing.<\/strong> EOS auto-approves up to five core products to get you practicing quickly, then gives you a deliberate, reviewable workflow to bring the rest of your catalog into verified knowledge. Start free with up to 5 seats at app.akaeos.com<\/strong>, or [download the full whitepaper]<\/strong><\/a>.<\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"

Onboarding auto-approved five products. The rest of the catalog sat pending. A composite scenario of how a firm cleared the queue and closed its blind spots.<\/p>\n","protected":false},"author":1,"featured_media":11548,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3642,3640],"tags":[4723,5073,4946,5072,4905,4902,4903,4679,4724,4908],"class_list":["post-11547","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai-en","category-all-en","tag-ai-sales-training","tag-building-materials","tag-case-study","tag-catalog-coverage","tag-knowledge-hub","tag-product-catalog-management","tag-product-training","tag-revops","tag-sales-enablement","tag-sales-onboarding"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t