WKS17 - Pricing Admin and Management
Workshop on to cover pricing administration.
Participants
Name | Company | Role |
|---|---|---|
Teemu Salonen | Valio | Pricing Analyst |
Tomi Toivonen | Valio | Pricing Manager |
Omar Bendada | Ben Consulting Services | Business Analyst |
Sofia Simaria | Ben Consulting Services | Proxy Product Owner |
Alain Becker | Pearson Ham Group | Operation Manager |
Goal
In this workshop we define the processes related to pricing data management.
Workshop materials
Topic | Document | Comment |
|---|---|---|
Lookup tables design | Technical Design Documents ![]() | Walkthrough of lookup tables being designed |
Lookup tables requirements/ideas | Valio Excel ![]() | Walkthrough of lookup tables that Valio has considered in their requirements |
Main results
Payment Terms (List of Values)
This will be a static "list of values" rather than a dynamic lookup table.
Charges
Delivery Charge: Dependent on geographical area (postcode/area ID from customer master data). This requires a lookup table.
Shipping & Small Order Delivery Charges: Not typically dependent on geographical area.
Maintenance: These tables are generally maintained manually. There's a discussion about potentially consolidating different charge types into the same table if the structure allows.
Data Source: Customer master data (postcode) is needed to determine the geographic region ID for delivery charges. There's an open question about how customer master data (child-level in Price Manager) will be aggregated to the parent customer level used in CPQ, which impacts geographical lookup.
Rebates
Yearly Rebates:
Structure: Will involve lookup tables or formulas for calculating thresholds and percentages. The team needs to finalize the formulas and percentages.
Pre-population: The system should automatically populate scales based on deal size.
Maintenance: The underlying lookup table structure for yearly rebates needs to be defined. There's a discussion about whether these scales should be static or dynamically calculated based on deal size, with overlapping ranges.
Marketing Rebates:
Structure: Will not use lookup tables for start/target/floor. The fields will be empty by default, allowing sales representatives to define them.
Maintenance: Sales representatives will play around with the values; no lookup table for guidance.
One-Off Rebates:
Structure: Will include a field for a minimum purchase threshold (e.g., for signing bonuses).
Maintenance: Sales representatives will define the values; no lookup table for guidance.
Through Billing
Structure: Dependent on the supplier.
Maintenance: Will require a lookup table. The fees vary significantly by supplier. This table will be manually maintained.
Data Source: The list of suppliers will be pulled automatically from the Product Master Data to ensure coherence and prevent manual errors. Any new suppliers added to Product Master Data will automatically update the supplier list in CPQ.
Valio Guidance
Current State: Not currently in Zilliant Price Manager.
Implementation: Will be implemented locally in CPQ as a lookup table initially.
Future Integration: If it becomes a dependency for Price Manager's optimization, it should ideally reside in Price Manager, with CPQ looking it up via API. The data structure for this table needs to be defined.
Cost Tables
Existing Customers: Costs will be based on historical data (recent past costs caused by the customer). This data is in transactional data within the BI system and Zilliant Price Manager.
New Customers: Costs will be estimated based on similar business operators' cost structures (e.g., Euros per kilo).
Structure: Will be implemented as lookup tables in the background. Likely structured by product group (Level 3) and potentially customer level (Level 2 for new customers).
Unit: Cost will be represented in Kilos (net weights initially, with a plan to switch to gross-weight kilos if data improves).
Other Relevant Considerations:
Customer Aggregation Logic: A critical open question is how child-level customer master data from Price Manager will be aggregated to the parent customer level for use in CPQ. This needs to be defined in a dedicated session.
Data Coherence: Emphasis on ensuring data coherence across systems, particularly between CPQ and Price Manager/Product Master Data.
API-First Approach: For large datasets like pricing guidance, the preference is to query Price Manager directly via API calls rather than replicating huge tables in CPQ.
Manual Maintenance: Some tables (e.g., certain fees, value guidance initially) will be manually maintained by the business, at least for now.
Build Phase: The team is preparing for the build phase, with initial user stories being planned for the first sprint. The availability of the platform environment is a key dependency.
Documentation Review: The Valio team is expected to review and validate technical documents (User Management, Product List and Catalog, Quote Fields) provided by the development team. Omar did a walkthrough of the technical documentation currently being prepared.
Action list
- Valio team to review and validate technical documents (User Management, Product List and Catalog, Quote Fields) provided by the development team.
- Valio team to define data structure for the Valio Guidance table.
Decisions
List of requirements
Payment Terms Management:
Implement a static "list of values" for payment period options within the CPQ system.
Charges Management:
Develop a lookup table for delivery charges dependent on geographical area (postcode/area ID from customer master data).
Implement functionality to define and apply shipping and small order delivery charges (not geographically dependent).
Support manual maintenance of charge tables within CPQ.
Rebates Management:
Yearly Rebates:
Implement lookup tables or formulas for calculating yearly discount thresholds and percentages.
Enable automatic pre-population of yearly rebate scales based on deal size.
Define the underlying lookup table structure for yearly rebates, considering static or dynamic calculation and overlapping ranges.
Marketing Rebates:
Provide empty fields by default for sales representatives to define marketing support amounts (no lookup tables for guidance).
One-Off Rebates:
Include a field for a minimum purchase threshold for one-off rebates (e.g., signing bonus).
Allow sales representatives to define one-off rebate values (no lookup tables for guidance).
Through Billing Management:
Implement a lookup table for through billing fees, dependent on the supplier and product group.
Automate the pulling and updating of the supplier list from Product Master Data into CPQ to ensure data coherence.
Support manual maintenance of this lookup table within CPQ.
Valio Guidance Implementation:
Implement Valio Guidance as a lookup table locally in CPQ initially.
Plan for future integration with Zilliant Price Manager via API if it becomes a dependency for Price Manager's optimization.
Define the data structure for the Valio Guidance table.
Cost Tables Integration:
Implement lookup tables in CPQ for estimating and incorporating costs into pricing.
For existing customers, base costs on historical transactional data from the BI system and Zilliant Price Manager. > Valio team to populate lookup tables
For new customers, estimate costs based on similar business operators' cost structures (e.g., Euros per kilo). > Valio team to populate lookup tables
Ensure cost data is represented in Kilos (net weights initially, with a plan for gross-weight kilos).
Structure cost lookup tables by product group (Level 3) and potentially customer level (Level 2 for new customers).
Session recording
https://tldv.io/app/meetings/683981b8bf460a0013502438/

