A perspective from our Customer Success team.

A lot shipped at Team ’26 this month. Rovo Studio and Agents in Jira went GA, the Teamwork Graph CLI hit beta, MCP support expanded, the Dia browser is live. If you run an Atlassian environment, you’ve probably already seen the headline list.

We’ve spent the weeks since digging into something the headlines don’t cover: what these announcements actually demand of the environment underneath them. Because the through-line across all of it is that Atlassian is becoming an execution platform, and that shifts the question every admin and platform owner should be asking. It’s no longer “do we have the feature.” It’s “is our environment ready for it.”

Here are the four announcements we think enterprise teams should be watching, and the questions worth asking about each.

1. Atlassian is becoming an AI execution platform

The Rovo announcements were the loudest part of the keynote: expanded AI-assisted workflows, autonomous task capabilities, deeper integration across Jira and Confluence. Read together, they point somewhere specific. Atlassian is moving past work management and toward AI-assisted operational execution.

The shift that matters is in the relationship. Rovo started as something you ask questions to. It’s becoming something that coordinates and acts. That’s a different kind of tool, and it changes what good looks like.

Picture an engineering leader heading into a deployment review. The old version of that evening meant pulling release blockers off Jira boards, cross-referencing Confluence pages, and chasing four people for status updates. The new version is a single request: summarize the critical release blockers, flag any unresolved dependencies, and draft stakeholder updates for tomorrow’s review. The workflow compiles it in seconds.

That only works if the underlying work is structured enough for Rovo to reason over it. And it raises questions most teams haven’t had to answer before: which workflows are appropriate for AI-assisted automation, how much autonomy is acceptable in each one, and how those automated actions get audited after the fact.

2. The Teamwork Graph is becoming enterprise infrastructure

Atlassian opened up the Teamwork Graph at Team ’26, letting AI systems and external tools securely interact with organizational context across Jira, Confluence, and connected systems.

This is the announcement we find most validating, because it confirms something we’ve been telling clients for years: the value of your Atlassian environment was never the screens or the workflows. It’s the relationships across all of it. The graph connects projects to owners to dependencies, ties documentation to approvals, links goals to the history of how the work actually went. AI gets dramatically more useful when it can see those relationships instead of isolated records.

The implication is clear: The quality of your organizational context is becoming one of the biggest differentiators in how much value you get from enterprise AI. Organizations with well-connected systems and clean metadata will pull ahead. Organizations with fragmented tooling and inconsistent data will watch the same features underperform and wonder why.

A release manager asking which unresolved dependencies could impact our Q3 launch should get blocked epics, missing approvals, ownership gaps, and related incidents surfaced in seconds. They will, if those relationships are captured in the graph. If they aren’t, the AI can only work with what it can see.

The questions to sit down with: which systems should connect to the graph, and are the permissions around that access properly scoped and governed?

3. Poor Jira hygiene is now a business risk

We’d put this at the top of the list, even though it wasn’t a product announcement at all. It was the theme running underneath every other one, and it’s the one with the most direct consequences for the teams we work with.

Here’s the change. Before AI, poor Jira hygiene created inefficiency. A board was cluttered, a report came out wrong, someone wasted an afternoon reconciling two sources of truth. Annoying, rarely dangerous. Once AI is reading your workflows and acting on them, the same inconsistent ownership and stale metadata produce wrong recommendations and incorrect automations, at machine speed and with a confidence the output never earned.

A scenario we can see playing out: an AI workflow auto-escalates a production incident using ownership data stored in Jira. The data is eight months stale, and the listed owner changed teams in the spring. The escalation routes to the wrong person. The right person never gets paged. Response time slips during an active outage, and nobody can immediately explain why. The AI did exactly what it was told. The data told it the wrong thing.

That’s the shift in a sentence. Your metadata used to be housekeeping. Now it’s the foundation your automations stand on.

The questions that follow are uncomfortable for most environments: how standardized are our workflows and metadata, is ownership actually current, and are permissions governed or just inherited?

4. MCP is emerging as an enterprise AI standard

Atlassian expanded support for MCP, the Model Context Protocol, a standard that lets AI systems securely interact with enterprise tools and organizational context. In practice, it means AI platforms and coding assistants can now reach Jira and Confluence context through governed interfaces.

The easiest way to think about MCP is as a common connector for AI systems, the USB-C of the category. It’s shaping up to be foundational plumbing, and it opens real possibilities: AI-assisted development, workflow orchestration, copilots that actually understand your environment instead of guessing at it.

A developer in their IDE can ask their AI coding assistant to show all unresolved dependencies tied to this feature branch and summarize any related incidents, and the assistant pulls that context straight from Jira and Confluence without the developer leaving their workflow. Genuinely useful. It’s also another door into your environment, and every door is a governance and security conversation.

Before turning MCP on broadly, the questions to resolve are which integrations you actually want enabled, how permissions will be governed across them, and what audit controls and security boundaries need to be in place first?

What this adds up to

The pattern under all four announcements is the same. Atlassian is betting on the graph and opening it up. The payoff is real, but it accrues to the environments that are ready for it.

Success in the next two quarters won’t come from enabling features. It’ll come from governance, operational maturity, and data quality.

For most teams, the right next move isn’t a strategic overhaul. It’s smaller and more concrete:

• Review governance and permissions, with particular attention to who can build agents versus who can use them.
• Standardize the workflows and metadata your automations will depend on, starting with ownership and the fields that drive routing.
• Pick one low-risk, high-value workflow to pilot, and treat it as a way to learn what your environment actually needs.

If you’re trying to figure out where your Atlassian environment stands today and where a sensible first step is, that’s a conversation we’re glad to have.

To talk through what Team ’26 means for your environment, contact us today.

Almost every leader we talk to is being asked the same question right now, and very few of them realize it’s a trick question. The question is “what’s our AI strategy.” The trick is that the real answer isn’t a strategy at all. It’s an architecture decision, and most organizations are making it without noticing they’re making it.

Here’s why. The agent is the easy part now. Capable models have become something you buy by the seat, and the gap between the best and the second-best narrows every quarter. What actually separates the companies getting real value from the ones quietly funding a graveyard of pilots is something less visible: where the AI sits relative to the work, and how much of the organization’s real context it can see from that position.

An agent is only ever as good as the context it can reach. So the question that looked like it was about AI turns out to be about architecture, and the architecture is something most companies already have, assembled by accident over years of buying tools one problem at a time.

