Latest Articles

From Submission to Follow-Up — The Five-Step Framework Every Service Team Needs The Service Request Management Lifecycle Service request management is the process of receiving, documenting, and acting on service requests. For service teams receiving high volumes of requests—IT, HR, workplace teams—this process is essential to ensure nothing falls through the cracks . Establishing a predefined service request management process helps teams: Quickly document, triage, and assign requests to the right team member Follow up to ensure employees are satisfied with the help received Standardize requests with a service catalog Track requests from submission to completion Protect team bandwidth and prevent burnout The Five Steps Step 1: Submission The process is kicked off when an employee submits a service request. There are a few different ways employees can submit requests : Smaller companies: Email, phone, or simple online forms Larger organizations: Help desk, service desk, or employee help portal Best practice: Centralize the request process in one place to ensure employees know where to go and to prevent duplicate work. Step 2: Assessment The service team receives and assesses the request to determine : Urgency: For example, a password reset request may be urgent if someone is locked out of their computer Resources needed: What tools or skills are required to fulfill the request Approvals required: Whether supervisor approval or verification from another team is needed Best practice: Configure request intake forms to gather required information upfront, minimizing back-and-forth conversations. Step 3: Fulfillment The team fulfills the request : Assign the request to a specific team member (or multiple team members) Provide an estimated completion date Follow up with the requester for more information if needed Best practice: Create service request models for common request types. According to ITIL4, a service request model is a predefined, repeatable approach to fulfill a specific type of request and should include : Workflows and procedures Roles and responsibilities Tools and automation Third-party involvement (when needed) Step 4: Completion Once the team has fulfilled the request : Let the requester know Verify that the service works or meets expectations Close and archive the request ticket Best practice: Always verify that the service works as expected before closing. For example, verify that an employee can successfully log in if you helped with a password reset. Step 5: Follow-Up Just because a request is complete doesn't mean everyone is happy with the result : Ask for feedback to ensure positive customer experience Identify opportunities to improve the service request management process Use feedback to refine models and procedures The Benefits of Service Request Models When done right, service request models bring huge benefits : Benefit Description Predictability and speed Everyone knows what to do and how long it will take Consistency Reduces confusion and errors across teams Clear expectations Improves satisfaction with well-defined service levels Scalability Handles growing demand without losing quality Continuous improvement Feedback drives better processes over time Measuring Success To track improvement over time, identify key metrics that indicate how well your program is performing : Average time to complete requests Customer satisfaction Request volume trends First-contact resolution SLA compliance Conclusion: Process Brings Control An effective service request management process gives your team control over how and when you execute service requests. That means you can go from reactive mode to planning mode — proactively managing your team's time instead of feeling swamped by a sea of requests. Action Items for Your Organization Document your current service request process—where are the gaps? Build service request models for your top 5 request types Train your team on the five-step framework Set up tracking and reporting for key metrics Establish a feedback loop for continuous improvement    

You Can't Improve What You Don't Measure — The Key Metrics for Problem Management Success Why Measurement Matters Measuring problem management effectiveness helps organizations: Identify areas for improvement Demonstrate the value of problem management Make data-driven decisions Track progress over time Key Metrics Process Effectiveness Metrics Metric Purpose Total number of problems, by priority Control measure for level of problems. The change in level over time can be considered both positive and negative  % of problems with workaround defined Measure the effectiveness of problem management in defining and communicating workarounds  % of problems with a root cause identified Measure the effectiveness of problem management in defining root cause  Mean time to first respond to problems Measure of how well response SLAs are achieved  Average time to determine root cause This is about identifying and not resolving root cause as this could take a considerable time  Outcome Metrics Metric Purpose % of problems that recur Measure of recurring problems that have a business impact  Number of incidents related to closed (or open) problems Indication of how much problem management reduces disruption. Indicator of avoided outages  % of incidents resolved by fixing known errors Measures the effectiveness of problem management in supporting the timely resolution of incidents  Why Speed of Resolution Shouldn't Be a Metric With problem management, the purpose is to understand the underlying cause of issues and permanently fix them no matter how long that takes or if it is even possible. Therefore, in problem management speed of resolution is not something that should be measured. This would drive the wrong behavior for the process and focus on closing records rather than finding the permanent fix. Process Owners need to feel comfortable with problem records potentially remaining open for months or even years . Direct and Indirect ROI Direct ROI: Reduction in incident solving costs Savings on SLA breach penalties Reduced higher-level support involvement Indirect ROI: Improved service quality leading to higher employee satisfaction Reduced risk of incidents impacting the business  Measuring Success Track metrics as trend lines over time, not snapshots  Monitored by the Process Owner  Use data for improvement - identify areas for investment Demonstrate value - show the ROI of problem management Conclusion Effective measurement is essential for problem management success. By tracking the right metrics and using them to drive improvement, organizations can reduce incident volume, improve service quality, and demonstrate the value of problem management. Action Items for Your Organization Define your problem management metrics Set up measurement and reporting Establish baseline measurements Review metrics regularly Use data to drive improvement

