ETRMSolutionETRMSolution

Energy Trading · Managed Support

Improving ETRM Production Support and Incident Resolution

An energy trading company's ETRM support process had no formal triage structure, resulting in unpredictable resolution times and a trading desk that had stopped reporting minor issues.

Illustrative example. This case study is an anonymized composite representative of engagements we run, not a disclosure of a specific named client.

The Challenge

Every ETRM issue, regardless of severity, was routed to the same small internal team with no formal prioritization. Critical issues sometimes waited behind minor cosmetic requests, and the trading desk had grown used to working around known issues rather than reporting them.

Existing Environment

An in-house ETRM support team of two, covering an enterprise ETRM platform for a multi-commodity trading desk, with support requests submitted informally over chat and email.

Root Cause

There was no defined severity classification, no formal escalation path, and no visibility for the trading desk into whether a reported issue was being worked on.

Solution

We implemented a structured L1/L2/L3 support model with defined severity levels and response-time targets, set up a proper intake and ticketing workflow, and added a daily health-check routine to catch market data and position issues before the desk encountered them. We also provided supplemental L2/L3 capacity during peak periods and after-hours.

Support model

Issue Reported (Ticketed Intake)
L1 Triage & Severity Classification
L2 Functional/Technical Resolution
L3 Root-Cause Investigation (as needed)
Resolution & Desk Notification
Daily Health Check (Proactive)

Implementation

  • Defined severity levels and response-time targets with the trading desk's input
  • Stood up a ticketing workflow to replace informal chat-based requests
  • Built a daily health-check routine covering market data, positions and key reports
  • Provided supplemental L2/L3 support capacity for peak periods and after-hours coverage
  • Reviewed resolution metrics monthly with the internal team

Result

  • Average resolution time for critical issues dropped substantially after severity-based triage was introduced
  • The trading desk began reporting minor issues again once they had visibility into resolution status
  • Several recurring issues were caught by the daily health check before affecting the trading desk

Technologies

AllegroTicketing/workflow toolingMonitoring scripts

Lessons Learned

  • A trading desk that stops reporting issues is a warning sign, not a sign that problems have gone away - visibility into resolution status matters as much as resolution speed.
  • Proactive daily health checks consistently catch issues earlier and more cheaply than reactive support alone.

Working through something similar?

Tell us about your environment and we'll walk through how we'd approach it.