There are two credible ways to answer it. They lead in different directions. The difference matters more than the marketing on either side suggests.

Answer one: put the intelligence inside the platform

The first approach puts the AI layer inside the platform that already encodes how a domain operates.

The strongest example in the market today is Atlassian’s Teamwork Graph. Two decades of work have accumulated inside Jira and Confluence, and that history is not just a pile of tickets and pages. It’s a map of how an organization actually runs: which projects depend on which others, who owns what, which decisions were made and why, how today’s incident connects to last quarter’s change.

Atlassian has spent the last year turning that map into something its agents can reason over. Rovo gets meaningfully smarter as the graph fills out, because it inherits context no general-purpose model could reconstruct from scratch.

When one platform genuinely owns a domain end to end, this is the right answer. And it isn’t close. Picture a release manager heading into a launch review. The question on their mind is which unresolved dependencies could derail the quarter. Inside a well-tended Atlassian environment, an agent can answer that in seconds, because the dependencies, the owners, the blocked work, and the related incidents already live in one connected structure. The intelligence is useful precisely because it never has to leave the place where the work lives.

The limit is the same as the strength. This approach is powerful inside the domain the platform owns, and it has little to say about everything outside it.

Answer two: put the intelligence across the stack

The second approach starts from a fact every leader knows but few architectures account for: no organization runs everything through one platform.

Engineering may live in Atlassian, but sales lives in the CRM, finance lives somewhere else again, and the executive team lives in mail and calendar. A knowledge worker’s actual day crosses six or eight systems. The work that matters most often happens in the spaces between them, where no single platform has authority and no single graph has visibility.

The across-the-stack approach puts the AI layer there, in the flow of the user’s work rather than inside any one domain’s data model. Superhuman is the platform we’re betting on for this, because it’s built to meet people inside the tools they already use and to carry consistent governance across all of them, rather than asking the organization to re-platform onto one vendor’s world.

Picture an account executive preparing for a renewal. The history they need is scattered: the deal in the CRM, the implementation issues in a support tool, the contract terms in email, the relationship context in three months of meeting notes. No domain platform owns that picture, because the picture isn’t a domain. It’s a person’s job. An across-the-stack layer can assemble it because it follows the user instead of the system.

The limit here is the mirror image of the first approach. This layer goes everywhere, which means it rarely has the deep, structural context that a domain-owning platform accumulates over years.

Where the clean line breaks down

It would be tidy to draw a clean line between these two and tell you which side to stand on. The truth is messier.

The line is moving. Atlassian is building outward, not just inward. Its support for the Model Context Protocol (MCP) and its growing library of connectors are bets that other systems and other agents will increasingly reach into the Teamwork Graph, and that the graph will reach back out. Meanwhile, the across-the-stack platforms are developing real depth inside their own surfaces, so the breadth-versus-depth contrast softens a little every quarter.

What stays distinct, underneath the converging features, is the organizing center of gravity. One approach is built around the data model of a domain and reasons outward from there. The other is built around the user’s flow of work and reasons inward toward whatever systems that work touches. Those are genuinely different design philosophies, and they will stay different even as each one borrows capabilities from the other.

Which is why the question for most leaders was never “which one wins.” Both will be present in any mature environment. The within-the-platform layer will keep getting smarter at the work it captures, and the across-the-stack layer will handle everything that lives in the gaps.

The useful question is narrower and more practical: which of the two is missing in your organization right now.

A way to tell which one you’re missing

You can usually find the answer by asking where the friction actually is.

If the work that matters most runs deeply through a single platform, and the complaint you hear is that your people can’t get good answers out of a system that clearly holds the data, you are probably under-invested in the within-the-platform layer. The context is there. Nothing is reasoning over it.

If the work that matters most crosses many systems, and the complaint you hear is that AI helps in pockets but nobody can see value at the level of a whole role or a whole team, you are probably under-invested in the across-the-stack layer. The intelligence exists inside individual tools. Nothing is following the person between them.

A few questions tend to surface which case you’re in:

• Where does the work that matters most actually live, and is it one platform or many?
• Which of your platforms genuinely own a domain end to end, and which only own part of it?
• Where would AI need to follow a person across tools to be useful?
• And where do governance, audit, and measurement need to be consistent across systems rather than configured one tool at a time?

None of those questions require a finished AI strategy to answer. They require a clear look at how work moves through the organization you already have.

The decision you can’t get wrong by moving

There’s a quiet anxiety underneath the “are we behind” question. The anxiety assumes there’s a single right architecture, that choosing wrong is expensive, and that the safest move is to wait until the picture clears.

The opposite is true. Because both layers will end up mattering, and because the right place to start is almost always one team and one workflow, this is not a decision you can get catastrophically wrong by moving.

It’s one you can only get wrong by waiting. The organizations that will look prescient in two years are not the ones that picked the correct architecture in advance. They’re the ones that put something real into motion early, learned what their environment actually needed, and let the strategy follow the evidence instead of preceding it.

That is the work, and it’s why we sit where we do. As an Atlassian Platinum Solution Partner and a Superhuman Alliance Partner, we work across both sides of this choice. Not because we’ve decided one of them wins, but because the honest answer for most organizations is some of both. The architecture is the question. We help you find the first place to start answering it.

If you’re trying to work out which layer is missing in your environment, and where a sensible first step would be, reach us at contact@e7solutions.com.

Powerful alerting and on-call management tools for Dev and Ops teams.

Opsgenie is a comprehensive solution that offers unparalleled alerting and on-call management tools for Dev and Ops teams. It is an ideal choice for teams looking to remediate issues quickly and efficiently while keeping customer satisfaction high. The best part? Integrating Opsgenie with the tools you use every day is super easy! You can easily integrate it with Jira, Jira Server, Jira Service Desk, and Statuspage, among others.

Opsgenie is also compatible and integrates seamlessly with hundreds of the best monitoring, workflow, and collaboration tools. It boasts a flexible rules engine that allows Dev, Ops, and IT teams to plan for service disruptions effectively, stay in control during incidents, and take rapid action when necessary. With Opsgenie’s notification system, you can be sure that the right people will be alerted in real-time, ensuring that your team can resolve any issues efficiently.

