Our onboarding team estimates a Claromentis Enablement Hub rollout needs at least 47 combined hours from your team over eight weeks. Policy reviews, identity work, and staff training come on top. Before you sign, name four roles, agree what goes live first, and get your onboarding scope and cost in your proposal. Keep your old policy repository open for anything that isn't ready to move. Before launch, check that staff at each site can find the right policy on the device they use on shift. Then set aside a little admin time every month.
You've chosen your healthcare intranet software. The contract is nearly signed. Now someone on your team has to build it.
And that person already has a full-time job.
If you're the IT director at a community hospital, or the operations lead who'll run your new healthcare employee intranet day to day, you need three answers before you sign: how many hours this takes, whose hours they are, and what's most likely to stall it.
Most implementation stories skip straight to the launch announcement. They rarely mention the weeks of work it took to get there.
This guide shows you what to expect from a healthcare intranet implementation, using our own onboarding process and a fictional community hospital as an example.
In this article, I'll show you the four roles to name before kickoff, how to estimate your team's hours, and an eight-week walkthrough at a fictional hospital. Then I'll cover the cleanup, permissions, and after-launch work that's required, and how to decide whether your first phase is worth the effort.
Before you start your onboarding and intranet implementation, pick the people you want to work on it. In our experience, four roles keep a rollout moving.
Name who fills each one before your first call. You'll need:
A small team can combine some of these roles. Try to spread them across several people, though, and give each one a named deputy. If one person takes on all four, the rollout stops every time they're on leave or covering a shift.
As Claromentis partner, Harsh Divecha, says "The people who own the process own the platform", so keep that in mind. Harsh spent several years administering Claromentis for more than 850 users at a multinational healthcare group, so he knows what he's talking about.
Once you know who's involved, you can work out how much of their time you'll need.
For Claromentis Enablement Hub, our onboarding team estimates 47 combined hours from your team over eight weeks, roughly one working day a week. Here's how those hours split between your team's work and ours:
That's a rough minimum to help you plan. Use our Hours worksheet in our pre-kickoff onboarding checklist to estimate your own.
It also counts each call once, so if three people join a one-hour call, that's three hours of your team's time. The same goes for training.
Then budget extra time for the work the estimate doesn't itemize:
Your numbers will go up if you have a large policy library, several sites, or custom work. So we'll scope the hours with you before you sign.
Okay, now we know who is participating, and how long it's likely to take. Let's walk through an example based on a fictional 120-bed community hospital with two outpatient clinics and about 600 staff.
Before kickoff, the hospital's team agrees exactly what will go live in week 8:
With that agreed, the five onboarding stages look like this. The last column is a simple test: once the hospital can tick it off, it's ready for the next stage.
Pay particular attention to the week 7 test. Before you launch, ask a small pilot group at each site, such as a nurse, a front desk colleague, and someone from environmental services, to open the intranet on the phone or workstation they'd normally use on shift. Then ask them to find the current version of a policy that applies to their site, and tell you who owns it or what they'd do next.
If they can do that, you know staff can log in, find what they need, and see who to ask. A login test on its own won't tell you all three.
What you do next depends on what's holding you up.
If staff at one of your sites can't log in, move the launch date. People who can't log in can't use anything, so there's no point going live until access works everywhere.
If some policies aren't approved yet, launch anyway with the ones that are, and move the rest to Phase 2.
But your staff still need to find every current policy in the meantime. So before launch, agree a few ground rules for wherever your policies live today, whether that's SharePoint, a shared drive, or an old intranet:
And if an essential policy isn't ready, such as one covering a high-risk task, its current approved version stays in the old repository, linked from the new library. If staff can't reach an approved version anywhere, that part of Phase 1 isn't ready, so it waits until the policy owner approves a version staff can open.
In our experience, two jobs go much more smoothly when you start them early: cleaning up your content, and deciding who can see what.
It's tempting to move every document across as it is and tidy up later. But move outdated policies into a new intranet, and you've got the same old mess in a nicer-looking home.
Your staff will notice, too. One travel nurse on Reddit described being asked to acknowledge 281 policies during onboarding: "Maybe 20% of them pertain to me."
So before anything moves, give every policy an owner and a review date, and decide whether it stays, merges with another policy, or goes.
The easiest way to do this is a simple spreadsheet with one row per document. For each one, note who owns it, when it was last reviewed, which sites and staff it applies to, and what you've decided to do with it. A few rows might look like this:
For Enablement Hub, if you're on SaaS, onboarding includes a bulk document migration that meets three conditions:
Bigger or more complex migrations are handled as custom requests. And if you host on-premises, your team runs the migration itself, using a step-by-step guide from our knowledge base.
Policies can come across with more detail. Policy Manager has its own bulk policy import: you prepare the policy files and a spreadsheet listing each one's title, category, owner, author, and review date, then raise a change request with us. We'll estimate the work and help you with the import. Add a category and a next review date to your cleanup spreadsheet, and you've done most of the preparation already.
Your users need to be on the intranet first, because the owner and author fields link to real people. So get your user sync, or your manual accounts, working before you prepare the import.
And take the time to get those review dates right. Policy Manager reminds the owner and author 15 days before each review date, and again on the due date, so the dates you add now are what keep your policies current later.
Also, if some of your sites follow their own local procedures, decide which policies apply across the whole organization before you merge anything.
Next, decide who should be able to see, edit, and approve what.
This takes careful thought on any platform, ours included. One G2 reviewer, from a staffing company, put it bluntly in January 2026: "permissions were cumbersome."
Fortunately, most of the work is deciding who belongs in which group. Build your groups from three things your directory already knows about each person: their role, their department, and their site. Then give each group access to the right pages, policies, and courses.
At our fictional hospital, a few of those groups might look like this:
Try to agree your groups by the end of week 2. Your directory sync, your policy library, and your training assignments all depend on them.
Your team builds and runs the intranet, and we guide, train, and support you along the way. Task by task, the work splits like this:
Our standard support covers your administrators, but not end users or product training. If a staff member needs a ticket raised, one of your admins submits it for them. So in practice, your admins become the first place everyone else goes with questions.
If you host on-premises, a few of these rows change, so check them for your setup.
Eight weeks is a guideline. Your user count, a large policy library, custom development, slow progress through training and feedback, or a weekly build session that keeps getting cancelled will all stretch it. So will a late decision on SSO, because staff can't use anything until they can log in.
Healthcare brings its own pressures too. An accreditation survey, an EHR upgrade, or flu season can each pull your platform owner away for weeks. So check your calendar for all three before you pick a kickoff date, and protect that weekly build session once it's booked.
Once you've launched, the day-to-day upkeep begins. Policies come up for review, new people join, others change roles, and departments ask for new pages.
A simple routine helps you keep on top of it.
As it happens
Your system admin owns these changes, whether they come through user sync or by hand.
Every month
Every quarter
Set aside time for this in your platform owner's week. How much depends on your sites, staff turnover, and how often your policies change, so agree a figure for your organization when you scope the project.
When something breaks, your admins raise a ticket in Discover. For a P1 issue, our support targets are a 2-hour response and an 8-hour resolution within stated business hours.
Good support should also leave your admins more capable. One of our US healthcare customers described a recent ticket like this: "Hannah implemented the fix for me, and then showed me how to edit or adjust it as needed in the future."
And many of our US healthcare relationships last for years. Emergency Physicians of the Rockies has used Claromentis across seven emergency departments since 2014, and Medcor since 2016.
Before you sign, put what you've worked out into a one-page decision note for whoever approves the spend.
Keep it short. It should show the staff task you're improving, what Phase 1 replaces, the admin work you'll keep, what you're leaving for later, and what the proposal still has to confirm. Then end it with one of three answers: go, revise the scope, or wait.
Here's a completed note for our fictional hospital. Copy the left-hand column to start your own.
Waiting is a sensible answer too. If nobody can take on the platform owner role this quarter, or an EHR upgrade lands in the same eight weeks, it's better to move your kickoff date than to start a rollout you can't staff.
Once you've signed, keep a simple record like this for the week 7 test, so your launch decision rests on what staff actually did:
At our fictional hospital, the Clinic B login problem holds the launch until the system admin fixes it. The EVS result is a quick change for the policy owner.
These are pilot observations: they show whether staff can log in and find what they need. If you want to measure time saved, you'll need a baseline from before launch.
Claromentis Enablement Hub brings your employee intranet, Policy Manager, LMS, and InfoCapture forms and workflows together on one platform. You can host it as SaaS, in a private cloud, or on your own servers. And it runs alongside your EHR and clinical systems, so they stay exactly where they are.
Our onboarding is a guided build. That means your team builds the site, and a dedicated onboarding account manager guides you through five live sessions. Along the way, you get:
By launch day, your admins have built the site themselves, so they know how to change it.
Your onboarding scope depends on your package, and it's priced separately from the platform. Both are set out in your proposal before you sign. At kickoff, your onboarding manager turns them into your week-by-week plan.
From what we've seen, the smoothest rollouts settle who owns what, and what goes live first, before anyone signs.
So your next step is to estimate your own hours from our 47-hour starting point. Then bring your first phase to a scoping call, along with your content inventory, your identity setup, and an idea of who you can free up. We'll propose the responsibilities, timeline, and onboarding cost for your organization.
Book a no-obligation scoping call with one of our experts.
Already signed? Download our pre-kickoff checklist at the form below to get your team ready for the first call and keep the build on track.