Latest Articles

Stop Building Workflows from Scratch — Use Task Lists and Action Flows for Employee Services The Pattern Problem Most employee service requests follow predictable patterns. New hire onboarding, hardware asset assignment, access provisioning—these are repeatable processes that can be standardized. Yet many organizations still handle each request from scratch, leading to inconsistency, delays, and unnecessary manual effort. The Solution: Predefined Workflow Components Modern service management platforms provide tools to streamline employee service requests through three key components: 1. Task Lists Task lists define the predictable, repeatable steps required for common service requests . Examples: New hire onboarding: Equipment setup, account creation, access provisioning, training scheduling Hardware assignment: Asset selection, configuration, shipping, user setup Access requests: Approval gathering, provisioning, confirmation Benefits: No one forgets a step Consistent process every time Easy to track progress Easy to identify bottlenecks 2. Approval Requests Approval requests get manager or department approval without leaving the ticketing system . Examples: Hardware requests: Manager approval before equipment purchase Budget requests: Finance approval before expense processing Access requests: Security or manager approval before granting access Benefits: Approvers notified automatically Approval history captured No separate email chains Faster approval cycles 3. Action Flows Action flows automate updates in external systems . Examples: HR systems: Update employee records when onboarding completes Asset management: Record hardware assignment Messaging platforms: Notify requestor when work is complete Benefits: No manual data entry across systems Consistent data across platforms Reduced risk of errors End-to-end automation How They Work Together When an employee submits a new hire onboarding request : Task list defines the steps: create account, assign equipment, provision access, schedule training Approval request routes to HR manager for approval Action flows create the account in HR systems, assign equipment in asset management, send notifications The Automation Hierarchy Level Description Example Manual Agent does everything by hand Agent creates account, assigns equipment, updates systems Task List Agent follows a checklist Agent follows predefined steps for onboarding Approval Workflow Approvals routed automatically Manager approves hardware request Action Flow Systems updated automatically HR system updated when onboarding completes Full Automation End-to-end automation Request → approval → fulfillment → notification with no manual steps Benefits Benefit Impact Consistency Every request follows the same process Speed No time wasted figuring out what to do Accuracy No steps missed or skipped Traceability Clear record of who did what when Scalability Processes work the same at any volume Playbooks: The Next Evolution Atlassian has introduced Playbooks as a feature that combines task lists, approvals, and action flows into a single, guided experience. Each playbook can include : Instructional steps: Clear instructions for manual actions agents must take Automation steps: Tasks that are automatically executed by the system This ensures that every agent follows the same process, which is especially useful for high-volume or critical requests. It also aligns perfectly with ITIL4's focus on standardization and automation to improve reliability and speed. Conclusion: Stop Building from Scratch Task lists, approvals, and action flows transform service request fulfillment from an ad-hoc process into a standardized, automated workflow. Organizations can stop building from scratch and start using predictable, repeatable patterns for common requests. Action Items for Your Organization Identify your 5 most common service request types Document the steps for each Build task lists for these request types Set up approval workflows where needed Create action flows for external system updates Start with one request type, then expand  