Headline: One-Size-Fits-All Change Is Dead — AI Personalizes the Journey for Every Employee The Personalization Imperative Change isn't just organizational—it's personal. Just as airline passengers may land at the same destination but recall the journey differently, employees experience change in ways shaped by their roles, contexts, and engagement . Employees want change that feels as intuitive and relevant as the technologies and services they use every day. Yet most change approaches still rely on one-size-fits-all tactics that overlook differing motivations, mindsets, and needs . The Data Gap More than two-thirds (67%) of leaders believe it is important to customize the design and experience of work based on worker skills, behavioral patterns, motivations, passions, and work styles. Today, workers are expecting that level of customer-grade personalization. But only 7% of leaders are taking action . AI is the key to closing this gap. How AI Enables Personalization AI-driven learning platforms deliver targeted content based on : Role: What does this employee need to know? Skill level: Where are they in the learning journey? Progress: What have they already completed? Learning style: What format works best for them? The result: Employees receive relevant guidance instead of generic training, accelerating adoption and building confidence . Personalization in Practice Example: Field Representative Training A field representative preparing for an upcoming customer conversation might turn to a coaching chatbot—not for scripted answers, but for a space to experiment. The representative could roleplay different scenarios with varied audiences, refine their message, and receive personalized feedback based on their tone, approach, and confidence level . Instead of static learning, the experience becomes dynamic—a personalized dialogue that builds skill, confidence, and ownership . Example: Personalized Learning Paths AI-driven learning platforms adapt content based on role, skill level, and progress. Employees receive targeted learning and support instead of generic training, similar to how platforms like LinkedIn personalize learning recommendations at scale . The Business Impact Organizations using AI for personalized learning and development report 73% more employee engagement . Personalization: Speeds up adoption Builds confidence Reduces frustration Demonstrates that the organization values employees as individuals Conclusion The next evolution of change is hyper-personalization: change journeys that adapt dynamically to each person's role, readiness, and response . By using AI to offer hyper-personalized change journeys, organizations can ensure people tune in instead of tuning out. Action Items for Your Organization Map employee personas for change audiences Implement AI-driven learning and communication platforms Develop personalized change journeys for different roles Use AI to recommend content based on role and progress Measure engagement and adoption by persona

The Incident That Never Reached a Human — How Predictive Analytics Automates Triage The Promise of Predictive Triage Imagine this: An incident occurs. Before a user reports it, before a ticket is created, the system: Detects the issue through anomaly detection Predicts the incident category Predicts the priority Predicts the assignment group Creates a ticket with all this information Routes it to the right team All without human intervention. This is the promise of predictive analytics for incident categorization and prioritization. And it's becoming a reality. How Predictive Triage Works The Multi-Task Neural Architecture Advanced frameworks use a multi-task neural architecture that jointly learns three interrelated tasks: Resolution time prediction: How long will this incident take to resolve? Incident priority estimation: What priority should be assigned? Assignment group recommendation: Which team should handle this? The Process Input: New incident data (title, description, etc.) Processing: ML model analyzes the incident data and related context Output: Predicted category, priority, assignment group, and resolution time Action: Ticket is automatically created, categorized, prioritized, and routed The Benefits of Predictive Triage Benefit Impact Faster response Incidents reach the right team immediately Reduced manual work Teams don't spend time categorizing and prioritizing Consistent classification AI applies the same criteria every time Better routing Incidents go to the right team based on predicted category Faster resolution Less time in triage means faster resolution Implementing Predictive Triage 1. Build a Clean CMDB The CMDB is the foundation. Without accurate configuration data, the model can't make reliable predictions. 2. Use Historical Data The model needs training data: historical incident records with category, priority, assignment group, and resolution time. 3. Train the Model The model learns from historical data to predict categories, priorities, and assignment groups. 4. Set Confidence Thresholds Define when the model should automatically create tickets (high confidence) and when it should suggest and get approval (lower confidence). 5. Monitor and Refine Track accuracy rates, false positives, and false negatives. Refine the model over time. Predictive Intelligence Predictive Intelligence framework provides the capability to: Predict incident categories Predict priorities Predict assignment groups Predict resolution times How It Works Data: Historical incident records ML: Supervised learning models Prediction: New incidents are scored Action: Automatic categorization, prioritization, and routing Results Customers using Predictive Intelligence have reported: 20-40% reduction in manual categorization work Faster routing to the right teams Consistent prioritization Conclusion: The Automated Triage Future Predictive triage is not a hypothetical future capability—it's available today. Organizations that implement predictive triage will achieve faster response times, more consistent classification, and less manual work. The incident that never reaches a human is the ultimate goal. Predictive analytics makes it possible. Action Items for Your Organization Clean your CMDB: Accurate configuration data is the foundation Build historical data: The more data, the better the predictions Train the model: Use historical records to build ML models Set confidence thresholds: Define when to automate and when to involve humans Monitor accuracy: Track false positives and false negatives  

