I'm trying to convince the team who is in charge of maintenance and development of our IM tool (OASIS) , that functional notification is absolutely necessary.
I mean, when an update is performed within a SR we're not the owner of (user callback, information update,...), the owner should be notified somewhere, preferably with an automatic notification (Email, ...)
But, in their opinion, this is better to create a new SR and to assign it to the relevant team to warn them, no matter how much call is placed by the requester, we have to open a new SR for each call...

This sounds like a management issue being clouded by a focus on the tool rather than the objective. I would need a lot more information to be able to comment usefully._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

I'm working as team leader in an IT environment, my team and i are acting as the SPOC for all IT request.

Our objective is to avoid delay in incident management, mainly avoid that a SR remain untouched by 2nd or 3rd level support teams, especially when a requester has called back, or providing with more information or requesting for a status update.

I'm also convinced this is a management issue but i would like to have your opinion...

Are you calling everything a service request? That is not helpful in a discussion here and is unlikely to be helpful in your organization.

What are the steps you follow for an incident?

Do you have a documented procedure to follow?

How do you (or how do you propose to) pass an incident to second line?

How do you record incident status changes? If you are the single point of contact, then all other teams/functions, must maintain status on the system so that you can advise users and customers without excessively interrupting the technicians.

The approach is not to argue over any specific aspect, but to establish policy, define objectives and derive procedural steps to meet these objectives and conform to policy.

Design a step-through of what you believe should happen and get input from all sections including quality management to determine if it meets your requirements in the best way possible._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

We mainly deal with IT incident, we register any of them in our ticketing system, we try to recover the functionality first hand, or we escalate it through the same tool to the second line.

My concern is that our ticketing system does not notify the actual owner of the ticket in case the status of the incident was modified (by owner i mean the second line in this case) The only notification occurs when the ticket get assigned (or assigned back to the first line), but not in case of any change in the status of the incident...

If needed, we still have the possibility to open the record, check for status update and inform the user, that's not the problem. But, in case we have to change the status of a ticket that is already assigned elsewhere, no one is informed about the update.

Raise a problem for your ticketing system. It needs to be modified or replaced to meet your requirements. Meanwhile design a workaround that ensures people are informed as required. It will help your case if you can isdentify the ongoing costs and risks in the workaround - but no cheating; design it as good as you can.

If you cannot do it as an IT service problem (but you should - that's what the system is for), then raise it with your quality manager / quality auditor. Getting an audit black mark can help to focus minds.

To underpin it either way, you need clear documented procedures. Without these you are fighting in treacle for any improvements.

Which is the third approach: propose a service improvement program. Again you do it easier with procedures in place and reliable historical data to aid the analysis.

If you want to do it right (and why not!), establish a full functional requirement specification for your service management tool set. The lack of this is what led you to where you are._________________"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718