AI Is Supposed to Reduce Work. So Why Are 44% of IT Teams Spending More Time on Incident Response? The Promise vs. The Reality The pitch was irresistible. AI would transform incident management—automating triage, accelerating root cause analysis, and freeing IT teams from the endless cycle of alerts and escalations. It would finally deliver on the decades-old promise of "doing more with less." The reality, according to comprehensive 2026 research from SolarWinds, is more complicated. AI is delivering genuine wins. 61% of IT professionals say AI has accelerated root cause analysis—a meaningful improvement in one of incident management's most time-consuming activities. The data shows organizations using GenAI in ITSM reduced average incident resolution time from 27.42 hours to 22.55 hours—a saving of 4.87 hours per incident . But here is the paradox that should concern every IT leader: 44% of IT professionals say managing incident response across teams has become a new or increased responsibility since AI adoption . Meanwhile, only 27% report any meaningful reduction in alert volume thanks to AI . First-line managers are feeling this most acutely. 41% say AI has increased expectations without reducing workload—more than double the 18% of C-suite leaders who say the same . How did a technology designed to reduce work end up creating more of it? The Trust Gap That Slows Everything Down The answer lies in a fundamental challenge that no vendor's sales deck addresses: trust. 71% of IT professionals still manually double-check AI outputs. 62% report difficulty trusting AI recommendations . In a service desk environment, this trust gap translates directly into slower resolutions. Teams receive AI-generated answers but spend time verifying rather than acting on them. The cognitive overhead of manual checks, cross-team coordination, and risk management is being absorbed by service desk teams without the infrastructure to handle it efficiently. Consider what this looks like in practice: AI Capability The Promise The Reality Automated incident categorization Tickets routed instantly Teams verify every AI-assigned category before routing AI-generated resolution steps Engineers fix faster Engineers research whether the AI's solution is correct Predictive alerting Problems solved before users notice Teams spend time validating whether the alert is real Root cause analysis Instant identification Teams verify the AI's conclusion against multiple data sources This verification overhead—the "trust tax"—erodes the efficiency gains AI promises. The Pace Without Governance Problem Organizations are deploying AI faster than they're building governance structures to support it. The overhead of manual checks, cross-team coordination, and risk management is being absorbed by service desk teams without the infrastructure to handle it efficiently. The underlying issue is clear: AI doesn't fix bad data, unclear ownership, or inconsistent processes. It scales them—quickly, confidently, and repeatedly. When organizations deploy AI on top of fragmented IT environments, they don't get efficiency. They get amplified chaos. 83% of IT professionals agree that AI is only as effective as the breadth and quality of data it can access . The most successful organizations are discovering a counterintuitive truth: AI requires more governance, not less. And that governance, paradoxically, creates initial overhead before delivering efficiency. The Real Cost of AI Incident Management The hidden costs are significant: Coordination Overhead With AI generating more insights across teams, 44% report increased coordination burden. Incident response now requires managing not just human teams but AI outputs and cross-team integration of AI-generated intelligence. Manual Verification 71% double-check AI outputs. Every AI recommendation triggers a verification cycle that adds time to incident resolution. Tool Complexity Managing AI-driven incident response across multiple tools creates additional cognitive load. Teams must understand not just their tools but how AI interacts with and generates output across the ecosystem. Training and Skills Teams need to understand not just incident management but AI capabilities, limitations, and risks. This creates a skills gap that requires investment. What Successful Organizations Are Doing Differently The organizations getting the most from AI in incident management share common practices: 1. Build Governance Before Scaling AI Treat governance and data quality as prerequisites, not afterthoughts. Organizations barely ready for automation should let AI recommend, not decide; assist, not replace; explain, not obscure. 2. Establish Clear Human Checkpoints For high-stakes incident decisions, configure AI to recommend actions but require human approval before execution. This maintains safety while building team confidence. 3. Measure What Matters Don't just measure resolution speed. Measure the coordination overhead AI creates. Track time spent verifying AI outputs. Understand whether AI is genuinely reducing workload or simply shifting it. 4. Start with "Assist," Not "Auto-Execute" Transition gradually: AI-assisted (operators interact with AI using natural language), AI-led (agents coordinate workflows while maintaining human oversight), AI-driven (agents validate hypotheses and execute full workflows automatically). 5. Invest in Data Quality Clean data is not optional for AI incident management. Organizations that invest in data quality see faster AI deployment and better outcomes. The AI Incident Management Maturity Model Level Description Key Characteristics Level 1: AI-Assisted AI provides recommendations; humans make all decisions Manual verification of outputs; high trust tax; limited efficiency gains Level 2: AI-Led AI coordinates workflows; humans supervise Partial verification; moderate trust tax; measurable efficiency gains Level 3: AI-Driven AI validates hypotheses and executes full workflows; humans oversee exceptions Low verification overhead; high efficiency; requires mature governance Level 4: Autonomous AI operates independently within defined boundaries; humans audit Minimal human intervention; requires robust governance and trust framework Most organizations are at Level 1 or early Level 2. The transition to higher levels requires governance investment before automation expansion. Conclusion: The AI Incident Management Reset The paradox of AI creating more work is not a failure of the technology—it's a failure of implementation. Organizations that deploy AI without governance, trust-building, and data quality investments are discovering that AI amplifies existing problems rather than solving them. The organizations pulling ahead are treating governance and data quality as prerequisites for AI incident management, not afterthoughts. They're starting with assist mode before moving to auto-execute. They're measuring not just resolution speed but the overhead AI creates. AI doesn't reduce work magically. It reduces work when it's trusted. And trust isn't automatic—it's earned through transparent, explainable, and well-governed implementation. The question isn't whether AI will transform incident management. It will. The question is whether your organization will pay the governance tax upfront or pay the chaos tax later. Action Items for Your Organization Assess your trust gap: Measure how much time teams spend verifying AI outputs Build AI governance: Establish clear accountability for AI-driven incident decisions Start with assist mode: Configure AI to recommend, not decide, for critical incidents Measure coordination overhead: Track whether AI is reducing or increasing team coordination Invest in data quality: Clean your CMDB and knowledge base before scaling AI Train teams on AI: Ensure teams understand AI capabilities, limitations, and risks  

