Bajaj Finserv

A user reports a problem. Maybe in a Teams channel. Maybe by email to production support. Maybe in a group chat that three other people are also typing in. At Bajaj Finserv Health, that message used to land in a dozen places at once, and someone on the support team had to catch every one of them by hand.

Sunil Chaudhari manages that team. When he took over production support, the intake looked like this: engineers reading through Teams channels and inboxes one message at a time, replying, fixing, and then, at the end of each month, going back through everything to count it. How many issues came from labs. How many from the pharmacy. How many from the hospital side. The tally lived in an Excel sheet, built by hand, for a slide deck that management reviewed every month.

It worked. It also took one to three hours a month to assemble, and nobody could say for certain the numbers were right.

The problem wasn't effort. It was visibility.

Bajaj Finserv Health runs a digital health platform: lab bookings, pharmacy, hospital services, wallets, claims. Each area generates its own support issues, and each issue arrived through whichever channel the user happened to pick. Teams. Email. A group chat. The support engineers caught what they could.

The gap showed up in two places. First, acknowledgment. When the same problem gets pinged by several users across several channels, a human reading manually will eventually miss one. Second, reporting. Management wanted issues broken down by module, by severity, by volume over time. Producing that meant reconstructing a month of scattered messages from memory and a spreadsheet.

So this was a very tedious job to get this data before IMR. We were using Excel to note down the issue ... it took a lot of valuable engineering hours.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

Custom implementation to eliminate duplicate alerts

The team brought in Xurrent IMR and connected it to the two channels their users actually use: Microsoft Teams and email. The routing rule they asked for was specific. The first message in a Teams channel creates an incident. Replies in that thread do not. A follow-up is part of the conversation, not a new ticket.

Email works the same way. A note to production support is recorded as an incident the moment it arrives, no manual logging required.

The effect was immediate. Instead of reading channels to find work, the team gets an incident card in Teams the moment something is reported. From that card they acknowledge, resolve, add a command, or open a ticket in their dev tooling without leaving the conversation.

If someone pings on Teams, the very first issue raised by a user gets the incident created in Xurrent IMR. And if someone replies to that thread, an incident should not be created again. That was the requirement, and it's recording now.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

Acknowledgement in minutes, from the right responders

Bajaj Finserv Health holds an official 10-minute target to acknowledge an incident. Before, with issues spread across inboxes and chats, hitting that target depended on whoever was watching the right channel at the right moment. Now the card surfaces in Teams and the clock is visible.

Sunil puts the real number lower than the SLA.

It's within 5 minutes, in fact maybe within a minute or so. It hardly takes any time to acknowledge now because of the implementation for IMR.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

The severity model sits underneath this. A P0 is a broken journey: payments down, the app crashing, a user who cannot complete a booking at all. A P1 is real but survivable, like a wallet balance that will not apply at checkout when the user can still pay another way, or a UI issue where a different flow gets the user through.

A P0 does not wait out a normal release cycle. The team ships a hotfix within one to two hours, and if a fix is going to take longer, they roll back the production deployment within 10 minutes. On average, a P0 is fixed on the customer front within an hour, and the full fix follows a standard three-day maximum cycle time, their SOP. P1 issues, where a workaround exists, carry a seven-day ceiling because those changes ride the normal release train. Across all severities, average resolution runs three days.

Put together, the lifecycle now has numbers attached to every stage, and the team is beating its own targets. Against a 10-minute acknowledgment SLA, the team acknowledges in under 5 minutes, often within one. Critical issues get a first response inside 15 minutes, and a P0 is fixed on the customer front in an hour on average. 

Because the data now comes straight from Xurrent IMR, every one of those figures is measured rather than estimated, and none of them depend on a person remembering to watch a channel.

Escalation that reaches the right team

The four-person support team works as Level 1 on a rotating roster, covering 7:00 AM to 10:00 PM including weekends. Most issues stop there. The team carries standard operating procedures for the common cases, a data sync between two systems, a functionality question, an expected behavior a user has flagged, and resolves them without pulling in anyone else.

When an issue needs a code fix, it moves. The team opens a bug in Azure DevOps, the dev team analyzes and fixes, QA tests, beta validates, and the release goes to production. Once it ships, support closes the loop with the user and updates the incident in Xurrent IMR.

For a P0, the response is heavier. Sunil pulls the dependent teams into a war room and drives the issue to root cause, because a broken journey cannot wait out a normal cycle.

Nobody wants to take the issue on their plate, so the war room is necessary. As many teams as it takes, we get to the root cause and fix it, because the P0 cycle time can't go beyond three days. That's our SOP.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

From a spreadsheet to a 360° dashboard

The reporting problem solved itself once intake was clean. Every incident is captured in one place, so the monthly review no longer starts with reconstruction. The team can pull volume by month, see whether issues are trending up or down, and show management a count it trusts.

The hours that used to go into assembling that picture, one to three a month, now go back to the work. More than the time, Sunil points to confidence: the data reflects what actually happened, not what could be pieced together afterward.

After this integration, whatever incident has been created in Xurrent IMR, that's the number we had in the past month. There's transparency now, whether the issue count has increased or decreased.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

The support behind the rollout

The integration was new when we spoke, in place for about a week, with user education still underway as the team moved everyone from legacy group chats into the proper support channels. What Sunil volunteered without prompting was the help he got from Varun, our Support Engineer, building it.

The availability without hesitation is the part I really like. The knowledge of the product and the integration is really good. I even searched LinkedIn to leave a recommendation.

Sunil Chaudhari, Engineering Release Manager, Bajaj Finserv Health

Results with real business impact

Since moving their incident management and response onto Xurrent IMR, response times, visibility, and reporting accuracy have all improved measurably.

• Fragmented intake → unified, automatic capture: Teams and email are now the two connected channels, with a routing rule that creates one incident per issue from the first message in a thread, so replies don't trigger duplicates.
  Business impact: engineers no longer hand-monitor channels and now get incident cards the moment something's reported. Intake risk on a patient-facing platform drops sharply as a result.
• Manual, error-prone reporting → zero-touch, trusted reporting: The 1-3 hours spent hand-building the monthly Excel report dropped to zero, since every incident is already logged in Xurrent IMR by the time the month ends.
  Business impact: the team redirects those hours to resolving issues instead of accounting for them, and leadership now reviews numbers pulled straight from the system, with a full audit trail.
• No unified visibility → 100% capture in one dashboard: All modules (labs, pharmacy, hospital, wallets, claims) now feed a single dashboard that shows volume and trend over time. Sunil says the team can now see whether issue counts are rising or falling.
• Inconsistent acknowledgment → sub-5-minute, often sub-1-minute, response: Against a 10-minute SLA, the team now acknowledges in under 5 minutes. Sunil says it's often within a minute.
  Business impact: users get a fast, consistent response regardless of which channel they used, rebuilding the trust that manual channel-watching couldn't guarantee.
• No performance tracking → a measured, accountable lifecycle: P0 issues now get first response inside 15 minutes and average customer-facing resolution within an hour, all tracked against documented SOPs (3-day P0 ceiling, 7-day P1 ceiling).
  Business impact: the team can now prove its own performance against targets, which helps justify resourcing and demonstrate service quality to stakeholders.

The shift Bajaj Finserv Health made

The team didn't change what it covers or how hard it works. It changed where the work starts. Intake is automatic, acknowledgment is tracked, escalation reaches the right people, and the monthly number is one nobody has to defend. The support engineers spend their time on issues instead of on accounting for them.

That's the version of production support every team wants. It starts with making sure no report slips through, and no acknowledgment gets missed.

‍