The person using a digital product is not necessarily the person choosing it, approving it, paying the invoice or receiving the largest economic benefit.
That distinction changes product design, positioning, pricing units, package boundaries, sales content, onboarding, security requirements, the evidence you need at renewal, and which side of a marketplace should be the one paying.
Charging the person who benefits is only correct when that person also controls a budget. Where they do not, the product has to be sold twice — once to the user and once to whoever signs.
A founder who interviews enthusiastic users but never reaches the budget owner can mistake adoption interest for demand. A product priced per user can suppress collaboration even when the company—not each user—captures the value. A marketplace can charge the scarce side and prevent liquidity before a transaction is ever created.
Before deciding how much to charge, map who participates in value creation and purchase.
The stakeholder roles
The same person can hold several roles. Keep the labels separate because each role answers a different question.
| Role | Core question | Typical concern |
|---|---|---|
| User | Who operates or experiences the product? | Ease, speed, workflow and reliability |
| Beneficiary | Who receives the outcome or economic gain? | Result, risk reduction or strategic impact |
| Champion | Who actively promotes adoption internally? | Credibility, implementation and personal success |
| Buyer | Who evaluates and chooses the offer? | Fit, alternatives, terms and expected return |
| Budget owner | Whose budget funds the purchase? | Priority, total cost and measurable impact |
| Payer | Which person or entity transfers the money? | Invoice, tax, currency and payment process |
| Approver | Who can authorize or block the purchase? | Risk, policy, legal, security and compliance |
| Administrator | Who configures and governs access? | Control, integration, permissions and support |
| Customer | Which relationship does the company promise to serve? | The combined experience across purchase and use |
“Customer” is useful in everyday language but too broad for product decisions. State the precise role when discussing evidence.
Instead of saying “customers want SSO,” say:
- security approvers require SSO before they permit deployment;
- administrators need centralized access control;
- end users do not mention SSO in workflow interviews;
- the budget owner accepts an enterprise package because SSO reduces governance risk.
That description reveals why the capability matters and who will pay for it.
Four common role configurations
1. One person holds every role
A solo designer buys an application with a personal card, uses it daily and benefits directly.
The purchase can be self-serve because: the user recognizes the problem, value is personally observable, one person controls the budget, risk is limited and payment needs little coordination.
A clear landing page, trial and card checkout may be enough. Per-user pricing can feel natural because the user and payer are the same.
2. A manager buys for a team
A support manager chooses software used by 20 agents. The manager owns service metrics; finance pays; IT approves the integration.
Here:
- agents care about workflow speed;
- the manager cares about resolution time and quality;
- finance cares about total cost and contract terms;
- IT cares about security and maintainability.
The product needs user adoption and managerial evidence. A successful trial with three agents is not enough if it cannot demonstrate team-level impact or pass technical approval.
3. A central buyer purchases for distributed users
A company licenses compliance training for all employees. Procurement negotiates the contract, HR administers it and employees complete the content.
The economic beneficiary may be the organization through lower risk, even when individual users do not actively seek the product. Packaging can reasonably use employee bands, locations or annual coverage rather than active-user behavior alone.
4. Different sides create and consume value
A marketplace connects clients and specialists. Sellers create supply; buyers bring demand; the platform provides discovery, trust, workflow and payment protection.
Charging decisions affect both sides:
- a seller fee can reduce supply;
- a buyer fee can reduce transaction conversion;
- commission can align payment with success;
- subscriptions can work for frequent professional participants;
- promoted placement can monetize attention but damage relevance.
The “customer” is not a single obvious person. The platform must manage an economic system.
Why role confusion damages monetization
You research the wrong problem
Users describe friction in tasks. Buyers discuss budget priorities and alternatives. Approvers discuss risk. Asking one role to predict another produces unreliable answers.
An end user may say the company will certainly pay €20 per seat but have no knowledge of procurement thresholds. A finance buyer may demand analytics that managers never use. Both statements are evidence, but each is evidence about a different role.
You choose the wrong value metric
Per-seat pricing is easy to implement, yet it can conflict with value when:
- many occasional participants contribute to one workflow;
- viewers or guests increase the paid team's outcome;
- automation reduces the number of active users;
- the beneficiary is a workspace, store or business unit;
- only a small operator group uses a system protecting the whole company.
Conversely, a flat company fee can undercharge when adoption expands from one team to thousands of users and creates support, governance or infrastructure cost.
You communicate one generic benefit
“Save time” might appeal to a user but be too weak for a budget owner. “Centralized governance” may appeal to an approver but sound irrelevant to a daily operator.
A coherent offer can use different proof for each stakeholder without changing its core promise.
You mistake free adoption for paid demand
Users can love a tool while the organization sees no budget-worthy outcome. This often happens when:
- the benefit is personal convenience rather than organizational impact;
- the user cannot quantify the result;
- a free substitute is acceptable to the buyer;
- adoption creates unmanaged risk;
- the product does not reach the person with authority.
Activation validates usability and some value. It does not automatically validate purchase.
You reach renewal without evidence
The original champion may leave. Finance sees only an invoice. Users report activity but not impact. Without role-specific evidence, a useful product can still be cancelled.
Renewal design should begin during onboarding, not 30 days before contract expiry.
The stakeholder map
Create one row for every material role in the purchase and use journey.
| Role | Person or function | Desired outcome | Current alternative | Objection or risk | Evidence needed | Influence |
|---|---|---|---|---|---|---|
| User | Support agent | Resolve cases faster | Existing help desk and manual search | Another tool adds steps | Workflow time before/after | Medium |
| Champion | Support operations lead | Improve consistency | Training and documentation | Rollout could fail | Pilot adoption and quality | High |
| Budget owner | Head of support | Lower cost per resolution | Hire more agents | Savings may be uncertain | Volume-adjusted ROI | High |
| Approver | Security | Protect customer data | Reject new vendor | Data access and retention | Security documentation | Blocking |
| Payer | Finance entity | Correct, predictable invoice | Purchase order process | Variable bill | Annual cap and tax details | Medium |
Add actual names when working on a real opportunity. A generic persona cannot replace account-specific mapping in a complex sale.
Questions for every role
- What outcome does this person own?
- How is that outcome measured today?
- What do they lose if nothing changes?
- What new risk does adoption create for them?
- Which alternatives do they compare?
- What authority can they exercise?
- What proof makes a decision safer?
- At which stage must they participate?
The economic beneficiary
The economic beneficiary is the person or entity whose finances, risk or strategic position improves.
The benefit that justifies payment can be new revenue, lower labour or supplier cost, avoided loss, faster cash collection, increased capacity, reduced compliance exposure, better asset utilisation, higher retention, or shorter cycle time.
Whichever it is, the buyer has to be able to say it in their own words to someone above them. A benefit only you can articulate does not survive the approval meeting you are not in.
The beneficiary is often a strong candidate for budget ownership, but not always. Budgets follow organizational structures, historical categories and internal politics as well as value.
Quantify the value pathway
Connect product behavior to an organizational result:
Product capability → user behavior → operational change → business outcome → financial value
Example:
Suggested support answers → agents find information faster → average handling time falls → the team handles more cases without adding headcount → support cost per case declines.
Each arrow is an assumption to test. If agents see suggestions but ignore them, the pathway breaks before financial value appears.
Avoid invented ROI
Do not multiply optimistic time savings by a fully loaded salary and call the result guaranteed savings. Ask:
- Is saved time actually available for other valuable work?
- Does the team reduce overtime, contractors or future hiring?
- Is the measured change attributable to the product?
- Does quality remain stable?
- How frequently does the workflow occur?
Use ranges and disclose assumptions. Credible modest evidence is more useful than an inflated calculator.
The real buyer and budget owner
A user may not know who can approve a purchase. Ask process questions rather than “Are you the decision-maker?”
Useful questions include:
- How was the last comparable tool purchased?
- Which cost center would fund this?
- Who owns the metric this product changes?
- Who signs below €5,000, €25,000 and €100,000?
- When does procurement become mandatory?
- Which stakeholders can block deployment?
- Is budget already allocated or must it replace something?
- Who needs to see the pilot result?
- What date controls the next planning cycle?
The strongest confirmation is behavior: the user introduces the budget owner, schedules a joint review or helps build a business case.
Budget source shapes the offer
The same product can be evaluated differently depending on budget:
- an innovation budget may fund a pilot but not renewal;
- an IT budget emphasizes consolidation and security;
- a departmental operating budget emphasizes workflow outcomes;
- a marketing budget may require campaign attribution;
- a capital budget may prefer licensing or long commitments;
- a personal card requires simple self-serve terms.
Knowing the budget explains the alternatives and proof standard.
The payer as a separate role
The payer is the legal person or entity that actually transfers the funds, and payment can fail after the buyer has approved: an unsupported currency, missing tax information, card limits, purchase-order requirements, invoice terms, vendor onboarding, cross-border restrictions, a mismatch between entities, payment-method policy, or data-processing terms.
Vendor onboarding is the one that costs weeks. A deal agreed in October can sit unpaid until January because nobody started the supplier registration.
For small purchases, buyer and payer may be the same. For enterprise contracts, collection is a workflow with its own lead time and operational cost.
Map the contracting entity, the invoicing entity, the billing contact, the payment method, the currency, tax treatment, any references the invoice must carry, the payment term, and the renewal and notice rules.
Required references are trivial and block payment completely. An invoice without the purchase-order number goes back to you, not into the payment run.
A signed deal is not cash, and cash received is not necessarily recognized revenue. Forecast accordingly.
Who should pay
The payer should not be selected only by asking who receives any benefit. Consider willingness, ability, market dynamics and collection feasibility.
Use this scorecard:
| Criterion | Question |
|---|---|
| Economic value | Does this side receive measurable financial or strategic benefit? |
| Ability to pay | Does it control an appropriate and reachable budget? |
| Willingness to pay | Does the alternative cost enough to motivate purchase? |
| Scarcity | Would charging this side damage the scarce resource needed for the product? |
| Price sensitivity | How strongly will a fee reduce adoption or transactions? |
| Attribution | Can value be connected credibly to the product? |
| Collection | Can payment be enforced and processed efficiently? |
| Retention | Does paying reinforce or undermine continuing participation? |
Subsidize one side deliberately
Free does not mean valueless. One side may be subsidized because its participation creates the product's value.
Examples:
- viewers join a collaboration tool free while creators pay;
- candidates join a talent marketplace free while employers pay;
- consumers use a comparison service free while providers pay for qualified leads;
- developers use an open-source core free while companies pay for operations and governance.
The subsidy should have a reason and a limit. Track the cost of serving non-paying participants and the value they create for paying participants.
Avoid charging the constrained side too early
In a marketplace, the scarce side often limits growth. Charging it before liquidity or value is proven can deepen the shortage.
Scarcity can change. Early on, quality sellers may be scarce; later, buyer demand or specialized matching capacity may become the constraint. Revisit the policy using cohort and liquidity data.
An offer for all critical stakeholders
One offer can contain role-specific elements.
For the user
Demonstrate: faster or easier workflow, low switching effort, reliability, compatibility with existing tools and control and recoverability.
Measure activation and retained use.
For the champion
Provide: pilot plan, internal presentation material, rollout checklist, success metrics, stakeholder FAQ and visible implementation support.
Reduce the personal risk of recommending the product.
For the buyer and budget owner
For the buyer, show the business outcome, total cost, credible alternatives, time to value, the economic assumptions behind it, the contract scope, and the criteria on which renewal will be judged.
Naming the alternatives yourself is stronger than waiting to be asked. It shows you understand the decision they are making rather than the one you would prefer.
Make the decision defensible internally.
For approvers
For the reviewers, prepare security and privacy documentation, data flow and retention, accessibility evidence, legal terms, service levels, integration and identity controls, and the exit and data-export process.
The exit process belongs in the pack that wins the deal. A reviewer who can see how to leave is a reviewer who can approve joining.
Do not force the user to invent answers.
For administrators
For whoever will run it, clarify the deployment steps, permissions, account ownership, usage reporting, support escalation, provisioning and deprovisioning, and audit capabilities.
Deprovisioning is the question an administrator asks first and vendors answer last. It is the task they will perform most often after the launch.
Administration burden affects renewal even when users like the product.
Pricing and the real distribution of roles
Per-seat pricing
Per-seat pricing works when:
- each active user receives substantial direct value;
- individual access drives variable value or cost;
- seats are easy to define;
- buyers expect software to be budgeted by headcount.
It is weaker when wide participation creates network or workflow value. Consider free guests, active-seat billing, role-based seats, workspace pricing or a base platform fee.
Per-workspace or per-account pricing
This fits shared outcomes and collaborative units. It gives predictable spend and encourages invitations, but requires limits or packages that capture expansion among larger organizations.
Usage-based pricing
This can align with operational activity even when the payer is not the user. Give administrators visibility, budgets, alerts and caps. The budget owner must understand the unit and expected range.
Enterprise licensing
Annual licensing can fit centralized purchase, broad deployment and governance. Pricing may reflect business units, employees, locations, volume commitments or strategic scope rather than a public per-user amount.
Services and implementation
A separate fee can recover non-recurring onboarding work. Explain which stakeholder receives the service and what deliverable marks completion. Do not hide mandatory implementation behind an apparently self-serve price.
Run role-specific discovery
Interviewing ten users is not equivalent to interviewing the buying system.
User interview
Explore: current workflow, frequency and severity of friction, existing tools and workarounds, adoption barriers, moments of value and reasons to return or stop.
Champion interview
With the champion, explore urgency, the internal narrative they will use, the stakeholders involved, rollout risk, pilot design, success criteria, and what this means for them personally.
The last one is not cynical. Someone is spending their credibility on your product, and knowing what they gain or risk tells you how much help they need.
Buyer or budget-owner interview
Explore: strategic priority, budget source, alternatives, economic threshold, contract expectations and evidence needed to approve and renew.
Approver interview
Explore: mandatory requirements, review sequence, risk classification, documentation, non-negotiable blockers and typical review duration.
Compare answers. Misalignment is a product and go-to-market risk worth solving explicitly.
A 21-day stakeholder validation experiment
Week 1: map the current system
- Interview at least five active or target users.
- Ask each person to describe a real purchase process.
- Map user, beneficiary, champion, buyer, budget owner, payer and approvers.
- Record uncertainty rather than filling gaps with assumptions.
- Choose one segment where the role configuration is reasonably consistent.
Week 2: build a role-complete offer
Give the champion a user workflow demonstration, a one-page business case, the package and price, the pilot scope, a security or operational summary, invoice and contract assumptions, and explicit success criteria.
One page is the constraint that matters. The champion will forward it, and what gets forwarded is what gets read.
Present the relevant part to each stakeholder. Ask the champion to involve missing roles.
Week 3: request commitment
Seek behavior appropriate to the sales stage: access to pilot users, data or integration approval, budget-owner meeting, security review, signed pilot proposal and deposit or payment.
Track where the process stops. A product demo accepted by users but blocked before budget review points to a different problem than a proposal rejected for weak ROI.
Metrics to track by role
| Role | Useful signals |
|---|---|
| User | Activation, task completion, frequency, retention, satisfaction by workflow |
| Champion | Introductions made, pilot participation, rollout completion, internal response |
| Buyer | Proposal acceptance, sales-cycle stage, objections, competitive outcome |
| Budget owner | Approved amount, discount, budget source, ROI threshold, renewal decision |
| Approver | Review duration, blockers, exception count, approval rate |
| Administrator | Setup time, support tickets, provisioning accuracy, governance adoption |
| Payer | Invoice acceptance, payment time, failure rate, dispute rate |
| Beneficiary | Operational and financial outcome, confidence of attribution |
Do not let high user activity hide a blocked buying process, or a signed contract hide failed adoption.
Common mistakes
Assuming the champion has authority
Enthusiasm and authority are different. Help the champion navigate the process, but verify budget and approval directly.
Building only for the buyer
A product can win a contract and fail in use. Shelfware damages renewal and reputation. User value remains essential even in top-down sales.
Building only for the user
A delightful workflow may never receive approval if it creates security, governance or financial problems. Product quality includes adoptability by the organization.
Charging every participant
Viewers, guests, suppliers or occasional collaborators may increase value without justifying a full paid seat. A rigid rule can reduce the network needed by paying users.
Calling all non-paying participants leads
Free users may be product participants, supply creators or beneficiaries rather than future buyers. Assign a role and measure the economic contribution honestly.
Ignoring stakeholder changes
Champions leave, budgets move and executives change priorities. Build multi-threaded relationships and store renewal evidence in the account, not only in one person's inbox.
Using one ROI story for everyone
Users, managers, finance and security evaluate different risks. Keep one truthful value pathway, but provide proof relevant to each role.
Decision checklist
Role clarity
- We distinguish user, beneficiary, champion, buyer, budget owner, payer and approver.
- We know which roles are combined or separate in the target segment.
- Real interviews or opportunities confirm the map.
- We know who can block adoption and payment.
Value and evidence
- Users receive a repeated or meaningful outcome.
- The economic beneficiary can observe a business result.
- The value pathway states its assumptions.
- Renewal evidence will be collected during use.
Offer and pricing
- The value metric does not unnecessarily obstruct adoption.
- Package content addresses required user and organizational needs.
- The budget owner can understand total expected cost.
- The payer can complete the required process.
- Subsidized participants create measured value for the system.
Sales and onboarding
- Discovery reaches more than enthusiastic users.
- Champions have material for internal alignment.
- Approver documentation is available before it becomes urgent.
- Pilot success criteria matter to the renewal owner.
- Administrators can deploy and govern the product.
Know who actually pays
Monetize the value system, not an assumed generic customer.
Identify who uses the product, who benefits economically, who promotes it, who chooses it, who owns the budget, who can block it and who transfers the money. Then design a product experience users adopt, an argument buyers can defend, terms payers can execute and evidence beneficiaries can use at renewal.
When those roles align, pricing becomes easier to understand and revenue becomes more durable. When they do not, lowering the price rarely solves the underlying problem.