Avoid, Mitigate, Transfer, Accept — A Complete Guide to Risk Treatment Options The Four Risk Treatment Options Organizations should develop and implement IT risk response strategies that are consistent with the value of information assets and risk appetite . Option Description Best For Avoid Eliminate the activity or asset that creates risk Risks that exceed risk appetite Mitigate Reduce likelihood or impact through controls Most risks Transfer Shift financial exposure Financial risks Accept Consciously tolerate residual risk Risks within risk appetite 1. Risk Avoidance Definition: Avoiding IT risks involves a decision by a business owner and risk committee to cancel or postpone a particular activity or project that introduces an unacceptable IT risk to the business . When to use: Risks exceed risk appetite Cost of mitigation exceeds business value Risk cannot be controlled effectively Example: Canceling a project because the security risks cannot be adequately managed. 2. Risk Mitigation Definition: Applying IT controls to reduce risk includes identifying appropriate IT controls, evaluating their strengths and weaknesses, selecting adequate controls, and documenting and obtaining sign-off for any residual risk . When to use: Most risks Controls are available and cost-effective Residual risk remains within risk appetite Example: Implementing MFA to reduce identity theft risk. 3. Risk Transfer Definition: Transferring or sharing IT risks involves sharing risk with relevant (internal or external) providers and requires acceptance by the receiving provider(s) . When to use: Financial risks Vendor-related risks Insurance-eligible risks Example: Purchasing cyber insurance to transfer financial risk. 4. Risk Acceptance Definition: Risk acceptance involves formally documenting, approving, and signing-off on accepting IT risks, ensuring the accepted risk is within risk appetite and does not contradict regulations . When to use: Residual risk is within risk appetite Cost of mitigation exceeds business value Compensating controls are in place Risk acceptance should include: Justification (impact of not implementing controls) Compensating controls in place Renewal period Approval by business owner and risk committee  The Risk Treatment Process Step 1: Assess Inherent Risk What is the risk without controls? Step 2: Consider Treatment Options Avoid, Mitigate, Transfer, or Accept? Step 3: Evaluate Options What is the cost-benefit of each option? Step 4: Select Treatment Choose the best option Step 5: Implement Treatment Execute the treatment plan Step 6: Assess Residual Risk What is the risk after treatment? Step 7: Document and Report Document decisions, report to risk committee Key Principles Risk acceptance should be least preferred over risk mitigation through implementation of primary controls  Residual risk should be documented and signed-off Risk acceptance should be renewed periodically All risk treatment decisions should be documented Risk treatment should align with risk appetite Conclusion Risk treatment is not a one-size-fits-all process. Organizations must consider the full range of options—avoid, mitigate, transfer, or accept—and choose the best approach for each risk based on cost-benefit analysis and risk appetite. Action Items for Your Organization Define risk treatment processes Establish risk appetite Document risk treatment decisions Implement treatment plans Report to risk committee Review and renew risk acceptance  