Whether you’re working with a small team or a large enterprise, Opsgenie’s flexibility is unmatched. It can easily integrate with over 200 apps and web services to sync alert data and streamline workflows. This powerful tool ensures that your team can focus on what they do best, secure in the knowledge that Opsgenie is working in the background to ensure everything runs smoothly.

In summary, Opsgenie is the ideal solution for any Dev or Ops team looking to keep customer satisfaction high, remediate issues quickly, and stay in control during incidents. With its easy integration, flexible rules engine, and seamless collaboration with monitoring and workflow tools, Opsgenie is a must-have for any organization looking to streamline their operations and stay ahead of the competition.

Want to know more? Click the image above to watch a demo and learn how to:

• Understand Opsgenie’s core functionality and the benefits of the platform.
• Dev, Ops, and IT teams can plan for service disruptions and stay in control during incidents with Opsgenie’s flexible rules engine.
• Integrate Opsgenie with over 200 apps and web services to sync alert data, and streamline workflows

To learn more about Opsgenie, contact E7 Solutions today.

Automation used to require long programs and value that showed up “later.” In 2025, you can embed AI, automation, and orchestration directly into the flow of work and see measurable ROI within a single quarter. Start with high‑volume, rules‑driven tasks, wire in AI for intake and validation, automate routing and approvals, and make everything auditable. Then track cycle time, deflection, SLA compliance, and first‑pass yield to prove impact fast. McKinsey reports concrete gains when gen‑AI is embedded in service operations, including a 65 percent reduction in agents’ knowledge‑lookup handle time and significant shifts to automated contacts as programs scale.

What you will get in this guide

• A clear definition of embedded automation and why it matters now
• Outcome‑centric metrics that show ROI in weeks, not months
• A practical 30‑60‑90‑day rollout roadmap
• Where E7 accelerators plug in to compress time to value

---

What “embedded automation” means in 2025

Embedding automation is not about adding another standalone tool. It means weaving AI, automation, and orchestration into daily workflows so value appears without disruption.

• AI at the front door
  • Turn on Atlassian’s Virtual Agent in a limited channel and define 5–8 guided flows that collect complete data up front.
  • Use short, structured knowledge articles to power high‑confidence answers and guided actions.
  • Measure resolution, containment, and hand‑off satisfaction separately to find improvement hotspots.
• Automation in the middle
  • Automate routing, approvals, and escalations with risk‑aware rules to eliminate hand‑offs and idle time.
  • Use delegated approvals for low‑risk work; enforce SLA timers and auto‑escalations for stalled decisions.
  • Instrument each rule with a clear purpose and owner; require before/after metrics for every change.
• Context engine
  • Import priority services or suppliers into Assets and relate CIs to requests and changes.
  • Display dependency graphs during approvals so approvers can see blast radius quickly.
  • Auto‑notify CI owners when high‑risk work is proposed.
• Orchestration across systems
  • Keep Jira, Confluence, and line‑of‑business apps in sync with a lightweight hub such as Coda Packs.
  • Replace spreadsheet status with live views that pull from the source of truth.
  • Centralize actions (approve, comment, update) so teams don’t context‑switch across tools.
• Governance by design
  • Treat prompts, automations, and rules as versioned configuration with links to decisions in the ticket.
  • Define redlines (what AI may not do) and safe actions (what AI may do without human approval).
  • Review prompts and rules monthly; rotate any high‑impact changes through the change process.
• Why now
  • AI adoption is mainstream in 2025, shortening the path from pilots to production.
  • Platforms ship ready‑to‑use capabilities (Virtual Agent, Assets) that reduce setup time.
  • Teams have more examples and governance patterns, lowering change risk.

---

Outcomes to target and how to measure them

ROI is a business conversation. Baseline the last 90 days, then review weekly leading indicators and quarterly lagging results. Publish a single dashboard with owners and thresholds, and tie improvements to specific changes (for example, “intake validation v2” or “delegated approvals v1”).

Speed and Reliability

Speed without quality creates rework. By compressing cycle time and tightening first‑attempt success, you reduce cost while increasing trust in automation.

Metric	How to measure	Target (90 days)	Owner	Notes
Cycle time (median, p90)	Request → completion by type, approver group, hand‑offs	20–40% faster on targeted flows	Service Owner	Use p90 to expose bottlenecks hidden by averages
First‑attempt success	Rollbacks and rework per change/request	+10–20 points	Automation Engineer	Insert a lightweight PIR checklist into tickets
Approval lead time	Submission → decision; include auto‑approved standard work	30–40% faster	Service Owner	Time‑box delegated approvals with SLA timers

Service Performance

Better performance is the downstream effect of clean intake, correct routing, and strong context. Teams resolve faster, with fewer surprises.

Metric	How to measure	Target (90 days)	Owner	Notes
MTTR	Link incidents to changes and affected CIs; segment by CI criticality	10–25% improvement	Ops Champion	Auto‑tag incidents with probable blast radius from Assets
SLA compliance	Breach rate by step (intake, approval, implementation, verification)	<5% breach on targeted flows	Service Owner	Insert lightweight PIR checklist into tickets
Post‑deploy incident rate	Incidents within 24–72 hours post change	−20%	Automation Engineer	Require verification tasks and rollback criteria

Capacity and Focus

Automation should return time to high‑value work, not just move clicks around. Measure what you actually get back and where it’s being used.

Metric	How to measure	Target (90 days)	Owner	Notes
Deflection rate	Virtual‑agent resolution and guided completion by channel	15–30%	Knowledge Lead	Segment by topic to prioritize content gaps
Time returned	Before/after time studies on time per request; roll up to team level	3–6 hrs/agent/week	Service Owner	Reinvest time into backlog grooming, research
Knowledge reuse & FPY	Article reuse per 100 requests; first‑pass yield on forms	Reuse >2.0; FPY +15 pts	Knowledge Lead	Use dynamic forms to raise FPY over time

Implementation notes

• Publish a single dashboard with owners and thresholds for each metric.
• Tie improvements to specific changes (e.g., “intake validation v2” or “delegated approvals v1”).
• Review exceptions weekly and convert recurring issues into backlog items.

---

Roles and skills for an automation‑ready team

Clear ownership is the difference between momentum and stall. Assign named owners, even if one person wears two hats.

