In today’s digital economy, collaborative platforms are the backbone of teamwork, both internally and with external partners and customers. When the pilot project introduced a tailor‑made SharePoint product, we initially celebrated a success that quickly moved into the next development phase: the platform became a central hub for the, often heavily regulated, collaboration with external companies. The integration with ServiceNow, the automated provisioning of roles and permissions, and the inclusion of several third‑party service providers turned the system into a highly complex but functional solution.
Soon, however, the dark side of that success came to the fore: errors that could not be clearly assigned to any single system or to the involved service providers, and a consequently exponential increase in support effort. The external perception was unmistakable: “It doesn’t work.” That impression jeopardized not only users’ trust but also the client’s reputation as a provider of a professional collaboration platform.
The Starting Point: Multi‑Layered Processes, Multiple Service Providers
The project began with a custom SharePoint product that was first used internally for collaboration. Its success caused the system to expand beyond corporate borders quickly: external partners, customers, and other stakeholders received access, and the application landscape was extended with ServiceNow‑based request and role processes. Each of these components was managed by independent service providers, from SharePoint configuration to ServiceNow ticket management to specialized data‑integration and security services.
Integrating these disparate systems created a web of dependencies that was hard to keep track of in practice. Error messages appeared sporadically, often stemming from a subtle interaction between a ServiceNow workflow customization and a SharePoint permission rule. Who was responsible for fixing it? Internal business units pointed to the ServiceNow logic, while the ServiceNow partners criticized the SharePoint integration. This led to classic “finger‑pointing”: no one wanted to take ownership, and support repeatedly dealt with escalating requests. The effort was massive both in personnel time and cost, and the outward image suffered noticeably.
The Core Problem: Lack of Cross‑Cutting Governance and Transparency
The main challenge is not the technology itself but the absence of an overarching governance entity that can understand and coordinate both the technical details and the communication pathways between the service providers. In regulated environments, where compliance and security requirements are strictly prescribed, any change to a component instantly becomes relevant for the entire ecosystem. A small tweak in a ServiceNow workflow can cause unforeseen consequences in SharePoint and vice versa. Without a neutral overview, the team loses the ability to identify root causes quickly, and incident management turns into endless ping‑pong between providers.
Another issue arises from the missing categorisation of support tickets. Every new report is handled ad‑hoc, causing repeated cases to be analysed from scratch each time. This prevents the accumulation of experiential knowledge and inflates the effort required for each individual fix. Moreover, there is no unified documentation structured according to open standards (such as UML). Without such a foundation it is impossible to trace changes, assign responsibilities, or implement automated tests.
The Solution Approach: Technical Neutrality Meets Communicative Strength
To untangle the situation we need an approach that combines two pillars: deep technical understanding of all involved systems and the ability to act as a neutral mediator in a often conflict‑laden environment. That combination is the core of the flowciety service‑provider‑management offering.
- Technical Deep‑Dive
An experienced technology specialist is brought in to study the existing SharePoint and ServiceNow implementations, track down customisations, and map the underlying data flows. The specialist uses UML as a reference framework to depict the complex landscape in a structured, traceable form. Uniform naming conventions, clear interface specifications, and a central repository create a platform where everyone works from the same information. - Systematic Ticket Categorisation
A systematic classification scheme for support incidents is introduced. Every incident is labelled by cause, affected component, and severity, making recurring patterns instantly visible. For the most common error types a “run‑book” is created: a documentation package that defines both the technical remediation steps and the clear escalation paths. Thus an ad‑hoc ticket becomes a standardised process that can be resolved in minutes instead of hours. - Neutral Facilitation and Governance
The technology specialist also assumes the role of neutral moderator: gathering facts, presenting root causes impartially, and steering discussions between service providers. Regular steering meetings that showcase concrete metrics (e.g., average handling time, repeat‑incident rate) foster a shared goal: not blame‑allocation, but continuous platform improvement. Assertiveness is required to define responsibilities clearly, to follow up on agreed‑upon actions, and to enforce compliance when needed. - Service‑Level Agreements (SLAs)
SLAs are introduced that define not only response times but also explicit hand‑off points between providers. These SLAs are derived from insights gained during ticket categorisation and are co‑created in joint workshops, ensuring every team knows and accepts the expectations.
The Delivered Value: More Stability, Less Effort, Better External Image
- Reduced Error Rate: Structured analysis and documentation of the system landscape significantly lower the frequency of incidents. Recurring problems are identified before they cause disruptions.
- Accelerated Incident Resolution: Categorisation and run‑books enable technicians to jump straight to the relevant steps instead of starting from zero each time.
- Support‑Effort Reduction: For the client, support effort drops by roughly 30 %, translating into lower costs and more capacity for strategic work.
- Improved Perception: Users experience a reliably functioning system with fast fixes. External communication shifts from “It doesn’t work” to “We provide a stable, regulatorily compliant collaboration tool,” strengthening trust in both the IT department and the product itself.
- Sustainable Governance: Ongoing upkeep of the UML artifacts, continual updates of run‑books, and regular alignment with service providers keep the platform adaptable; new changes no longer trigger fresh waves of errors. The company can roll out new features faster, comply with regulatory updates, and continuously enhance overall collaboration.
Conclusion: In an environment where heavily customised software solutions must interoperate, there is no rigid “X‑model” that solves every problem. What consistently works is the symbiosis of deep technical expertise and strong communicative assertiveness. A team that can dive into the details of SharePoint, ServiceNow, and the whole integration layer and act neutrally to mediate between different service providers can rescue even the most tangled situation. Through disciplined documentation, systematic incident management, and clear governance mechanisms, processes become stabilised, support effort diminishes, and the external image improves. The result is not only a smoothly functioning product but also a long‑term, scalable collaboration model that benefits the client, its partners, and ultimately all end‑users.
We are IT partners
Our motto: Establish IT in everyday business as a solution, not as a source of problems.