From IT to Facilities — Why Service Request Management Is the Key to Workplace Experience The Rise of Facilities Service Requests Facilities services have become a core component of enterprise service management. Employees need: Transportation and parking Room booking Facilities tickets (maintenance, cleaning) Office equipment and supplies Lobby services Maps and wayfinding The Facilities Challenge Historically, facilities requests were handled through separate systems or ad-hoc processes. This fragmentation created a poor employee experience: Problem Impact Separate system for facilities Employees don't know where to go No tracking or visibility Employees don't know request status Inconsistent response times SLAs don't exist or aren't tracked Siloed operations No connection to IT, HR, or other services The Unified Approach Microsoft's Employee Self-Service Agent includes real estate and facilities as a key vertical, handling requests for: Transportation Dining Room booking Lobby services Facilities tickets Parking registration Maps  The previous experience was fragmented across mobile, websites, and physical kiosks. The new agent unifies these experiences in one place . Benefits of Unified Facilities Service Management Benefit Description Better employee experience One place for all needs Faster resolution Standardized processes and SLAs Better tracking Visibility into request status Data-driven improvements Analytics on request patterns Cross-department coordination Connected to IT, HR, and other services Facilities Service Request Types Category Examples Workplace services Desk booking, office moves, space requests Maintenance Repairs, cleaning, temperature issues Equipment Furniture, office supplies, technology Transportation Parking, shuttle service, travel Facilities access Building access, key cards, security Conclusion Facilities service requests are a growing part of enterprise service management. Organizations that include facilities in a unified service delivery model will deliver a better employee experience and operational efficiency. Action Items for Your Organization Map current facilities request process — what's fragmented? Identify the most common facilities requests Integrate facilities into your service management platform Define SLAs for facilities request types Measure employee satisfaction with facilities services  

Vendor Offboarding Is Critical — One Weak Offboarding Can Expose Your Data for Years The Offboarding Risk Vendor offboarding is often overlooked—but it's a critical risk stage. Organizations must conduct safe vendor offboarding by verifying compliance records and ensuring that sensitive data is deleted . The Offboarding Challenge When a vendor relationship ends: System and data access must be revoked Data must be returned or deleted Contractual obligations must be verified Compliance records must be maintained The risk: One weak offboarding can expose your data for years—with no contractual recourse. Offboarding Best Practices 1. Plan Offboarding in the Contract Before the relationship starts, define how it will end: Transition assistance or unwind clauses  Clear and time-bound exit strategy  Vendor requirement for data migration  Guarantees of data delivery in an open, non-proprietary format  2. Define Offboarding Procedures Establish a documented offboarding process that includes: Notification requirements Access revocation Data return or deletion Compliance verification Final review 3. Verify Data Deletion Ensure that sensitive data is deleted : Obtain certification of deletion Verify that backups are also deleted Document deletion for audit purposes 4. Revoke Access All access to systems, data, and facilities must be revoked: System access Data access Physical access Network access 5. Maintain Compliance Records Retain records of the vendor relationship: Contracts Assessment reports Incident reports Termination documentation The "Right to Audit" During Offboarding Strengthen onboarding of new vendor processes to include sanctions, ownership structures and also ensuring strong right to audit in all contracts . The right to audit should extend through offboarding. Offboarding Checklist Pre-Offboarding : Review contract for offboarding requirements Identify all data and systems involved Plan for data migration or deletion During Offboarding : Revoke all system and data access Return or delete data Verify deletion certification Document offboarding activities Post-Offboarding : Maintain compliance records Monitor for continued access Conduct final review Conclusion Vendor offboarding is a critical risk stage that is often overlooked. Organizations that plan for offboarding from the start and follow documented procedures will protect their data and maintain compliance. Action Items for Your Organization Document offboarding procedures Define offboarding requirements in contracts Verify data deletion Revoke all access Maintain compliance records Include offboarding in VRM lifecycle  