Role	Top responsibilities	Key KPIs	Cadence
Service Owner	Own ROI targets, prioritize backlog, approve policy/rule changes	Cycle time, SLA compliance, time returned	Weekly metrics review
Automation Engineer	Build intake flows, routing, approvals; maintain versioned automations	First‑attempt success, approval lead time	Bi‑weekly change window
Knowledge Lead	Curate articles/snippets; run freshness SLAs; close content debt	Virtual‑agent resolution, knowledge reuse	Weekly content stand‑up
Model Steward	Govern prompts/models, run drift and safety reviews, manage redlines	Evidence completeness, exception rate	Monthly governance board
Ops Champion	Drive adoption, surface friction, run office hours and change comms	Portal usage, channel mix, CSAT	Weekly office hours
Practice Alignment (ITIL 4)	Maintain one‑page RACI, thresholds, and playbooks	Policy adherence, audit pass rate	Quarterly practice review

---

Guardrails first: governance that keeps you compliant

Speed and safety are not opposites. Build controls into the workflow so people move fast and stay inside the rails.

• Policy clarity
  • Define standard, low‑risk, and high‑risk paths for common request types; document where AI may act and where human approval is required.
  • Publish short “policy‑in‑a‑paragraph” tooltips in forms and virtual‑agent flows so users understand expectations.
  • Keep a one‑page policy map in Confluence and link it in every relevant Jira screen.
• Risk models
  • Start with deterministic rules using inputs like CI criticality, recent incidents, size, spend, and test coverage; introduce ML only after data quality is proven.
  • Version model features and thresholds in a readable config file; require approvals for any change.
  • Review false positives/negatives monthly and tune rules to improve path accuracy.
• Approvals and evidence
  • Delegate low‑risk approvals with SLA timers and auto‑escalations; reserve targeted CAB for high‑risk.
  • Capture decisions, timestamps, and rationale inside the issue; block closure if required artifacts are missing.
  • Use checklists for rollback, test evidence, and verification; auto‑attach AI summaries.
• Audit logging
  • Treat prompts and automations as configuration items with unique IDs and change history.
  • Log exceptions and rationale in the ticket; attach policy checks and risk scores as artifacts.
  • Run quarterly audit sampling; publish findings and fixes to a shared runbook.
• Continuous oversight
  • Hold a monthly governance review covering model drift, prompt efficacy, deflection quality, and SLA breaches.
  • Conduct security checks on access, PII handling, and retention; align with company data policies.
  • Route control changes (prompts, models, rules) through the same change process—no shadow updates.

---

A Blueprint for Operationalizing Embedded Automation

Jira Service Management and Coda can give you a practical stack to embed AI and automation where work actually happens.

• Virtual Agent
  • Enable in Premium or Enterprise and start with 5–8 guided flows for the most common intents.
  • Offer guided completion options to gather everything downstream approvers need.
  • Track containment vs. resolution and review low‑CSAT transcripts weekly to improve.
• Risk‑aware workflows and approvals
  • Add approval steps and rules that calculate risk and select the correct path automatically.
  • Pre‑approve standard work and create fast lanes for low‑risk requests; reserve human reviews for edge cases.
  • Instrument each step with SLA timers and aging reports to catch stuck work early.
• Assets (CMDB) as your context engine
  • Import top services/suppliers and relate CIs to requests and changes for a single pane of impact.
  • Use relationship graphs to visualize blast radius during approvals and incident response.
  • Auto‑notify owners of affected CIs when a high‑risk change is proposed.
• Knowledge and orchestration
  • Build short, structured articles; track reuse and keep freshness SLAs.
  • Stand up a Coda hub with Packs to avoid tool sprawl and centralize actions.
  • Replace spreadsheet status with live views that pull from the source of truth.

---

Process design: from “CAB by default” to “CAB by exception”

High‑maturity teams reserve human debate for the few changes or requests that truly warrant it. Everything else flows through fast lanes with guardrails.

Step	What happens	Examples	Measurement
AI‑assisted intake	Purpose, scope, rollback, test evidence captured; user guided to correct path	Virtual Agent forms with dynamic fields and inline examples	First‑pass yield; incomplete submission rate
Automated risk score	CI criticality, dependencies, incidents evaluated; score displayed	Weights tuned by service tier; spend thresholds for supplier flows	Path accuracy; exception rate
Pathing	Standard auto‑approve; low‑risk delegated with timers; high‑risk targeted CAB	Change windows for standard; CAB roster by CI ownership	Approval lead time; CAB volume
Execution & verification	Linked tasks, smoke tests, post‑deploy checks run	Git/CI links; auto‑rollbacks for failed checks	Post‑deploy incident rate; verification SLA
Learning	Knowledge updated; Assets relationships adjusted; backlog items created	Auto‑create knowledge stubs; summarize PIRs in ticket	Knowledge reuse; recurrence of similar issues

---

A 30‑60‑90‑day roadmap to ROI

Start small, move fast, and measure relentlessly. Aim for visible value in 30 days and a durable operating model by day 90.

Days 1 to 30 — Prove value quickly
Timeline	Deliverable	How to deliver	Proof of value
Week 1	Live portal + minimal risk fields	Configure JSM project; add required fields only	Baseline cycle time and FPY visible
Week 2	Virtual Agent live with 5–8 flows	Enable in one channel; publish a how‑to video	Containment and resolution metrics start tracking
Week 3	Assets seeded with top services/suppliers	Import CIs; link to requests/changes	Approvers see impact context in‑ticket
Week 4	Three paths (standard/low/high) active + dashboard	Define rules; add delegated approvals; publish dashboard	Cycle time down; first‑pass yield up; SLA compliance visible

Days 31 to 60 — Expand and harden
Timeline	Deliverable	How to deliver	Proof of value
Week 5	CAB‑by‑exception + delegated approvals	Add approval steps; codify thresholds; time‑box SLAs	Approval lead time drops; CAB volume declines
Weeks 6–7	Dependency maps + training	Map relationships; publish Confluence playbook; run office hours	Fewer misroutes; faster hand‑offs
Week 8	PIR automation + reporting	Auto‑attach AI summaries; add verification tasks	Post‑deploy incident rate falls; PIR completion rises

Days 61 to 90 — Scale and govern
Timeline	Deliverable	How to deliver	Proof of value
Week 9	Two additional teams live	Reuse proven flows; templatize intake and approvals	Cross‑team consistency; faster onboarding
Weeks 10–11	Governance and safety reviews	Launch monthly governance; add redlines/safe actions	Exceptions decline; audit readiness improves
Week 12	Quarterly value report	Integrate incident/problem signals; publish ROI, MTTR, SLA, deflection	Executive‑ready narrative of outcomes

