How Sprout turned raw ERP exports into live sales events, with no manual cleanup

Sprout ran its hardware sales cycles as sourcing events in Prokuria, configuring the procurement workflow to run in reverse, because the events engine works in both directions: raw ERP exports went in as they came out, aggregation happened automatically, and preparing an event stopped being spreadsheet work.

Days of consolidation after each event

Settled inside the platform as the event closed

No manual cleanup

Sprout's raw ERP exports imported and aggregated as they came out

One engine, both directions

The same sourcing events, configured to sell rather than to buy

Francisco Urdaneta, Director of Product Monetization at Sprout.

“Helped us turn a complex, manual RFQ process into a faster, more scalable workflow.”

Francisco Urdaneta

Director of Product Monetization

The company

Sprout - a US IT asset lifecycle and disposition (ITAD) company

Sprout is a US-based IT asset lifecycle and disposition (ITAD) company, specializing in enterprise hardware redeployment, resale, and disposition. Inventory and product data were kept in an ERP, and every sales cycle started there.

Moving recovered hardware (laptops, memory, servers) back to market is a fast-moving trade. Stock composition changes constantly, the same part arrives many units at a time, and the buyer base is broad. Taken together, this makes the sell side look a lot like sourcing in reverse: one seller, a large set of buyers, a list that has to reach all of them at once, and responses that have to be comparable when they come back.

The problem

A sales cycle that started with thousands of lines of raw data

Every sales cycle started in the ERP, with an export of the stock going to market. The export ran to thousands of lines, and none of it was ready to send.

  • The list came out line by line. The export recorded stock item by item, while buyers needed one line per product with the quantity rolled up, so identical items had to be collapsed into a single line by hand.

  • Formatting came before selling. Cleaning, reformatting and organizing the export into something sendable took a meaningful share of the cycle, before any conversation with a buyer.

  • The list went out by email: one prepared spreadsheet, sent to the whole buyer base.

  • Responses came back in every possible shape. Each buyer replied in its own format, so nothing could be compared until someone consolidated it by hand into a single master spreadsheet.

  • The team did the comparison work. No system handled the reconciliation step, so the slowest part of the process landed on the desks of the people who knew the products best.

Time was lost at both ends of the cycle, first preparing the list and then normalizing the replies, and that time was missing from pricing, allocation and the buyer relationship.

The solution

How Sprout ran sourcing events in reverse

Sprout used Prokuria’s sourcing events with the roles inverted, cycle after cycle. Sprout was the seller, and the participants invited into each event were its buyers. The events module handles RFQ events and bidding, and it works in both directions. Everything it normally does for a buying team reaching a supplier market, it did here for one selling team reaching its own buyer market.
Diagram of Sprout's sales cycle in Prokuria.

Flows around the events module took out the manual work, and every cycle ran the same short sequence:

  • The ERP export went straight in. A custom import module was built for that specific file, so the export could be uploaded as it came out of the ERP, and the platform mapped its columns with no reformatting step.

  • Aggregation happened at event creation. Imports were selected into a new event, and identical products were rolled up into single lines automatically, so the sellable list was produced inside the platform.

  • The event went out in Excel. Buyers received the event by email as a spreadsheet, filled in the file and replied with it attached. They kept working in a format they knew, and every response came back in the same structure.

  • Evaluation followed the team’s rule. A custom evaluation model scored the responses against the team’s own allocation rules, and the platform proposed a result the team could accept or override.

  • Management got a report in its own format. A custom Excel report took the evaluation outcome out of the platform in the layout the business wanted to read.

A team of product specialists ran the events, each covering a product line.

This is where Prokuria tends to differ from a standard suite. Prokuria is configured without code, so the workflow follows the process a team already runs. Where the standard models did not cover the process, we built two pieces for this engagement: an import written for one specific ERP file, and the team’s own allocation rule.

The results

Event preparation down to minutes, and days removed from each cycle

Preparing an event went from hours of spreadsheet work to minutes. The larger saving came after the responses were in: the consolidation and comparison work that used to take days of the cycle happened inside the platform as the event closed.
Before and after comparison of Sprout's event preparation.

Beyond the time saved, three things changed:

  1. Both ends of the cycle lost their slowest step. Turning raw stock data into a sellable list stopped being manual work, and so did turning the responses back into something comparable.

  2. The allocation rule lived in the system. The logic was written into the evaluation model and no longer rebuilt from scratch each time, so any decision could be reviewed and repeated, whoever ran the event.

  3. Specialists spent their time on product. The people who knew the categories ran the events, and the preparation overhead came off their desks.

Achieving operational excellence with Prokuria's flexibility

Sprout ran a sales process on a sourcing platform, and it worked because the events engine runs in both directions and the workflow is configured rather than coded. That is what carried Sprout’s cycles: the seller in the buyer’s seat, a buyer market in place of a supplier market, source data straight out of a proprietary ERP export, and an allocation rule that belonged to the company.

What the configuration made possible: every cycle started from the raw export instead of a rebuilt spreadsheet, the whole buyer base received the same list at once, responses came back comparable by construction, and the allocation rule ran in the system. Two pieces were built for the engagement, the import and the evaluation model, and they were built around the process. Configuration covered the rest with no code.

What our customers say about us

We know each company is different

That’s why Prokuria flexes to fit your process, with no code, no IT consultants, and no long implementations. You’re up and running at a fraction of the cost.

Ready to take control over your procurement process?