The Seven Stages of Problem Management — A Complete Guide to the Process Overview of the Problem Management Lifecycle The Problem Management lifecycle ensures that problems are systematically identified, investigated, and resolved. Each stage has specific activities, inputs, and outputs. Stage 1: Problem Detection Problems can be detected through multiple channels: Major incidents: When a major incident occurs, a problem should always be raised  Recurring incidents: Patterns of similar incidents indicate an underlying problem Monitoring events: Alerts that suggest an underlying issue Trend analysis: Patterns identified through data analysis Vendor reports: Suppliers reporting known issues Technical support staff: Internal experts identifying issues  Key question: Is this a one-time incident or a pattern indicating a problem? Stage 2: Problem Logging Once detected, the problem must be properly logged: Core fields : Field Description Subject Title or short summary Description Detailed description including actual behavior, expected behavior, and steps to reproduce Resources Devices on which the problem is identified Category Category to which the problem is mapped Sub Category Subcategory under the category Priority How soon the problem needs to be fixed Additional fields: Requested By: User who requested the problem Assignee Group: User group that manages the problem Assign to: Specific user Application: Applications where the problem is detected Root Cause: Factors on resolution of which incidents can be prevented Work Around: Temporary method for achieving the task Stage 3: Problem Categorization Categorization helps with reporting, routing, and analysis: Product categorization: The IT asset or system affected  Operational categorization: The action or function required  Component/s: Segments of IT infrastructure related to the problem  Good categorization ensures consistency and enables meaningful reporting. Stage 4: Problem Prioritization Priority is based on : Impact: The effect of the problem, usually in regards to service level agreements Urgency: The time available before the business feels the problem's impact Frequency: How often related incidents occur The goal is to prioritize problems that have the greatest business impact. Stage 5: Problem Investigation and Diagnosis This is the root cause analysis phase, where the team determines the underlying cause of the problem: Root cause analysis: Using techniques like Five Whys, Ishikawa diagrams, and Pareto analysis Investigation reason: The trigger for prompting an investigation (e.g., recurring incidents, non-routine incidents)  Cross-functional collaboration: Involving subject matter experts Key question: What is the underlying cause that, if fixed, would prevent recurrence? Stage 6: Creating a Known Error Record When the root cause is identified and a workaround is developed, the problem becomes a "known error" : Known Error documentation: Symptoms of related incidents, root cause, and workarounds Knowledge Base integration: Known errors are added to the Knowledge Base  Incident linking: All related incidents are linked to the known error This is where problem management creates lasting value—by ensuring that when the same issue occurs again, it can be resolved faster. Stage 7: Problem Resolution and Closure The final stage involves implementing a permanent fix: Propose a change: The service desk team proposes a change to the infrastructure to resolve the problem  Implement the fix: Through change management Verify resolution: Confirm the problem is resolved Close the problem: After verification and documentation Testing the fix: Ensure it doesn't introduce new problems. Stage 8: Major Problem Review Team members should carry out in-depth reviews of major problems : Lessons learned: What worked, what didn't Preventive measures: How to prevent similar problems Process improvements: How to improve the problem management process itself Action items: Follow-up activities Visualizing the Lifecycle The problem management workflow should complement these ITIL-recommended activities : Problem investigation Identification of workarounds Recording of known errors Start with the default workflow and adapt it to your specific needs over time. Conclusion The Problem Management lifecycle provides a systematic approach to identifying, investigating, and resolving problems. By following each stage, organizations can ensure that recurring incidents are eliminated and service quality improves over time. Action Items for Your Organization Map your current problem management process against the lifecycle Identify gaps in your process Document the workflow in your ITSM platform Train your team on each stage of the lifecycle Measure completion time for each stage