Centralized pricing service
In our consulting practice, we speak to many different retailers about their pricing needs. Recently, the requests we have fielded are trending towards what I would term a centralized pricing service. For many years across all industries the trend has been towards specialized services and we seem to have hit that point with pricing in retail.
In retail, we often see three systems that work in conjunction to deliver prices to customers: ERP (Host Merchandising), POS and eCommerce. Prices come from downstream and are aggregated or augmented in the ERP system and are sent out to POS and eCommerce separately. What retailers have found is that the ERP isn’t a very effective tool for managing prices, so they end up externalizing the pricing process in spreadsheets or custom systems.
This is because pricing sits in the void between eCommerce, POS, and ERP / Host Merchandising. Many off the shelf and homegrown eCommerce solutions struggle to handle the volume of data associated with the permutations between channel and location. POS is typically segmented for a single store and ERPs struggle to handle the transaction speed necessary for supporting real time or mass calculations in a timely manner. This leaves enterprise retail pricing out in the cold with a hodgepodge of spreadsheets and custom solutions.
What is driving the need for a centralized pricing service?
- Consistent pricing. Customers are demanding that retailers give them consistent prices on the internet and the store.
- Amazon. Grocery and fashion retailers watched as Amazon decimated other retailers and realize they have to make a change.
- Hyper personalized offers. What used to work as location based offers don’t make sense with multiple channels, so retailers are starting to tie offers to specific customers to inspire loyalty.
Consistent pricing. In many retailers, the eCommerce and POS are typically two disparate systems often with different functionality. Maintaining consistency becomes an exercise in custom code or manual processes that break down. Customers don’t really care what your internal issues are, they just want to be able to go online, see a price, then go into a store and get the same price. And if they have a special deal because they’re a loyal customer, they want to get that same price in the store that they would receive online. It’s not a new or unusual request and it’s been an issue in retail for years. Customers are now getting frustrated and expect it.
Amazon. Amazon has been dabbling in grocery and fashion for years now. Then, they bought Whole Foods and are smack dab in the middle of grocery. At the 2018 SXSW I was in a session where the CTO of Amazon Fashion stood up and questioned a leading fashion retailer. They’re watching, learning, and getting better. It’s inevitable that they will figure it out and retailers need to be prepared. Of course, it’s not just Amazon, grocery and fashion have always had competitive threats. It’s just more pronounced with Amazon encroaching. Competitive and consistent pricing is one way to combat this threat.
Hyper personalized offers. As competition closes in, another tool to entice customers to continue shopping with you is personalized offers. In the past, retailers could offer location based or general coupons for customers. Entrepreneurial affiliates on the internet have rendered general coupons a shared secret that serve to simply lower margins rather than inspire loyalty. Retailers have since turned to coupons or offers that are tied to a particular customer. On top of that, hyper personalized offers push existing systems to their breaking point.
These are just three of the most prominent complexities that are difficult to address with current solutions. So, what would you need from centralized pricing service?
- Fast. If you’re generating files for POS then it has to calculate potentially millions of price changes quickly and if you’re servicing internet requests, it needs to have fast response time.
- Real time and batch interfaces. To serve different channel needs, the system needs to allow real time or batch interfaces. In some cases, some retailers are seriously considering real time interfaces from the POS which would negate the need for batch.
- Pricing system of record. A centralized pricing service needs to be the pricing system of record including day to day pricing, mark downs, promotions, coupons, contracts, and all the history.
Fast. Whether you are enabling real time connections to your POS or generating files that will be distributed to your POS, a centralized pricing solution needs to be fast. Retailers that have hundreds of stores with localized prices can easily scale to millions of calculations. The system needs to be fast so you’re not waiting hours to get your prices out. Without a pricing service, ERP typically shoulders that burden and given the number of calculations needed would take hours to process rendering the ERP unusable during that time.
Real time interfaces. A centralized pricing service would be used for POS, eCommerce, and funneling prices back into your ERP or Host Merchandising system for financial calculations. If your infrastructure can handle it, real time interfaces are the best way to go because then you have the right price from your pricing system of record.
Pricing system of record. If you have a centralized pricing service, it needs to handle all pricing requirements. This includes day to day pricing in grocery, regular price in fashion, hard marks, promotions and coupons. Each of these are different events that change the price. They need to be tracked and historical records kept so that you can reconstruct the price at any point in time. In addition, some retailers have b2b contracts with customers, so the system needs to handle customer pricing for individual products or groups of products.
In conclusion, if you’re finding pricing is spread across several different systems, you’re having to piece it together and you aren’t sure if your POS prices match your eCommerce prices it might be time to consider a centralized pricing service. Leading retailers are trending in this direction and the flexibility a pricing service offers is tantamount to their success.
Pricing service deployment approach
Retail customers have different requirements on how their pricing execution service should behave. Some need it to feed their POS and eCommerce systems whereas others require real-time connections to improve functionality in limited POS systems. The approaches we use are centralized and distributed which translates to real-time execution or batch processing respectively. The decision on which to use depends on many factors including the customer’s intended use of the service, the levels of maturity of the IT infrastructure, and availability of staff. Both approaches have merits and customers must weigh the trade-offs before committing to an approach.
What is the difference between the two? Distributed is when you pre-process most of the prices, store them in a repository such as files or a database table, and then send them to the remote system. This allows central calculation of most of the prices with minimal additional calculations at the local level. Real-time is a service where the function of calculations is offloaded to the external system and accessed through callouts. The advantages and disadvantages of each approach are enumerated below.
· Utilize existing price distribution infrastructure
· Known file interfaces
· Utilize existing operational procedures
· Price authoring infrastructure simpler
· Less flexibility in promotions
· No centralized validation for coupons or loyalty discounts
· Potentially longer deployment time for prices
· Easier consistency across channels
· Quicker deployment time for prices
· Real-time validation of coupons and other promotions
· More complicated infrastructure
· More difficult integration
Often, it might not be a one approach fits all and you can employ both approaches. For example, in hardlines a distributed file would need to be sent to the price tagging system and real-time could be used online for pick up at the curb whereas the POS would also require a price file. What are the reasons to use one approach versus the other? We help customers make the decision by asking pointed questions such as:
- How complicated are your promotions?
- Do you want promotions that are more complicated than your POS can handle?
- How much latency does your network have?
- Can your POS handle real-time callouts?
- How reliable is your network?
For example, you might use a decision tree like this:
This is just one example of how you arrive at the decision. Other factors might be budget, availability of staff, and any number of competing projects that would have an impact on a pricing service implementation.
We have seen an important motivation for using batch processing is that many retailers don’t trust their network. They feel they would like to use real time but their network isn’t reliable enough across all stores, so they need a local presence that can calculate the prices.
Here are some other reasons that would tip the scales one direction or the other:
- Complicated promotions: Complexity of promotions is a factor that could lead a company down the real-time path. For example, if promotions are simple, then it might make sense to pre-process them and send them to the stores in batch. If they are complicated, you might be better off calling real-time because the work involved updating the POS system would be better spent integrating to a centralized pricing system.
- Network reliability: Many retailers are reluctant to use real time connections because they trust their network 99% of the time, but not 100% and the slim chance that the network might go down precludes them from deciding on real time connections. There are hybrid approaches where most of the pricing information is sent to the POS and in case of a network disruption the POS can fail over to the local price files. However, as more and more critical services require reliable connections, the decision to migrate to real-time becomes easier for retailers.
- Validated coupons: Another point of consideration is any promotion that requires validation. For example, single use or customer tied coupons need a centralized system to ensure the coupon hasn’t been used before in another store or a different channel. This can be coupled with a distributed approach for standard promotions and prices so that a real-time callout is only necessary when validating.
- Utilizing existing infrastructure: When determining an approach, sometimes it is easier to get started by using the existing infrastructure and replacing the back end price authoring environment. This might lead customers to choose batch processing where they would be able to duplicate the existing files and limit changes to the distribution framework. By doing this, they would limit the impact on IT given the required code changes, testing, and system upgrades.
In both cases when implementing a pricing service, customers gain centralized control of pricing which leads to reduced errors, better traceability, and quicker execution. Ultimately, a customer will evaluate the objectives of their pricing service which will dictate the approach. Once that decision is made then we focus on the final network topology which we will discuss in the next article.