Your new workforce won't be all human. Join the
conference to learn the new workforce OS.
request invite
TL;DR: The fourth ITIL 4 guiding principle, collaborate and promote visibility, makes two demands. Collaborate: involve the right people across team boundaries instead of optimizing inside silos. Promote visibility: make the work and its status visible, because you can only prioritize and decide on work you can actually see, and hidden work-in-progress quietly wrecks both. Most IT organizations break both at once. Requests sit in a portal only IT watches, cross-team coordination happens in private messages that leave no trace, and prioritization defaults to whoever complains loudest because nobody can see the real queue. An AI Coworker that works inside Slack and Teams is a direct answer to both halves: it puts the work in a shared space where the right people are already present, and it makes the request, its status, and its resolution visible in the open. The one honest condition is that the Coworker's own actions have to be visible too. This is still one of the seven guiding principles in the current ITIL, which moved to Version 5 in 2026.
Related reading: Progress iteratively with feedback, the third ITIL 4 guiding principle, The 7 ITIL 4 guiding principles, and how we build to them.
This is part four of a walk through the ITIL 4 guiding principles, one at a time, from the point of view of someone building with AI rather than studying for an exam. We have done focus on value, start where you are, and progress iteratively with feedback. This one, collaborate and promote visibility, is the principle I see broken most often in real IT organizations, and it is the one where the shape of an AI Coworker turns out to matter more than the intelligence inside it.
There are two ideas here, and it helps to keep them separate because IT tends to fail at both, in different ways.
Collaborate. Better outcomes come from working across boundaries with the right people involved, not from each team optimizing its own corner. In service management that means the service desk, the engineers, security, the app owner, and the person who raised the request are not five separate universes connected by tickets. When they work as one flow, context survives the handoffs. When they do not, every boundary becomes a place where information falls on the floor.
Promote visibility. Decisions can only be made well on work you can actually see. ITIL is blunt about this: insufficient visibility of work leads to poor decisions, and hidden work-in-progress competes silently for the same people and time. If nobody can see the true amount and state of the work, prioritization stops being a decision and becomes a reaction to whoever is loudest. The fix is not more status meetings. It is making the flow of work, and its state, visible to the people who need it.
Start with collaboration. A request comes in, and the real work is spread across a portal, an engineer's terminal, a security reviewer's inbox, and three Slack DMs. Each person sees their slice. Nobody sees the whole. The coordination that does happen leaves no shared record, so the next person to touch the request rebuilds the context from scratch. That is not collaboration. It is a relay race where the baton keeps getting dropped between lanes.
Now visibility. The classic place work disappears is the ticket queue that only the IT team watches. A request goes into a portal, its status flips from assigned to in progress, and the person who asked has no idea what is happening or when it will be done. Multiply that across a few hundred open items and you lose the one thing you need to prioritize well: an honest picture of how much work is actually in flight and where it is stuck.
These two failures reinforce each other. Silos hide work from other teams, and invisible work makes collaboration impossible because you cannot coordinate on something you cannot see.
Here is the part that surprised me. You would expect the fix for a collaboration-and-visibility problem to be a process change or a new dashboard. But the shape of an AI Coworker, where it lives and how it behaves, addresses both halves more directly than a policy ever has.
Take collaborate first. An AI Coworker that works inside Slack and Teams is operating on the collaboration surface people already use. The request does not disappear into a portal. It happens in a channel or a thread where the requester, the service desk, and whoever else is needed can all be present at once. When the work crosses a boundary, when security needs to weigh in, or the app owner needs to confirm impact, the Coworker can pull that person into the same thread rather than starting a private side conversation. The collaboration becomes a shared event instead of a chain of handoffs.
Now promote visibility. Because the work lives in an open thread, its status is visible by default. The requester can see that their access request is waiting on an approval, not lost. The team can see the same thing. And a Coworker that tracks the flow of requests, incidents, and changes can surface the real work-in-progress, so prioritization is driven by what the queue actually looks like rather than by who escalated most aggressively.
There is one honest condition, and it is the whole reason the shape matters. A Coworker only promotes visibility if its own actions are visible. If it quietly does things in the background and reports nothing, it has become the exact silo the principle warns against, just an automated one. So the design bar is that every meaningful action the Coworker takes, checking a policy, provisioning access, routing to a person, leaves a plain-language trace in the thread and on the record: what action was taken, what data it touched, under whose authority, where a human approved, and the final state.
Take a request that needs more than one team: an employee asks for access to a system that holds sensitive data. Without this principle, the request goes to a portal, an IT person picks it up, pings security in a DM, waits, hears back, provisions the access, and closes the ticket. The requester saw a status bar. Security's input lives in a DM nobody else can find. The app owner never knew.
With it, and with a Coworker in the loop, the request lives in a thread from the start. The Coworker captures it, checks policy, and because the data is sensitive, brings the security reviewer and the app owner into the same thread for a visible decision rather than a private one. The requester can see exactly where things stand. When the access is granted, the Coworker records what it did and why, in the open.
To keep this current and honest: ITIL moved to Version 5 in 2026, per PeopleCert. The seven guiding principles, including collaborate and promote visibility, remain part of the framework, so this is not a legacy idea. Confirm the exact syllabus wording on PeopleCert's site, since details shift between versions.
Atomicwork is an AI-native ITSM platform, and it fits this principle for structural reasons, not cosmetic ones. Its AI Coworker works inside Slack and Teams, so collaboration happens where people already are and the right people can be pulled into one shared thread. The work, its status, and the Coworker's own actions are visible in the flow rather than buried in a queue only IT watches.
The tool-agnostic takeaway holds regardless of platform: put the work where people can see it and collaborate on it, and make sure the work, including the automated parts, is visible to the people it affects.
What is the ITIL 4 principle "collaborate and promote visibility"? It is the fourth of ITIL 4's seven guiding principles. It has two parts: collaborate across team boundaries with the right people involved, and promote visibility by making work and its status visible, because you can only prioritize and decide well on work you can see.
Why does hidden work cause problems? Because invisible work-in-progress competes silently for the same people and time, and when nobody can see the real queue, prioritization defaults to whoever complains loudest instead of what matters most.
How does an AI Coworker support collaboration? By working inside Slack and Teams, the collaboration surface people already use, so requests happen in a shared thread rather than a portal, and by pulling the right people into that same thread when a request crosses a boundary.
How does an AI Coworker promote visibility? Because the work lives in an open thread, its status is visible to the requester and the team by default. The one condition is that the Coworker's own actions must also be visible, recorded in plain language on the thread and the record.
Is this principle still in the current ITIL? Yes. ITIL moved to Version 5 in 2026, and the seven guiding principles, including this one, remain. Confirm current syllabus wording on PeopleCert.
The ITIL 4 guiding principles, including collaborate and promote visibility with its emphasis on cross-boundary collaboration and the visibility of work-in-progress, are summarized in practitioner guidance such as Stuart Rance's "The 7 Guiding Principles of ITIL 4" on the SysAid blog; treat that as a practitioner summary of AXELOS material and verify specifics against the official publication. ITIL Version 5 status and the continued presence of the guiding principles: PeopleCert, ITIL Foundation (Version 5) certification page. This post makes no statistical claims. Where outcomes are described, they are qualitative and should be validated in your own environment.
