Running a Risk Register Review for a Complex Device Account

A risk register review turns a pile of scattered worries about a complex device account into a short list of named items, each with a source, an owner, and a date. For a strategic account manager running a multi site device account, this is one of the more useful conversations you hold each quarter. Handled well, it turns vague unease into a plan both sides can point to. Handled badly, it turns into a blame session or a status update that nobody actually believes.

Why this conversation goes wrong

Most account teams already track risk somewhere, an email thread, a spreadsheet, a note from the last quarterly meeting. The problem is that none of it lives in one place, and none of it has an owner attached. When an operations leader raises a concern weeks after it started, it feels like the account team was hiding something, even when nobody was. The concern usually surfaced somewhere, just never in a form senior leaders actually saw.

The other common failure is treating every complaint as a risk. A contact who is frustrated about a delayed shipment is not the same thing as an open access request blocking a training date. Let every gripe onto the register and the real dependencies get buried under noise, and the whole exercise stops being useful. A risk register records facts that have a next step. It is not a place to record feelings.

This conversation also drifts into an approval discussion or an escalation meeting if you let it. A register review should surface what is open and who owns it next. It should not become the venue where you approve a customer plan or resolve an active service failure. Keep those processes separate, or the register loses its purpose as a coordination tool.

How to prepare

Before you sit down with the customer, pull together every open item from the account plan, service records, pending approvals, training schedules, and any recent data requests. Sort them into a small number of categories instead of one long list. A service dependency, a customer approval still waiting on someone, a question about data or reporting, and an education need cover most complex device accounts.

For each item, write down four things. The issue itself in plain language, the record or conversation that supports it so nobody has to take your word for it, the owner on each side who can actually move it forward, and the date you expect the next update, not the date you hope the whole thing closes.

Decide in advance what this meeting is not for. A live service failure needs your normal escalation process, not a spot on the register. A training date needs a name attached to whoever has to sign off on it, not a vague reference to local approval. The register works because it names dependencies. Anything you cannot name clearly does not belong on it yet.

What to say

Operations vice president Cole opens the meeting the way most of these start. He says, "We keep hearing about problems only after a deadline has already passed. I want to know what is actually outstanding on this account, not what everyone hopes gets resolved."

Account manager Mei shifts the conversation from complaint to structure. She says, "Let's walk through every open dependency in one place. For each one, I want us to agree on the record that supports it, the person who can move it next, and the decision it affects. If we can't agree on those three things, we should call it a question, not a risk."

Cole points to two items right away, an access request that has been sitting with his IT team for three weeks, and a training date for a new unit still waiting on local approval. Mei writes both down as she hears them, then reads each one back. "The access request depends on your IT team's ticket, and it affects whether we can start the phase two rollout next month. The training date depends on a signature from your unit director, and it affects when your staff get certified on the new system." She commits to confirming both next update dates with her service manager and the unit educator by the end of the week, and asks Cole to do the same on his side so neither item goes quiet again.

That exchange works because Mei does not argue with the premise that things have gone unresolved. She also does not turn the meeting into an apology tour. She moves straight into structure, and she makes Cole part of building it rather than someone receiving a report.

Mistakes to avoid

Do not let the register become a running list of complaints. An item with no owner and no next step is not ready for the register, it belongs in a different conversation. Naming something as a risk before you know who owns it just adds noise and makes the whole document less credible.

Do not use the review to approve anything on the spot. Account managers sometimes feel pressure to resolve every item in the room, which leads to promises nobody can keep. The register tracks dependencies. It does not replace the sign off or contract process that a decision like a customer plan actually requires.

Do not skip the evidence source. An entry that says the customer is worried about response times, with no record behind it, will get argued about at the next executive meeting because nobody can point to where it came from. Naming the source, a ticket number, an email, a specific call, keeps rumor out of a discussion senior leaders are going to take seriously.

Do not confuse this review with a security questionnaire or a service escalation. Each has its own process and its own audience, and mixing them stretches the meeting past what anyone can absorb in one sitting. The post on Handling a Health System Device Security Questionnaire covers how to keep that exchange focused on facts instead of assumptions, the same discipline this review depends on.

Practice it before you need it

The best way to get comfortable running this conversation is to build a real register from a current account plan before you sit down with the customer. Pull four entries, one service dependency, one customer approval, one data question, and one education need, and write out the source, the owner, and the next date for each. Have a manager or a peer play the frustrated operations leader and push back on vague answers the way a real customer would.

In coaching, the test is simple. Can the account manager explain every entry's source and next action in one clear sentence, without hedging or reaching for vague reassurance. If not, the entry is not ready, and neither is the rep. Score the practice run on whether ownership stayed specific, whether the account manager avoided turning the meeting into an approval session, and whether they stayed collaborative instead of defensive when challenged.

DealSpeak's Medical Devices practice conversations let you rehearse this exact exchange against an AI counterpart that pushes back the way a real operations leader does, then scores how you handled ownership, evidence, and tone. Running through it a few times before the real meeting is worth more than reading about it. If you also manage open service issues on the same account, the piece on Preparing an Executive Review of Open Device Service Issues walks through a related meeting that often sits right next to this one on the calendar.

A risk register review is not complicated once you separate facts from feelings and give every item an owner. Run it well and it becomes the tool that keeps senior leaders calm between meetings. Run it badly and it becomes one more thing people stop trusting.