---

Common pitfalls and how to avoid them

Most automation programs fail quietly. Use this checklist monthly and assign an owner to each risk.

Pitfall	Risks	Signals to watch	How to fix
Automating chaos instead of process	Bot accelerates the wrong work; low trust in results	Low FPY; heavy rework; long comment threads clarifying basics	Start with standardized flows; add dynamic forms; publish examples; create a “content debt” backlog with owners
No audit trail for AI and automations	Compliance failures; hard RCAs; shadow prompts	Decisions in chat; missing evidence on closed tickets; inconsistent approvals	Treat prompts/rules as config items; auto‑attach summaries and policy checks; block closure if evidence missing; quarterly sampling
Over‑engineering before proving value	Months of design with little usage; budget erosion	Complex flows, low adoption; constant rework; stakeholder fatigue	Land quick wins (deflection, delegated approvals); set WIP limits; require before/after metrics for every new rule
Under‑investing in adoption and training	Teams bypass the portal and bot; email and meetings creep back	Low portal usage; high email volume; repeated “Where do I go?”	Office hours; 60‑second clips; links to the bot in signatures and intranet; track channel mix weekly
Ignoring practice alignment and governance	Conflicting rules; unclear ownership; CAB gridlock	Ad‑hoc exceptions; recurring policy questions; stalled approvals	One‑page RACI; codified thresholds; monthly reviews for prompts/models; govern control changes via the same change process
Metrics without action	Dashboards exist, behavior doesn’t change	Static trends; recurring breaches; unowned red metrics	Assign metric owners; weekly “top 3 risks”; tie actions to backlog items with dates; review outcomes in leadership forums
Tool sprawl via side integrations	Fragmented data; broken hand‑offs	Duplicated fields; conflicting statuses; brittle connectors	Maintain an integration catalog; use declarative templates; review new connections in governance; deprecate redundant forms

---

Key takeaways

• Embedded automation compresses cycle time and reduces manual friction when AI, approvals, and orchestration live in the workflow. Atlassian, Coda, and others can provides the building blocks to operationalize this pattern.
• ROI in weeks is achievable by targeting high‑volume, rules‑driven work and measuring deflection, first‑pass yield, cycle time, and SLA compliance from day one. McKinsey’s service‑operations results offer credible benchmarks.
• Adoption risk is lower in 2025 because AI usage is mainstream and platforms ship ready‑to‑use virtual agents and asset context.
• Governance is a design constraint, not a blocker; ITIL 4 and Gartner’s focus on agentic AI and governance make continuous oversight non‑negotiable.
• With E7, automation becomes a System of Work, not another IT project. Accelerators help you ship quick wins while building durable controls.

---

Why E7

E7 Solutions specializes in transforming digital operations by aligning technology and teams to strategy. We focus on sustainable growth, platform clarity, and empowering leaders to make bold, confident decisions. From complex migrations to operational unification, we don’t just deliver projects; we empower transformation with purpose and velocity.

• Atlassian Platinum Solution Partner with ITSM specialization and a track record of cloud, service management, and work management outcomes.
• Supplier Service Management to stand up supplier portals, automated approvals, and escalation handling on Jira Service Management for “minutes not weeks” onboarding.
• Product Operations Acceleration to connect your existing tools into a single operating rhythm, cut operational drag, and improve delivery speed in a few as 30 days.
• Advisory, Service Management, Training, and Managed Services so the wins you land scale with governance and quality.

---

About the author

Edmond Delude is the Founder and CEO of E7 Solutions, a consulting firm specializing in service management, digital operations, and AI‑driven transformation. With over 25 years of experience as an entrepreneur and executive leader, Edmond helps organizations modernize their platforms, align strategy with execution, and unlock sustainable growth. His work combines deep technical expertise with a human‑centered approach to leadership, enabling teams to thrive while delivering measurable business outcomes. Edmond is a recognized voice in the intersection of technology, leadership, and operational clarity.

---

Works cited

• McKinsey & Company — From promising to productive: real results from gen AI in services (Aug 16, 2024) — https://www.mckinsey.com/capabilities/operations/our-insights/from-promising-to-productive-real-results-from-gen-ai-in-services
• Stanford Human‑Centered AI — AI Index 2025 overview — https://hai.stanford.edu/ai-index/2025-ai-index-report
• Stanford Human‑Centered AI — AI Index 2025 full PDF — https://hai-production.s3.amazonaws.com/files/hai_ai_index_report_2025.pdf
• Gartner — Top Strategic Technology Trends for 2025 — https://www.gartner.com/en/articles/top-technology-trends-2025
• Atlassian — JSM Virtual Agent product guide — https://www.atlassian.com/software/jira/service-management/product-guide/tips-and-tricks/virtual-agent
• Atlassian — Set up your Virtual Agent (Support) — https://support.atlassian.com/jira-service-management-cloud/docs/set-up-your-virtual-agent-in-jira-service-management/
• Atlassian — Asset and configuration management in JSM — https://www.atlassian.com/software/jira/service-management/product-guide/getting-started/asset-and-configuration-management
• Atlassian — IT asset and service configuration management in JSM (handbook) — https://www.atlassian.com/whitepapers/it-asset-and-service-configuration-management-in-jira-service-management
• Atlassian — Add an approval to a workflow — https://support.atlassian.com/jira-service-management-cloud/docs/add-an-approval-to-a-workflow/
• AXELOS — ITIL 4 Practitioner: Change Enablement — https://www.axelos.com/resource-hub/blog/itil_4_practitioner_change_enablement
• Coda — Overview: use Packs in Coda — https://help.coda.io/en/articles/2414769-overview-use-packs-in-coda
• Coda — Admin Pack basics — https://help.coda.io/en/articles/8550050-coda-admin-pack-basics
• E7 Solutions — Supplier Service Management — https://www.e7solutions.com/solutions/supplier-service-management
• E7 Solutions — Advisory Services — https://www.e7solutions.com/advisory-services-e7-solutions
• E7 Solutions — Managed Services for Atlassian — https://www.e7solutions.com/managed-services-for-atlassian-e7-solutions
• Atlassian Partner Directory — E7 Solutions — https://partnerdirectory.atlassian.com/e7-solutions-llc

