How to run a root-cause review with your Italian ICP

Recurring issues are the most expensive kind. A late payslip query, a mismatched contribution code, a missing document for a new hire. Each one gets fixed. Then it comes back next month.

If you manage the relationship with your Italian in-country partner (ICP), you have probably seen this loop. Tickets close. The pattern stays. A root-cause review breaks the loop. It works best when it is short, fixed in format and run on a regular rhythm.

This article describes a single-session format you can run with your Italian ICP. It needs no special tooling. It needs discipline about scope.

Before the session  

Pick one recurring issue. Not a theme, not a list. One issue that has appeared more than once and cost your team time.

Good examples:

• Payroll inputs arriving after the cut-off agreed with the ICP.
• Employee data that fails validation on the Italian side.
• Onboarding documents returned incomplete.
• Repeated questions about the same contribution or collective agreement point.

Bad examples: “communication”, “quality”, “delays in general”. These cannot be reviewed in one sitting.

Send the ICP a short brief in advance. It should contain the issue statement, the affected cases, and the dates they occurred. Ask them to bring the same from their side. Two views of the same cases is the point.

Who attends  

Keep the room small. You need four roles:

• A facilitator from your side, usually the partnership or operations manager.
• A payroll or operations lead from your side who handled the cases.
• A payroll or compliance specialist from the ICP.
• A decision maker from each side who can approve a process change.

If nobody can approve a change, the session produces notes and nothing else.

The agenda  

Run the session in four blocks. Time-box each one and say so at the start.

Block one: agree the facts. Walk through the affected cases in order. Each side states what happened and when. Do not discuss causes yet. The goal is one shared timeline. Differences between the two timelines are often the first finding.

Block two: find the cause. Ask why the issue happened, then ask why again, until you reach something a process or a system controls. Stop when the answer is a rule, a field, a handoff or a missing check. Do not stop at “someone made a mistake”. People make mistakes inside processes that allow them.

Write each cause on a shared page. Mark it as one of three types: input quality, handoff timing, or unclear ownership. Most recurring issues sit in one of these.

Block three: choose the fix. For each cause, pick the smallest change that removes it. A validation rule at the point of entry beats a reminder email. A named owner beats a shared inbox. A structured data exchange beats a spreadsheet sent by hand.

Be wary of fixes that rely on people remembering. They fade within a few weeks.

Block four: assign and close. Every fix gets one owner and one date. Read the list back before anyone leaves. Agree when you will check whether the issue has stopped.

Rules that keep it useful  

Keep blame out of the room. The question is what allowed this, not who did it. Your ICP will bring better information if they are not defending themselves.

Share your own side first. If your platform sends late or incomplete inputs, say so. It sets the tone and it is usually true in part.

Stay on the chosen issue. New topics go on a parking list for the next session.

Do not leave without a decision. If two causes remain open, assign an owner to resolve each before the next check.

What to write down  

One page is enough. Record the issue statement, the shared timeline, the confirmed causes, the fixes with owners and dates, and the check date. Send it to both teams the same day.

Keep these pages together. After a few sessions you will see which causes repeat across issues. That is where a structural change pays off.

Follow-up  

At the check date, look at the data, not at impressions. Did the issue recur? If yes, the cause was wrong or the fix was too weak. Run the review again on the same issue, with the new evidence.

If the issue is gone, say so to the ICP team. Recognition keeps the habit alive.

Where a shared data format helps  

Many recurring issues trace back to the same place: how data moves between your platform and the ICP. Free-form emails and attachments leave room for gaps. A defined data exchange makes missing fields visible early and gives both sides the same record to review.

That also makes the review easier. You are discussing the same fields, not two versions of a story.

Partnership teams that want to see how we structure this can request the data-exchange specification.