Home » eProcurement Blogs » Punchout Catalog Blogs » Punchout Purchasing Case Study

Punchout Purchasing Case Study:

Creating a Supplier Punchout

punchout purchasing
John O'rourke

10 Minute read September 2021

Table of Contents

eProcurement punchout catalog

About the Client

A promotional merchandise company with offices worldwide, who had a history of winning large corporate clients. They already had several “punchout” connections to their large customers, and were very familiar with the benefits of integrating directly with customer systems.

The Problem

The client’s sales effort was working very well, and being able to offer their customers a “punchout” or “single sign-on” made it more attractive to larger companies. A “punchout” or “single sign-on” is a technology that lets your customers go from their internal system directly to your website, without having another password to remember.

Setting up these connections was becoming more difficult and costly, because up to this point, each setup was done individually. There was no centralised management or documentation of the different connections. To add to the difficulty, some of the customers had systems that did not use one of the industry standard methods to communicate!

To add another challenge, some customers needed specific “mapping” of the data from one system to another – for example, one customer’s eProcurement system sent a combined “name”, but the e-Commerce system wanted separate first and last names for the users.

The Solution

We created a centralised system which could “speak” all the different standards used by procurement systems. It allowed for plug-in modules so we were able to connect it to different e-commerce systems, such as Shopify, AIM Smarter, and Magento. It connects those e-Commerce websites to procurement systems such as SAP Ariba, Workday, Coupa, Oracle and Ivalua. We then created a central register of all the connections, and a process for the set up of any new clients.

An Example of Punch Out Purchasing

punchout catalog

Outcomes

The sales team were able to remove rekeying of orders for many accounts, and both customers and staff no longer had to worry about creating user accounts and resetting passwords. With the advent of GDPR, this became even more important because it provided assurance to all parties that their employee data was stored and used in a controlled way.

Sales staff now actively talk to customers about integrating with their systems, because everybody in the business understands the value of removing a lot of administrative work.

Setup costs per customer came down, because the system had pre-set configurations for the most common uses. This was even true when some “mapping” was required, such as the first/last name issue described above.

Overall, the system allowed the same team to support a growing number of orders and clients, by keeping administrative overheads down.

The Process

Discovering What’s Needed

The first step was to identify all the different technologies that needed to be supported – these include terms you may have heard, like “REST”, “SAML”, “cXML” and “OCI”. Then we identified all the e-Commerce systems we needed to connect with, and what those connections needed to do.

For example, when connecting to the Magento e-Commerce system, we needed to create new user accounts, create shopping carts, create new orders, and retrieve product information. Most of this could be done on a standard Magento system, but we needed to create an add-on module which would handle creation of new orders.

The last part of the discovery process was making a list of all the “mappings” needed – for example, one connection had to change a 2-letter country code into a 3-letter country code.

Creating a Minimum Viable Product

With systems like this, you don’t know exactly what is needed until people start to actually use it. So in just one month, we created a first draft of the system, and began to migrate the old connections over to it.

In migrating each connection, we discovered new requirements that had not been fully realised before, so already the new system was going to be better for the users than the old system was.

Dealing with Old Corporate Punchout Systems

A recurring issue when integrating with large organisations is that their systems are old. We regularly encountered difficulties with use of outdated security standards and had to create workarounds for that – you can’t just say to a big customer “update your IT systems”!

Iterating and Maturing the System

With each new requirement and each new customer, we added capabilities to the system which had not been anticipated – in one case, a customer’s connection needed to go to two different websites depending on which department the user was from, so we added a menu system.

“Mature” in software terms could mean things like “free of bugs”, “trustworthy” or “reliable”. This system became more trustworthy and reliable because it allowed us to get a clear insight into any issues that came up, and fix them in a proper and permanent way.

One example of this is that we discovered a way of handling errors where, rather than notifying someone in IT each time, it directly emailed the account manager of whichever customer had the issue, and gave them a plain English summary of the problem. This reduced support costs and helped save everybody’s time.

Future-Proofing

We started with the intention of making it easier for our own staff to set up new connections. The intention is to keep “trickling down” the capabilities, so that our client’s IT staff can set up new connections, and eventually perhaps non-IT staff will be able to set up new connections.

Would You like Punchout Purchasing Advice?

Contact Us

We Create Punchout Purchasing for All Systems