What is Incident Management?

According to Atlassian, an incident is described as “an event that causes disruption to or a reduction in the quality of a service which requires an emergency response.” For example, an incident can range from minor intermittent errors to a major or global web crash. There is a high priority in having a focus and strategy on incident management, as incidents can become costly or damaging to business. In fact, based on industry surveys by Gartner, Atlassian noted that network downtime can cost more than $300,000 per hour. In addition to the costs of network outages, other occurring incidents can also cost teams time while waiting for the incident to be resolved.

The solution for these types of situations, though, is proven successful when the tasks and services affected resume to regular functioning. Once the incident is resolved, the incident postmortem takes place to identify the root cause of the incident as well as plan actions to prevent the re-occurrence of the incident. As there are several incident management processes for every type of organization to adapt, each one of those processes have the same focus and significance in supporting companies through the occurrences of incidents.

Basic Incident Management Process

At E7 Solutions, we take Incident Management seriously, making sure to be as transparent and communicative not only within the company but also with our customers. Before we dive too deep into Incident Management, let’s start with a basic process for managing incidents.

1. Guide and build: Incorporate autonomous decision-making and consistency culture among teams in identifying, managing, and learning from incidents. There will not always be a clear answer, but guiding and building together can move the process along more effectively.
2. Align teams: Develop an understanding of which attitude is appropriate for each aspect of incident identification, resolution and reflection.
3. Detect: Continuously monitor and attend to incidents before customers discover them, as issues can be resolved before becoming incidents.
4. Respond: “Don’t hesitate to escalate.” It is better to bring awareness of a potential incident even if it does not affect everyone than to stay silent.
5. Recover: Service will go down from time to time uncontrollably; this is understood as long as the incident is resolved as quickly and efficiently as possible.
6. Learn: In reference to the value above, mistakes or accidents will occur but proper accountability and gained knowledge from those situations can improve for better delivery of service.
7. Improve: Break down the incident, starting from the exact root cause to the necessary and strategic actions to prevent or reduce the chance of the incident occurring again. Set dates for those actions.

In a perfect world, everything would run smoothly, and there would be no such occurrence of incidents. However, the real world has proven endless times that it hides nothing from the possibility of problems happening now and then. With that said, it is important to identify the cause of incidents, develop consistent procedures to resolve among dedicated teams, plan actions that can reduce or prevent re-occurrence, and learn from each one to tackle those situations accordingly.

We’re just getting started on the various topics associated with Incident Management, such as Atlassian tools dedicated to incident management processes, incident response, best practices for incident communication, and more. Check out our Incident Management detailed guides.

Though advancements to technology are constantly evolving, it is clear incidents that can affect either minor organizations or large areas of the world, such as internet outages, can still find its way around those advancements and put a halt to production. What may not be clear, however, is the behind-the-scenes of those incidents. Is the organization aware of this issue? What are they doing to fix the problem, and when will it be resolved? Read below to gain insight on the 7 steps Atlassian uses in its transparent incident response strategy.

1. Detect: Those within your organization can be made aware of incidents in several ways other than simply discovering them, such as monitoring or customer reports. In any form of an incident being found, it is important to log a ticket for it. Atlassian members can then check if an incident is in progress. The five fields to fill in to obtain the most information about each incident are: summary, description, severity, faulty service, and affected products.

2. Implement communication channels: Open communications are essential in being considered in order to address the incident quickly. Once the ticket is created, the issue evolves to the fixing stage and is assigned to an incident manager. That designated member then prepares communication channels to establish and narrow a focused communication strategy, which typically includes a chat room, a video chat, and a Confluence page.

Sending follow-up communications wraps up the communication strategy for resolving an incident. Follow-ups keep both customers and staff in the loop of the incident’s progress and develops a stronger trust with the organization. It is likely information on the incident will be little to none in the beginning, but making those involved aware from the start will only help them follow along as the incident progresses. An example of a strong follow-up message will consist of a small summary of the incident’s current state, with up to four bullet points on where it stands and what the next steps look like, and a date representing when another follow-up message is planned to be sent out.

3. Assess and apply severity: After the communication channels are implemented, the severity of the incident is assessed to decide what response level meets the level of severity. Some key focus points debated to determine that level are whether the impact of the incident is internal or external to the customer, how many customers are affected by the incident, and when the incident started.

There are three severity levels among the one that will be assigned to the incident: critical incident with very high impact, major incident with significant impact, and a minor incident with low impact (see the image below for examples of each). The establishment of the incident’s impact is then followed by confirmation of the severity.

4. Communicate to customers: Sending initial communications on the incident is the next focus, as communicating both internally and externally will focus the incident response in one place and prevent avoidable confusion. Communicating with the customer that the organization is aware of a problem and is taking action to resolve it is just as important as communicating with the team about incident status and any new incidents because each action taken helps to build trust with both sides.

5. Escalate: This stage in the incident response process describes where more teams may need to get involved in resolving an incident than just the first responders. Opsgenie, a page rostering and alerting tool, allows teams to build lists of team members that can be contacted in an instance of an emergency. Having a list of reliable individuals to contact in certain dire situations is important because the alternative of having one specific individual can result in failure to resolve the issue, due to several circumstances of potentially being unavailable.

6. Delegate and iterate: When a member from one of those lists in the escalation stage is contacted, the role is delegated to that member. Again, communication is a major focus here, as the member will need an understanding of the incident and the role at hand in order to work quickly and effectively. The incident roles Atlassian uses are: the incident manager, the tech lead, and the communications manager.

The incident manager has overall responsibility and authority regarding the incident and will need to take necessary action to resolve the incident. The tech lead develops theories on what is broken and the reason why and decides and executes changes that need to be made to resolve the incident. Finally, the communications manager writes and delivers internal and external communications on the incident.

This stage also represents the iteration of the incident response process. It begins with observing what is happening and communicating observations with others, developing possible reasons for the occurrence of the incident, performing experiments that determine whether those reasons are the true causes, and repeating. This cycle is designed to be followed for many incident response scenarios.

7. Resolve: The resolve stage represents the end of the incident, where the current or imminent business impact is over. Any cleanup tasks are then performed and can be tracked to the main issue. The last round of internal and external communications is sent, explaining through a quick recap the impact and duration of the incident in addition to the number of support cases received.