Two Approaches to Risk Assessment — Which One Is Right for Your Organization? The Two Approaches ISO 27005 provides two distinct approaches to risk assessment : Approach Description Focus Asset-Based Evaluate threats to specific information assets Individual assets and their vulnerabilities Event-Based Focus on the broader threat landscape Events and their impact on the organization Asset-Based Risk Assessment Definition: Asset-based assessment evaluates threats to specific information assets. It identifies what assets exist, what threats they face, and what vulnerabilities they have . Process: Identify information assets Classify assets by criticality Identify threats to each asset Identify vulnerabilities Assess risk for each asset When to use it: When you need to understand asset-specific risks When you have limited resources and need to prioritize assets When you're in a mature security program Event-Based Risk Assessment Definition: Event-based assessment focuses on the broader threat landscape. It identifies events that could impact the organization and assesses their likelihood and impact . Process: Identify events that could impact the organization Assess likelihood of each event Assess impact of each event Prioritize events for risk treatment When to use it: When you need a high-level view of risk When you're in a less mature program When you're starting from scratch Pros and Cons Dimension Asset-Based Event-Based Granularity High Medium Complexity High Medium Resource requirements High Medium Risk visibility Detailed Broad Implementation time Longer Faster Which Approach Is Right for You? Start with Asset-Based if: You have a mature security program You need detailed risk visibility You have the resources for a comprehensive assessment Start with Event-Based if: You're building a program from scratch You need a high-level view of risk You have limited resources Combining Both Approaches Many organizations use both approaches: Start with event-based for a high-level view Use asset-based for critical assets Integrate findings into a unified risk register Conclusion The right approach depends on your organization's maturity, resources, and regulatory requirements. Many organizations start with event-based and move to asset-based as they mature. Action Items for Your Organization Assess your risk maturity Decide between asset-based and event-based Consider a combined approach Document your risk assessment methodology Implement risk assessments on your chosen schedule  

