Fixed-fee vs per-ticket support models for ICP services

Every EOR and payroll platform that works with a local partner has to decide how to pay for support. The choice looks like a pricing detail. It is really a choice about behavior. The model you pick shapes what the partner does when a case is hard, when a case is boring, and when a case could have been avoided.

This article compares fixed-fee and per-ticket models for ICP services in Italy. It looks at incentives first, then at quality outcomes. It gives no price points. Those depend on your scope and volume.

What each model pays for  

A per-ticket model pays for activity. Each request that reaches the partner creates revenue. A payslip query, a social security question, a document request: each is a unit.

A fixed-fee model pays for availability. The partner is paid to keep a defined service running. The number of requests does not change the fee.

That difference sounds small. It is not. Each model rewards a different kind of work.

Incentives under per-ticket pricing  

Per-ticket pricing is easy to explain and easy to audit. You pay for what you use. Finance teams like it because cost tracks volume.

The weakness is that the partner earns more when you have more problems. A partner that fixes a root cause reduces its own revenue. A partner that answers each repeat question one at a time keeps it. Few partners act in bad faith. But incentives work without anyone intending them to. Over time, the process drifts toward handling tickets, not removing them.

There are other side effects:

• Ticket definitions become a negotiation. Is a follow-up a new ticket or part of the old one? Is a bundled question one ticket or several?
• Your own team learns to hold questions back to save cost, or to split them to get faster answers. Both distort your data.
• Complex cases are the most expensive per ticket, and the ones where you most need the partner to spend time. Pricing by count does not reflect effort well.
• Quiet periods leave the partner with little revenue. That makes it hard to keep experienced people assigned to your account.

Incentives under fixed-fee pricing  

Fixed fees reverse the pressure. The partner now benefits from fewer, cleaner requests. Every avoidable question costs them time and brings no extra income. So they have a reason to fix templates, correct data at the source, and write clear guidance for your operations team.

That is the good case. The bad case is also real. A partner paid the same amount whether they do much or little may do the minimum. Slow responses, thin answers and unclear ownership are the typical symptoms. The fee can also be set too high or too low at the start, and then nobody wants to reopen it.

Fixed fees need the service to be defined well. Without a clear scope, response targets and reporting, you are buying a promise, not a service.

Quality outcomes compared  

The two models tend to produce different quality profiles.

Responsiveness. Per-ticket partners often respond fast, because each response is billable. Fixed-fee partners need response targets in the contract to hold the same line.

Depth of answers. Fixed-fee partners can afford to spend time on a hard case. Per-ticket partners may close it quickly and wait for the follow-up.

Prevention. Fixed-fee models favor prevention. Per-ticket models favor resolution. If your pain is recurring errors, prevention matters more.

Predictability. Fixed fees make budgeting simple for the platform. Per-ticket costs rise exactly when you onboard many new employees or hit a regulatory change, which is when you want the least friction.

Data quality. In a per-ticket model, ticket counts become the main metric. They measure workload, not outcomes. In a fixed-fee model, you are forced to define outcome measures: errors found, time to resolution, repeat issues.

A hybrid that works  

Most platforms end up between the extremes. A common structure is a fixed base fee for a defined scope, plus a per-case charge only for work outside that scope, such as a special project or an unusual request. The base fee covers routine support and prevention. The variable part covers real exceptions.

For this to work, three things must be in place.

1. A written scope that names what counts as routine.
2. Service targets tied to outcomes, not just to response time.
3. Shared reporting, so both sides see the same categories of request and the same trends.

Without the third point, the other two decay. Disputes about what a ticket is, or what is in scope, usually come from each side keeping its own records.

How to decide  

Use these questions.

• Is your request volume stable or spiky? Stable volume suits fixed fees. Spiky volume may need a variable element.
• Do you want the partner to improve your processes or only to answer? If improve, avoid pure per-ticket.
• Can you measure outcomes today? If not, a fixed fee is risky until you can.
• How mature is your scope? A new market with unknown demand may start per-ticket and move to a fixed base once patterns are clear.

The common mistake is to treat the model as a procurement choice made once. It is better treated as a setting you review. Volumes change, scope changes, and the incentive that worked at launch can work against you later.

What this means for operations  

Whichever model you choose, the operational test is the same. Look at what your partner does with a repeated question. If they answer it again, your model rewards repetition. If they come back with a fix, it rewards improvement. Pay for the behavior you want to see.

Partnership teams that want to compare models on real data need a shared structure for requests, categories and outcomes. We have defined one for ICP services in Italy. Partnership teams are welcome to request the data-exchange specification.