SharePoint vs modern intranet for transport companies
97% of Danish companies with at least 10 employees used information technology in 2023, according to Statistics Denmark on IT in businesses. This is changing the way an IT manager in transport works with intranets. The question is no longer whether the company should be digital. The question is whether the intranet actually works for drivers, warehouse teams, dispatchers and managers across locations.
In many transport companies, the practical day-to-day reality looks similar. The head office publishes news in one place, operational documents are stored in another, and contact details live a life of their own in Outlook, Excel or local lists. When the intranet is also difficult to use on mobile, engagement drops rapidly. This is where the difference between SharePoint and a modern stand-alone intranet becomes interesting, especially when hidden operational costs and contact data begin to impact daily operations.
Introduction to intranets in transport companies
A transport company can be highly digitised and still have an intranet that creates friction. This is the contradiction that many IT managers encounter in practice. The organisation has systems for operations, planning, finance and documents, but the employee at the terminal or in the cab still finds that internal information is hard to find and even harder to use on the go.
SharePoint is often chosen because Microsoft 365 is already in-house. It seems logical. If documents, email and collaboration are already in the Microsoft universe, it seems natural to build the intranet there as well. But the transport sector places some special demands. Many employees do not have a fixed desk. They read news on their phones, look for contact persons under time pressure, and need precise information without having to click through complex pages.
Hidden costs rarely appear on the licence sheet. They manifest in support requests, low mobile usage, manual updates and duplicate maintenance of contact data. Therefore, the comparison between SharePoint and a modern intranet is not just a technical choice. It is an operational choice.
An intranet in transport needs to function more like an operational portal than a document library.
For companies working with internal communication in a mobile workday, this review of internal communication in the transport industry describes the same challenge very clearly. If news, documents and contact data are not easy to access at the first attempt, the intranet loses its role as a shared workspace.
Understanding contact data in intranets
The biggest contact data problem in transport is rarely that a name is missing. The problem is that the data is too simple or too old to be useful in operations. Many intranet profiles contain a name, title and perhaps a phone number. This is equivalent to a telephone directory. It is better than nothing, but it does not help much when the company needs to find the right person on the right shift at the right location.
The telephone directory versus the living portal
The classic telephone directory logic is static. An employee is registered with one team, one department and one number. In a transport company, reality is more fluid. A manager may cover multiple depots. A planner may have shifts across teams. An employee may be responsible for emergency response without this appearing in the job title field.
A modern intranet profile therefore functions better as a living portal. It combines basic data with dynamic attributes, which transform the value of search and targeting in day-to-day operations.
Which data fields make sense
Contact data in an intranet can be divided into two layers:
Basic fields such as name, job title, department, email and telephone. This is the minimum most people expect.
Dynamic attributes such as location, team affiliation, shift role, language level, area of responsibility and availability status. These are the fields that operational staff actually navigate by.
A concrete example makes the difference clear. If a terminal manager needs to find "the correct contact for cold chain deviations during the evening shift", a name and title rarely help enough. If the profile instead shows location, emergency response role and current organisational placement, the intranet becomes a working tool instead of a business card archive.
Practical rule: If a contact field does not help someone make a faster decision in operations, it should either be removed or moved out of the standard search.
Why structure matters more than volume
Many organisations believe that more data automatically results in better contact data. This is rarely true. Unstructured free-text fields create more variations, more errors and poorer search results. The right goal is not maximum data volume, but consistent structure.
A good contact database makes three things possible in daily operations:
Find the right person quickly
Target news and operational messages by role or location
Maintain changes without manual custom solutions
When contact data is built correctly, the value to the frontline almost always increases noticeably. Not because the database itself is exciting, but because it eliminates unnecessary calls, uncertain transfers and information blocks.
Why correct contact data is critical
Incorrect contact data seems like a small problem until operations are under pressure. In transport, this is often where the consequences become visible. This applies to internal communication, emergency response and documentation for audits or inspections.
Internal communication misses the mark without precise data
Many intranet news articles are published broadly because the organisation does not trust the target groups in the system. This creates noise. Drivers receive messages that only concern the warehouse. The warehouse receives information that is only relevant to administration. When employees experience too many irrelevant messages, trust in the intranet drops.
Correct contact data changes that pattern. When profiles and organisational fields reflect reality, the company can send messages to the correct location, function or shift. This makes communication more precise and less disruptive.
Emergency response depends on more than telephone numbers
In an operationally critical situation, "who is responsible" is more important than "who is first in the telephone directory". If an incident occurs in a warehouse, you need to be able to find the person who is actually responsible for the area, preferably without calling through several levels.
A contact profile should therefore be able to support questions such as:
Location: Who is responsible at this terminal?
Role: Who handles safety, quality or operational incidents?
Coverage: Who is the backup if the primary contact is unavailable?
A classic problem arises when a previously responsible person is still registered as the contact person in several systems. Consequently, inquiries continue to go to the wrong person, while the current responsible person has to be found through unofficial channels.
When emergency response relies on verbal knowledge instead of maintained contact data, response times become more unpredictable.
Compliance requires traceability and ownership
Contact data is not just a practical helper list. It is also part of the company's data governance. Auditors and compliance functions often check whether the company has control over who owns data, who is allowed to change it, and how changes can be tracked.
This does not mean that every intranet profile should be heavy to administer. But it means that the company should be able to answer three questions clearly:
Question | Why it matters |
|---|---|
Who is allowed to update contact data? | Prevents arbitrary or inconsistent changes |
Where do the fields come from? | Makes it clear what is master data and what are local additions |
How are errors detected? | Reduces the risk of old information remaining in place |
In transport environments with many locations, ownership is key. If "everyone" can edit contact details, no one takes real responsibility. If "only IT" can edit them, updates become too slow. The most effective model places ownership close to the business, but within fixed rules.
Data governance and GDPR in practice
Data governance often fails for one reason. The organisation attempts to solve it with technology alone. An intranet cannot clean up unclear ownership, mixed field names or local special rules. Before integrations and automation make sense, the company must decide what an employee profile should actually contain, and who is allowed to change what.
Start with a common data model
A solid model begins with standardisation. Not large documents. Small, firm decisions.
A useful approach typically looks like this:
Define mandatory fields
Name, workplace, function and primary contact method should normally be consistent across the organisation.Determine field types and formats
Locations should be selected from list fields instead of free text. "Taastrup Terminal", "Taastrup", and "Terminal East" must not be three different versions of the same place.Decide data source per field
Some fields should come from the HR system. Others can be maintained locally in the intranet. This distinction saves many conflicts later.Set up validation rules
If a field is mandatory for targeting news or emergency response, the profile must not be left without a value.Define access roles
HR, local managers and system administrators do not necessarily need to have the same permissions.Enable audit logic
When the company can see who changed a field and when, errors are easier to correct.
Important: Data quality improves faster with a few enforced rules than with many voluntary recommendations.
When the organisation wants a solution that also supports data protection at the platform level, Colibo's page on data protection describes the framework that many IT managers request regarding hosting, security and governance.
GDPR checklist for contact data
GDPR is often treated as a separate legal track. In practice, it should be built into the intranet design from the beginning. Contact data may seem harmless, but it is still personal data.
A simple checklist helps:
Purpose: Only fields with a clear work purpose should be displayed on the intranet.
Data minimisation: The system should not collect more personal data than operations require.
Access control: Sensitive or internal role information should not necessarily be visible to everyone.
Correction and deletion: There must be a process for correcting errors and handling information when an employee changes roles or leaves the organisation.
Transparency: Employees should know what profile information is displayed and why.
Pitfalls that are often overlooked
Two mistakes are repeatedly made. The first is using the intranet as a temporary storage for data that should reside in an HR master data system. The second is allowing local custom fields without a common standard.
Both quickly create variations that ruin search, targeting and reporting. The best practice is normally a simple core profile with a few, well-defined extensions. The fewer exceptions, the less ongoing maintenance.
Integration with Microsoft 365 and Google Workspace
Integration sounds like a technical detail, but in transport it affects both operational costs and user experience. The choice is rarely between "integration or not". It is between different integration patterns and how much complexity the organisation is willing to bear over time.
When Microsoft 365 is the starting point
For companies already using Microsoft 365, SharePoint is the obvious intranet choice. The advantage is proximity to existing users, documents and identities. The disadvantage arises when the intranet needs to function as a simple front door for a broad employee group, especially on mobile and across shifting operational roles.
In Danish transport companies, SharePoint environments have had a 22% higher IT support load related to user behaviour and configuration of Web Parts compared to modern intranets, according to Colibo's review of intranets for transport and logistics. This difference points to an important operational reality. When the platform requires more configuration and governance work, part of the cost shifts from the licence to support.
This does not mean that Microsoft 365 is a bad ecosystem. On the contrary. But it means that the intranet layer should be assessed on its own. If the IT manager wants strong integration with Outlook, Teams and Entra ID, a stand-alone intranet can still be relevant, as long as it integrates with identity, users and document sources without inheriting all of SharePoint's complexity.
When Google Workspace is the starting point
Google Workspace typically provides a different starting point. The organisation often has fewer expectations that the document platform itself should also function as an intranet. Therefore, many choose a more distinct split between the productivity suite and the intranet experience.
This model has some practical advantages in transport. Contact data, news and operational messages can be managed in a separate layer, while documents and collaboration still live in the Google universe. This often makes governance simpler because the intranet does not have to be shaped according to the document platform's standard logic.
What the IT manager should assess
Instead of asking "which suite is best", it makes more sense to assess integration needs in four areas:
Area | What should be assessed |
|---|---|
Authentication | Should the user log in in one place, and how much identity management should be shared |
Data sources | Which fields come from HR, the email system or local operational registers |
Synchronisation | How quickly changes in roles and locations should take effect |
Governance | Who owns the rules, and how heavy can the administration be |
A good integration design makes the platform easier to live with. A poor design makes it expensive to support, even if the features look complete on paper.
Comparison of intranet features
When the discussion of SharePoint vs modern intranet for transport companies becomes concrete, it should be less about feature lists and more about operational scenarios. Which features actually help employees who do not sit at a desk all day?
Side-by-side on the features that matter most
The table below compiles the features that most often determine whether the intranet is used in a transport company.
Feature | SharePoint | Modern stand-alone intranet |
|---|---|---|
Mobile access | Often closely tied to Microsoft 365 logic and page layout | Typically designed with mobile as the primary or equal access path |
News and targeting | Can be set up, but often requires more structural work | Often more directly built for target groups, feeds and quick publishing |
Digital info screens | Possible via customisation or extra layers | Often intended as part of internal communication across screens |
AI-assisted search | Depends on setup, data sources and user interface | Can be oriented towards intranet content and daily guidance |
Contact data | Functional, but often shaped by Microsoft's structure | Often easier to shape around operational roles and local needs |
The biggest difference in transport is often seen on mobile. SharePoint intranets for transport companies typically experience a 30 to 40% higher completion delay in mobile access compared to modern stand-alone intranet platforms, according to Lookbook365's analysis of intranets for transport and logistics. The same analysis also describes how modern stand-alone solutions can reduce mobile latency through local caching and edge hosting in Denmark or the EU.
For an office worker, this difference may seem modest. For a driver or terminal worker opening a message between tasks, it can be the difference between usage and abandonment. The mobile experience is not an extra comfort. It is the access path.
The best intranet feature is often the one the employee can use without explanation under time pressure.
For transport companies wishing to compare their needs with concrete priorities, this overview of intranet features for transport companies provides a useful decision filter. In particular, the combination of mobile access, info screens and search has great significance in operational environments with many locations.
Implementation example with Colibo
A Danish transport company wanting to move away from the SharePoint track rarely starts by replacing everything at once. The most realistic course is usually to define the intranet as the communication and contact data layer, while other systems are retained where they make sense.
A realistic project course
A typical project course can look like this:
First, contact data is cleaned up
The company gathers the fields that are actually used in operations. Old title variations, local lists and duplicates are removed or mapped.Next, governance is established
HR owns some fields. Local managers own others. IT owns the integration rules and the permission model.Then, target groups are built
Location, role and team become the drivers for news, emergency information and contact displays.Finally, user access is migrated
Employees get a simpler entry point on mobile and web, while document sources can remain where they are.
If the company chooses a stand-alone intranet like Colibo, it can function as this separate layer for internal communication, contact data, info screens and mobile access, while maintaining integration with Microsoft 365 or Google Workspace. The point is not the product name itself. The point is the architecture. The intranet must solve communication and operations without inheriting unnecessary complexity from the document platform.
The measurable differences should be assessed where the load is felt. Support pressure, mobile experience and profile maintenance are often more decisive than the number of available Web Parts. Therefore, it makes sense to measure before and after on the operational pain points that the organisation is already struggling with, rather than chasing broad ROI models with uncertain assumptions.
Conclusion and recommendations
In the transport sector, the choice between SharePoint and a modern stand-alone intranet is not just about technology. It is about how much complexity the company is willing to accept in daily operations. When employees work across terminals, routes, shifts and functions, mobile access, precise targeting and maintained contact data become more important than classic intranet design.
SharePoint makes sense in organisations that want a close tie to Microsoft 365 and have the capacity to handle the extra governance and support that often follow. A modern stand-alone intranet often makes better sense when the goal is simple mobile access, a low training barrier, clearer data governance and a communication interface built for operational staff.
The strongest recommendation for transport companies is therefore simple. Choose an intranet architecture where contact data is treated as business-critical information, not as a secondary feature. Then choose a platform that can integrate with existing environments without making the intranet heavier than users can bear.
If a transport company wants to clarify whether a stand-alone intranet is a better fit than SharePoint, the next step could be a short workshop or demo with Colibo, where contact data, mobile usage, governance and integration needs are reviewed based on the concrete operational reality.
