Need your advise.
In my organization, we have number of customer incident tickets in customer pending status.
I do know that pending customer stops the SLA for time to resolve.
However, there is no SLA for how many days an incident ticket can be tagged as pending customer.
What is the recommended period:
1. Before the service line can proceed to close the incident ticket.
2. How many times (days) a service line should communicate with the customer before proceed to close the ticket if no respond from customer.

Not sure if there is a standard timeline for a request/incident to be in open status unless mentioned in the SLA agreed with the business.It depends from organisation to organisation.

However here's the practise we follow for various scenarios.

1) If a new incident/request is not assigned to an engineer due to insufficinet information or missing customer contact info, our SD will mail/phone the user reqeusting for more details .
If it is missing contact number of the user, we will email the user requesting the same.

All the email correspondance is saved in the internal techncal note for the knowledge of the SD and the engineers( which is not visible for the user).

If the required update is not received from the user with 2 Business days, a reminder email/phone call is made whichever is appropriate to the user, which is also documented in the ticket and in the email we notify the user that if we don't recive the required info by end of next day, the WO will be treated as closed.

2) If the scenario is where we the ticket is kept pending due to pending task from the csutomer and if they have given SD specific date to get back to us then we will wait for the same and in this case the SLA will be stopped.After the deadline if they don't revert, we send a reminder email and thereafter it will be closed if we don't hear from them.

TQ.
What about in situation where the issue is resolved but waiting for a confirmation from customer to close the incident.
1. How long do you think we should keep the incident in pending customer (business days)
2. How many email reminders should we send to customer.

This is just to avoid any dispute from customer.
I do see email from customer asking why his/her incident ticket is close without approval.
Even thou it was not mention in ITIL or OLA, maybe we can set an expectation

have you read the thread "SLA's and User status : Pending Customer" which is currently just below this thread and is very "fresh"?

You only ever close an incident when it has been resolved by the restoration of the service (or the discovery that the service is not - or no longer - in need of restoration, but these should be exceptional cases). In many circumstances it is not possible to be certain that service is restored without user/customer confirmation

If you believe a service is down or defective and cannot contact the user(s) affected for any protracted period, then it would make sense to escalate the issue through the customer organization (for example, the user's section manager). Protracted period could be ten minutes for a vital service or two days for something less significant.

That said, the real answer is to discuss this issue with your customer (not user), and come to an arrangement, enshrined in the SLA, for communications and protocols that will best serve the business. You cannot expect ITIL to answer this kind of detailed question, since there are a million valid answers.

If you try to establish criteria based solely on time and/or number of attempts to get in touch, then you are neglecting the business impacts implicit in incidents._________________"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

If customer confirmation is not practical, then you need another protocol in your SLA that agrees the criteria for closing incidents. This will almost certainly require some kind of monitor/review/audit activity to ensure it is working properly and it is in the IT service organization's interest to avoid errors in this area since they will most likely mean that one or more users are still not getting the service they ought and no one will be aware of it.

An example of this is when a user has lost a centrally provided service and that service is restored centrally, there can be circumstances where the user's PC fails to recognize the return of the service (whether from architectural problems or from efforts the user made to get at the service before it was restored. Therefore the service looks "up" at your end but is still effectively unavailable. If you are not able to communicate with the user, neither side will be aware of the situation._________________"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