How an Asian Packaging Leader Automated Its Sales Operation

The Situation

A packaging enterprise that has been trading for the better part of a century, with four hundred to five hundred employees and four factories today, had built its own quoting and order system in-house, decades ago, and had been extending it ever since. It worked, in the sense that the business ran on it. It also meant that pricing knowledge lived in code no one wanted to touch, that every new material or sheet size was a development request, and that a large sales organization had learned to work around the system rather than through it.

The Requirement

They were not shopping for a modern interface. The requirement was parity, meaning everything the legacy system did, done at least as well, plus the things it had never done: supplier sourcing in the same place, structured customer records, and analytics that did not require an export.

Local business convention set a hard bar of its own. Formal document etiquette and delivery-date conventions had to be exactly right. A quote that gets them wrong does not get read. And with a sales organization this large, migration risk mattered more than any feature list.

Automating the Calculation

The pricing came first. Existing calculation logic was rebuilt as versioned pricing rules, scoped per product and material, composed from ten step types, running over multi-key cost tables keyed on material code, GSM, flute, and sheet size. The regional standard parent-sheet catalogs, with cut-factor math, were already in the engine rather than something to be added.

Parity with a legacy system is only demonstrable if you can compare outputs line by line. Every pricing run produces a step-by-step audit trail, which turned “does the new system agree with the old one” from an argument into a diff. Estimation that had required a specialist's memory became a calculation anyone with access to the pricing rules could reproduce, and changing it stopped being a development request: new materials, sheet sizes, and surcharges are configured in Pricing Studio by the people who own pricing.

The same trail changed profit analysis. Because every quote carries its cost drivers, margin stopped being a quarterly reconstruction. It is visible per quote, per customer, per product line, at the moment the quote is written.

How the Project Actually Ran

Nothing was configured before the operation was understood. The first work was hearing: sitting with the people who quote, sell, and close the books, and mapping what actually happens between an inquiry arriving and an order being invoiced, including the steps that exist only because the legacy system required them.

That map became two documents. A business process map of the operation as it runs, and a feature map putting each step against what Packative One does natively, what needed configuration, and what needed building. Everything after that was scheduled against those two, module by module, rather than against a single go-live date.

The build ran as overlapping workstreams. Calculation was modelled from real samples they had already quoted, then corrected against their own historical outputs. Interfaces and document conventions were localised to how their customers expect to be written to. Integration work connected the production side, so orders, job data and actuals move between Packative One and the systems already running the factories. Training was hands-on, on their own jobs rather than on demo data, and each round of feedback went back into the configuration before the next team joined.

Migrating Without Stopping Sales

There was no big-bang cutover date. Capabilities were switched on for one sales team at a time, and Form Studio let each team's spec capture match what its people already filled in rather than forcing a common denominator. The legacy system stayed available throughout, and the rest of the sales organization kept selling.