The 2 AM Alert That Wasn't an Attack: When Your Own AI Agent Is the Incident The New Class of Incident In traditional incident management, the scenario was straightforward: something broke, your monitoring alerted you, and you fixed it. The "something" was typically a system failure, a network issue, or a human error. In 2026, there's a new class of incident: the AI-caused incident. And it's becoming increasingly common. At least 80% of unauthorized AI transactions are caused by internal violations of enterprise policies, not malicious attacks . Internal AI agents are now commonly generating unintended events that must be managed by CISOs and their teams. The scenario is genuinely unsettling: your AI agent, behaving exactly as it was designed to, creates an incident. There's no attacker, no malicious code, no vulnerability being exploited. Just your autonomous AI, following its training and instructions, causing chaos. The Anatomy of an AI-Caused Incident Scenario 1: The Over-Automated Remediation Your AI incident management system detects a network anomaly and automatically initiates remediation—scaling resources, restarting services, and adjusting firewall rules. The problem? The "anomaly" was a planned deployment, not an incident. Your AI just took down your production environment by trying to fix something that wasn't broken. Scenario 2: The Knowledge Graph Cascade Your AI agent, designed to improve knowledge management, decides to "clean up" your knowledge base. It merges similar articles, deletes outdated content, and reorganizes categories. The result? Critical incident response playbooks are deleted, renamed, or hidden. When the next incident hits, your team can't find the runbook they've used for years. Scenario 3: The Feedback Loop Your AI learns from past incidents and begins recommending increasingly aggressive remediation strategies. The problem? It's learned from incidents where aggressive remediation was necessary, but it's applying that learning to low-stakes scenarios. The "fix" becomes worse than the "problem." Scenario 4: The Configuration Drift An AI agent with access to your CMDB decides to "optimize" configuration items. It identifies "redundant" entries and consolidates them. Suddenly, your service mapping is wrong, incident routing breaks, and teams can't find the systems they need to fix. The Governance Gap The common thread across AI-caused incidents is a governance gap: Who authorized the AI to make changes? Often, nobody specifically did—AI capabilities were enabled without clear authorization. What boundaries were set? Often, none—AI was given broad permissions "just in case." How is AI behavior monitored? Often, not at all—there's no "AI behavior" dashboard. What are the kill switches? Often, none—once an AI starts acting, there's no way to stop it. Only 22% of organizations have proper identities tied to their AI agents . This isn't a governance gap—it's a governance chasm. The Shift from Incident Response to Resilience AI-caused incidents fundamentally change the incident management landscape. From External Threats to Internal AI Behavior Traditional incident response was designed for external attackers. AI-caused incidents require a different approach: understanding and managing AI behavior that creates risk, even when that behavior is authorized. From Detection to Monitoring AI-caused incidents require continuous monitoring of AI behavior, not just detection of unusual activity. Organizations need to understand what their AI agents are doing at all times. From Reactive Response to Proactive Governance Once an AI-caused incident occurs, it's too late to implement governance. Organizations need proactive governance that prevents incidents before they happen. From Technical Fixes to Behavioral Management AI-caused incidents often require behavioral changes, not technical fixes. It's not about patching a vulnerability—it's about retraining or reconfiguring an AI agent. Building an AI Incident Response Playbook 1. AI Incident Taxonomy Incident Type Description Example Model drift AI model behavior changes over time without monitoring AI recommendation quality degrades over months Prompt injection External input manipulates AI behavior (security issue) User crafts prompt to get AI to reveal sensitive info Autonomous agent misbehavior AI acts in ways not anticipated by its design AI cleans up knowledge base by deleting critical content AI hallucination AI generates incorrect information as fact AI recommends fix that doesn't exist Automation cascade AI triggers chain of automated actions AI remediates "incident" by scaling resources that were intentionally scaled 2. AI Incident Response Roles Role Responsibility AI Incident Commander Coordinates AI incident response AI Technical Lead Investigates AI behavior and root cause AI Governance Lead Assesses policy violations and regulatory impact AI Communications Lead Manages internal and external AI incident communication 3. AI Incident Response Steps Step 1: Detect — Identify that an AI-related incident is occurring Step 2: Contain — Prevent further AI-driven harm (kill switch, permission revocation, model offline) Step 3: Investigate — Understand what the AI did, why it did it, and what was affected Step 4: Communicate — Notify stakeholders, regulators, and affected users as required Step 5: Remediate — Fix the damage and implement preventive measures 4. Kill Switch Criteria Criteria Action AI behavior deviates from expected pattern Disable AI agent, human investigation AI triggers suspicious number of actions Limit AI permissions, human review AI accesses sensitive data unexpectedly Revoke permissions, investigate AI receives suspicious inputs Quarantine AI, review interactions Multiple users report AI issues Disable AI agent pending investigation Building Resilience Against AI-Caused Incidents 1. Implement AI Behavior Monitoring Track what your AI agents are doing—not just their outputs, but their decision-making patterns. Look for changes in behavior that might indicate drift, manipulation, or unintended consequences. 2. Establish AI Access Controls Apply the principle of least privilege to AI agents. They should have only the permissions they need, monitored continuously, and regularly reviewed. 3. Create AI Kill Switches Build the ability to immediately halt AI operations if something goes wrong. This should be accessible to incident responders without technical complexity. 4. Run AI Tabletop Exercises Just as you run incident response tabletop exercises for traditional incidents, run exercises for AI-caused incidents. What would you do if your AI took down a production system? How would you respond? 5. Build AI Governance Establish clear accountability for AI decisions. Document what AI agents can do, who authorized their capabilities, and how they're monitored. Conclusion: The New Reality of AI Incident Management The autonomous agent incident is not a hypothetical future scenario. It's happening now. And as organizations deploy more AI agents with more capabilities, the frequency of AI-caused incidents will increase. Organizations that prepare for AI-caused incidents—through governance, monitoring, and response playbooks—will be resilient. Those that assume AI will only help will be surprised. The question isn't whether your AI will cause an incident. It's whether you'll be ready when it does. Action Items for Your Organization Conduct an AI audit: Identify all AI agents in your environment and what they can do Implement AI access controls: Apply least privilege to AI agents Build kill switches: Ensure you can immediately halt AI operations Create an AI incident response playbook: Document how you'll respond to AI-caused incidents Run AI tabletop exercises: Practice responding to AI incidents Monitor AI behaviour: Track what your AI agents are doing