The problem it is shaped around
Pricing is the classic spreadsheet job that spreadsheets are bad at. Everybody needs the grid; nobody can say which copy is current; the approval happens in email; and the history of why a price moved lives in somebody's memory.
This application keeps the grid and fixes the other three.
Two sheets, one workbook
The active price list - what you sell and what it costs right now:
| Column | |
|---|---|
| Product and SKU | What it is |
| Category | From the category catalogue, not a typed string |
| Current price | With its currency |
| Effective date and valid until | When this price applies |
| Status | Where this line stands |
The pricing approvals sheet - the queue of proposed changes:
| Column | |
|---|---|
| Product | What is changing |
| Requested price against current price | The proposal |
| Change percentage | Computed, so the size of the move is visible without arithmetic |
| Reason | Why - recorded at the moment somebody knows it |
| Requester and approver | Who asked, who decides |
| Status and approved date | Where it stands, and when it was settled |
A pricing manager works in a grid, the way they always did. The difference is that the grid is a spreadsheet on the platform: live, collaborative, with change history, with lookups into the real product catalogue - and a change can start a process instead of being announced in a message.
Approvals route through the org structure
An approver is not a name typed into a cell. A change routes to the person who owns the unit responsible for it, resolved against the shared org structure the rest of the platform uses.
That is why this application depends on that shared structure instead of carrying its own list of approvers to keep up to date. See AI organisation.
The approved price is the one the rest of the system reads - so a quote, a report and an invoice cannot each be looking at a different number.
What is governed data rather than a sheet
- Products as a data model - what you sell, with its attributes
- Price changes as a fact model - every change with its product, category, currency, date, reason, approver, approving unit, old price and new price
That second one is the quiet payoff: the history of pricing is a dataset, not an audit log nobody can query. Which price moved, how far, why, and who approved it are dimensions of an ordinary analytical model. See Data engine.
- Categories and currencies are master data, edited by an administrator, so a category is one list, not a column people retype three ways.
The dashboard
Three pages, on live data:
- Overview - price-change KPIs, changes by category, changes by reason. That last chart answers a question most companies cannot answer at all: why are we repricing - cost, competition, promotion, correction?
- Price lists - the products view
- History - the full price-change history, filterable
What it is made of
| Part | Built as |
|---|---|
| Active list and approval queue | Two sheets of one workbook |
| Products and price changes | Data models |
| Categories, currencies | Master data |
| Approver routing | The shared org structure |
| Reporting | A three-page dashboard over live models |