In times of technical challenges such as incidents, transparency, and communication are vital in effectively overcoming those times. From detecting the incident immediately to communicating with the necessary team members to assist in the resolving process, Atlassian’s incident management strategy enforces strong communication along every step to build trust with organizations affected by the incident.

---

At E7 we offer Journey to JSM packages which are designed to get your team into JSM with all the guesswork removed. Our out-of-the-box packages include strategic guidance, design workshops, assessments and recommendations, implementation, and training. More than a proof of concept, you’ll have our expert analysis, scorecards to measure continued success, and a fully realized service management solution!

Stop wasting valuable resources with your service management systems and start your Journey to JSM today with E7 Solutions.

Incidents can always happen. Growth and advancements in applications increase the chances for incidents to occur. Despite this, learning from those incidents can provide value to organizations by fulfilling postmortems.

A postmortem is “a written record of an incident” that describes the following items: the incident’s impact, actions that were taken to resolve the incident, causes of the incident, and any follow-up actions taken after to prevent the re-occurrence of the incident. By evaluating the incident and creating postmortems, the value of the incident is maximized because at that point it has become an unexpected investment in the reliability of the system affected.

Here are seven questions to help frame the importance of postmortems and best practices.

1. When are postmortems needed, and who completes them?

Postmortems are typically needed when major incidents occur, such as a severity 1 or 2 level incident. Though they are only considered necessary when it comes to significant incidents, postmortems can be completed for any level of incident where it may seem useful.

The postmortem is usually completed by an assigned member belonging to the team that delivered the service that caused the incident. It is “owned” by that person from the draft to when it becomes published. At times where incidents involve infrastructure or are platform-level, a program manager may be called to run the postmortem.

2. Why should postmortems hold zero blame?

Human nature tends to handle a problem by finding someone to blame when a problem occurs. Though this is the “easy” thing to do, it is not the best. Doing so can harm how effective the postmortem is depending on the situation of the incident. For instance, the team member completing the postmortem may leave out important factors of how the incident occurred if it serves as a potential risk to that team member’s job or reputation from peers. The focus should be held more on why the system faulted in allowing an error to be made rather than how the individual involved reacted.

3. How are postmortems processed?

The duration of how a postmortem is processed includes completing a postmortem issue, running a meeting, and capturing actions. Finally, gaining approval and communicating the outcome. There are several methods helpful in developing effective postmortems, but the right one depends on the culture of the organization.

• Single-point accountability: Assignee of postmortem ticket holds responsibility of postmortem results.

• Face-to-face meetings: This furthers analysis quickly, creates shared understanding, and aligns the team.

• Service Level Objective: A goal is set to complete postmortems with frequent reminders and reports.

A how-to guide for Problem Management in JSM can be found here.

4. What are postmortem issue fields?

In addition to the many ways postmortems are processed, multiple issue fields can be helpful. These are completed in an effort to collect all the important details needed to discuss in the postmortem meeting. Below are a few examples.

• Incident Summary: A few sentences explaining the incident, its severity, and impact.

• Leadup: A description of circumstances or occurrences leading up to the incident.

• Fault: Data showing fault in system working incorrectly.

• Recovery: A detailed explanation of how and when restoration of service occurred.

• Five whys: Five potential identifications of the incident’s root cause.

5. What is the difference between proximate and root causes?

Postmortems are significant for discovering root causes and finding ways to mitigate them so incidents can be further prevented. Root causes are why the chain of events led to the incident occurring, whereas proximate causes are reasons that led directly to the incident.

6. What do postmortem meetings consist of?

Similar to most meetings, postmortem meetings are important in providing effective and quick communication as well as developing deeper understanding and stronger learning. The main points to hit during postmortem meetings are to: remind the team that postmortems are blameless, follow the timeline of events during the incident, present the theory of the incident’s causes, encourage open thinking, and ask open-ended questions on how situations or handling can be improved.

7. What are postmortem actions, and how are they tracked?

There are different categories for postmortem action items, inspired by presentations and articles by Sue Lueder and Betsy Beyer of Google. From investigating, mitigating, and repairing damage from the incident to detecting, mitigating, and preventing future incidents, these actions are important in developing a strong postmortem.

Every action stemming from postmortems is tracked with Jira issues. Next, actions are linked as “primary action” or “improvement action.” This depends on whether there is a significant mitigation or indirect actions coming from the postmortem.

---

Check out our How-to series on Incident Management, or contact us if you are looking for ways E7 Solutions can help your organization with incident management. Also, be sure to check back to our site for more incident management to come!

Atlassian defines IT service management as “how teams manage the end-to-end delivery of IT services to customers.” From design to support, all aspects of ITSM should level down to being considered as a service.

Along with Atlassian, we believe teams come first. Why does this matter to ITSM? IT teams are the core and backbone necessary to enable productivity and digital transformation that can improve all teams. Without valuing and motivating these teams to make a difference in the organization’s everyday processes, there is little to no room for organizational growth or improvement. There is more reason ITSM is important to organizations, so let’s dive in.

In this article we will discuss:

• Why ITSM Matters
• ITSM Management Processes
• ITSM Tools

Why ITSM Matters

Although a lot of importance ITSM has to an organization lies within improving the principles of service management, it actually instills significant structure and provides multiple benefits to other areas of the organization, such as raised efficiency and productivity levels, aligned business goals and standardized service delivery. Most importantly, strong ITSM procedures incorporated into an organization increase customer satisfaction.

Atlassian has an ongoing list of further ITSM benefits, but here are a few E7 believes stand out the most and can save your organization on costs:

• Success metrics that measure the alignment of business priorities with IT teams
• Sharing the knowledge of IT teams with other teams to forward overall advancement
• Offering self-service or other quicker support services to further customer experience

ITSM Management Processes

The evident reality of technology’s endless advancements in today’s world provides a lot of room for improvement across all sectors of an organization. From tearing down traditional processes to upgrading to more modernized procedures, consistency, efficiency, and stronger productivity are a few aspects that modern IT teams can experience with the resources available now. The major ITSM processes can be found and described below:

Knowledge Management

There is much that can be and is learned by all team members that can help others within an organization. Implementing an effective way to store helpful information is summed by the term knowledge management. It is crucial to incorporate continuous learning among all teams, as knowledge is one of the most useful and available tools.

IT Asset Management

Organization is a key component of keeping an organization running smoothly and efficiently. By applying IT asset management, assets can be accounted for, deployed, maintained, upgraded and eventually disposed of. It may be discovered that some assets were not being used to the full potential, and some may be useless clutter than can be removed or is no longer useful to the organization. Either way, implementing this process makes it easier to level out the values and tangibility of items.

Incident Management

Incidents are always going to occur and disrupt service from time to time. Unfortunately but realistically, no system, equipment or technology is built to lifelong perfection. However, developing a process where incidents can be responded to by teams in an effective and organized manner is where incident management comes into play and makes dealing with incidents less overwhelming for your organization and your customers affected by them. This process is important to apply to organizations because it may just save over $300,000, while in their course, that is how much some large incidents cost each hour. Below are some benefits of incident management we place a narrow focus on:

• Reduced costs from lost time or revenue for the result of incidents on organizations
• Improved ability to measure incident resolution
• Stronger communication while incident is in motion, creating less chaos
• Stored information that can be used effectively for future incidents

Change Management

Change is the ultimate driver for growth in many instances, specifically when it comes to business and competition. This ITSM process, change management, is essential to implement within an organization as it involves limiting or preventing as much disruption to customers’ access and response capability to IT services as possible. It can be tricky to work on systems and services that are critical as the chance of causing an interruption is always possible, but it is also critical to engage in practices that can prevent the likelihood of incidents. There are two major practices of change management in relation with ITSM, which are IT change management, now referred to as “change control,” and organizational change management.

Enterprise Service Management

A lead up from general IT service management is enterprise service management. This process represents a binding of the effective use of IT teams and services to other areas of the organization, such as marketing, finance or HR. One of the most rewarding aspects that we find when helping customers maximize the use of Atlassian tools is how many ways it can improve both the inner and outer workings and functions of an organization.

ITSM Tools

As mentioned above, all things ITSM should be considered as a service. That’s why there is such a narrow focus on the service portal, which is one of the most important tools that can be used as an interface for connection between IT teams and customers. Today, the fast-moving pace of technology and its impact on leading industries is putting more depth and weight on ITSM tools to be faster, always available and provide ample and stellar customer experience.

In order to stay up-to-date with the rapid evolution of technology today, ITSM is the heart of where your organization should look to accomplish that. No longer is IT service management solely about support, it’s about ample and available service as well as being an ultimate provider for your customers. This is where Service Management can accelerate your business and empower teams to support your organization whole-scale, from IT to HR.

If your organization is in need of implementing an effective Incident Management process or other support on ITSM, we’re your team! At E7 we offer Journey to JSM packages which are designed to get your team into JSM with all the guesswork removed. Our out-of-the-box packages include strategic guidance, design workshops, assessments and recommendations, implementation, and training. More than a proof of concept, you’ll have our expert analysis, scorecards to measure continued success, and a fully realized service management solution.

Stop wasting valuable resources with your service management systems and start your Journey to JSM today with E7 Solutions.

From IT to HR, technology provides the services, tools and advancements all teams need to accelerate organization and efficiency levels. Some Atlassian IT services, such as Jira Service Management, focus on team collaboration and work visibility to produce faster delivery. Others, like ITSM and ITIL, go hand-in-hand with aligning methodologies and practices that equally accelerate productivity for an organization. Similar to the way ITSM and ITIL have their individual contributions to an organization’s functioning success, ITIL and DevOps also share this type of relationship.

What is DevOps, and What is ITIL?

You can probably guess that the term DevOps is a collaboration of the words “development” and “operations,” but what exactly does it refer to? The purpose of DevOps is to increase transparency and communication levels among the development teams and IT operations teams to build stronger business value.

We’ve recently discussed the role ITIL offers to organizations, which serves as a framework for ITSM methodology and is a set of practices and guidelines that support and align IT procedures and business strategies. ITIL lays down the guidelines for businesses to follow in handling incident management, change management, and more.

ITIL and DevOps contribute to teams in individual fashion but complement one another in the process. Though it is common to find that organizations stick to using one approach, there are clear and cost-efficient purposes as to why a combination of approaches can be taken. Now, let’s discuss how ITIL and DevOps are capable of existing underneath the same roof, working both together and separately to support your teams working at high velocity.

How to Handle Incidents Better with ITIL and DevOps

The dependency organizations have on technology to operate their infrastructure is high and constantly increasing. Even when things go wrong, teams rely on technology to fix it. Therefore, in cases where incidents can cause major harm for your organization and negatively affect your customers, it is crucial to act quickly on them to reduce or prevent the damage altogether. To manage incidents effectively, they can be categorized and monitored with tools that can increase issue detection and data visibility, helping your IT team identify and work to resolve the problem, keeping productivity flowing for your end-users.

Collaboration and Team Empowerment at High Velocity

The common beliefs that ITIL is solely guidelines and DevOps is a conjunction of operational development are correct, but they do volumes more than that to empower teams. Atlassian is not shy about incorporating teamwork into almost everything they do, and ITIL and DevOps are not excluded. Organizational silos are defeated by the collaborative, blameless cultures of these IT services that keep teams moving and improving.

How ITIL and DevOps Can Save Cost and Time for Teams of All Sizes

Whether your organization is considered a start-up, a leading enterprise or major corporation, the benefits of understanding how to tackle aspects like change management and incident management are a must in case of a predicted or unexpected outage. Tools like SLAs, incident postmortems, and automations can positively impact teams of all sizes in terms of customer satisfaction and cost-saving.

SLAs are Service Level Agreements that stem from ITIL, and they outline your objectives and progress with your customers to reduce misunderstandings.

Postmortems are DevOps-based collaborative tools that help your team work through mistakes or incidents together in a blameless, honest fashion. These can help your organization save cost and time by increasing both comfortability and transparency levels for your team members. When your team feels they can openly address actions that may have caused an incident, there is increased opportunity for improving incident response and a better chance of decreasing or preventing chances of the incident recurring.

The general idea that incorporating IT services is important for organizations to do. However, applying a high-level understanding and application of IT services, like ITIL and DevOps, can help your team through the duration of an incident in several ways, including:

• Enforcing stronger, honest relationships among teams
• Saving your organization time and cost
• Preparing your team for incidents

Like Atlassian, we’re here to help your team accelerate to their full potential. You can learn more about how we can help you implement Atlassian ITSM tools and services by visiting ourJira Service Management pages, viewing our ITSM webinar below, or just by contacting us!