News: Content of this SCN Doc will be maintained now in wiki page https://wiki.scn.sap.com/wiki/x/Vo_rGg

 

Purpose

 

With the following hints you will be able to configure the use of Service Level Agreement SLA to make sure that messages are processed within the defined period of time.

For configuring SLA you should get this document SLA Management from SAP SMP.

 

Here I will try to give you some hints for SLA configuration.

 

The screenshots are taken from a Solution Manager 7.1 SP05 with a Incident Management standard scenario configuration.

 

Overview

 

By setting up the SLA Escalation Management mechanism the system monitors when deadlines defined in the SLA parameters have been exceeded in the service process and which follow-up processes would be triggered. For example, email notifications will be sent to upper levels in the Service Desk organization like to responsible IT Service Managers to inform them immediately about expiration of deadlines and SLA infringements. Thereby, IT Service Managers are only involved in the ticketing process when it is really necessary.

 

Definitions

 

IRT

 

The IRT (Initial Response Time) represents the calculated point in time between the creation of the incident message and the first reaction by the processor
contracted in the SLA. This is realized via the “First Response By” timestamp which clarifies until what point in time the processor’s reaction on the created incident has to be performed at the latest.

When the processor starts processing the incident then it is enriched with the timestamp “First Reaction” for actual first reaction by the processor.

 

MPT

 

The MPT (Maximum Process Time) represents the calculated point in time between the creation of the incident message and the total processing time of the message contracted in the SLA. The MPT is realized via the timestamp “ToDo By”. Until this timestamp the incident has to be processed at the latest by the processor.

 

When the incident is closed by the reporter (in the case that a newly created incident is withdrawn or a proposed solution is confirmed) then the incident is
enriched with the timestamp “Completed” for actual incident completion.

 

 

Step 1. Copy transaction type SMIN -> ZMIN

 

We are going to work with ZMIN transaction type.

/wp-content/uploads/2013/09/image001_280133.png

Insist here on the fact that you should copy all transaction types into your own namespace or <Z>, <Y> namespace before starting to use Incident Management, copy transaction types, copy status profiles, action profiles, etc…if not your modifications to the standard will be overwritten after the next support package import. This is really important in Solman 7.1!!!

 

After each Support Patch applications you have the option to use report AI_CRM_CPY_PROCTYPE “Update option” to update already copied transaction types with new shipped SAP standard configuration.

 

 

Step 2. Define Service Profile & Response Profile

 

Transaction: CRMD_SERV_SLA (/nSPRO ->SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) ->Application Incident Management (service Desk) -> SLA Escalations ->Edit Availability and Response Times)

Example:

/wp-content/uploads/2013/09/image005_280139.png

 

Factory calendar must be a valid one, see transaction /nscal and notes 1529649 and 1426524.

 

Note: The usage of Holiday calendar in availability time is not supported by SLA date calculation i.e. you MUST use the option “Factory Calendar” or “All Days Are Working Days”.

Pay attention to the System time zone & user time zone. Check in STZAC (note: 1806990).

 

Create a response profile:

/wp-content/uploads/2013/09/image007_280141.png

/wp-content/uploads/2013/09/image009_280142.png

I would suggest to maintain the times always in MIN.

Make the same for all priorities.

 

3. Define SLA Determination Procedure

 

SM34 : CRMVC_SRQM_SDP (SPRO -> SAP Solution Manager IMG ->SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> SLA Determination Procedure)

 

Create your own SLA determination procedure:

/wp-content/uploads/2013/09/image011_280144.png

 

What is important here is to determine where are the response profiles and service profiles to check first, there are several alternatives:

Possible access sequence:

/wp-content/uploads/2013/09/image013_280148.png

 

 

– Service Contracts

Please note that currently Service Contract Determination is just recommended for upgrading purposes to SAP Solution Manager 7.1 SPS 05 to support already defined configurations. For enabling Service Contracts, the required customizing has to be performed (please keep in mind that usage of Service Contracts in SPS 05 are not supported at the moment by SAP – no adoptions and tests were performed for SPS 05).

 

– Service Product Item

A Service Profile as well as a Response Profile can be attached to a Service Product. The Service Product can also be assigned to specific master data like to the category of a defined Multilevel Categorization. In case of selecting this category during the incident creation process, the correct Service Product
will be determined as well as its defined Service & Response Profiles.

 

– Reference Objects (IBase Component)

 

A Service Profile as well as a Response Profile can be attached to a specific IBase Component. This means, if this IBase Component is entered during the
incident creation process, the related Service & Response Profile will be chosen.

 

– Business Partners (Sold-To Party)

 

A Service Profile as well as a Response Profile can be attached to a specific Sold-To Party (e.g. a Customer). This means, if this Sold-To Party is entered to the incident (manually by the Processor or automatically by a defined rule), the related Service & Response Profile will be assigned

 

The most frequently used are the SLA determination via Service Product item and Business Partners (sold-to party).

 

If you need your own SLA determination check BAdI Implementation CRM_SLADET_BADI  (IMG: Customer Relationship Management -> Transactions -> Settings for Service Requests -> Business Add-Ins -> Business Add-In for SLA Determination).

 

Now check that you linked this new SLA Determination procedure to ZMIN

/wp-content/uploads/2013/09/image015_280149.png

 

4.Define Settings for Durations

 

Specify the times to be recalculated when the status changes, under “Specify Duration Settings”.

 

SM30: CRMV_SRQM_DATSTA (/nSPRO-> SAP Solution Manager IMG ->SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations ->Define Settings for Durations)

 

Note 1674375 is having two attached files indicated entries to be inserted and to be deleted.

 

For solman 7.1 until SP04 included these should be the standard entries:

/wp-content/uploads/2013/09/image017_280203.png

 

For SP05 and above these are the default entries:

/wp-content/uploads/2013/09/image019_280204.png

 

Date profile is not the data profile of the ZMIN transaction type, this is the date profile of the item category used, usually SMIP, we will see details about this in Step 9.

 

Note: For SMIV incidents in VAR scenarios status E0010 Sent to Support  means that the incident is at solman side so the correct entries are:

Status Profile Status Date Profile Duration type                     Date type

ZMIV0001 E0010 Sent to Support SMIN_ITEM SRQ_TOT_DUR
ZMIV0001 E0010 Sent to Support SMIN_ITEM SRQ_WORK_DUR

 

As summary, if the status means that the incident is at processor side the correct entries are:

Status Profile Status Date Profile Duration type        Date type

XMIX0001 E000X SMIX_ITEM SRQ_TOT_DUR
XMIX0001 E000X SMIX_ITEM SRQ_WORK_DUR

If the status means that in the incident is at  key user side the correct entries are:
Status Profile Status Date Profile Duration type Date type
XMIX0001 E000X SMIX_ITEM                          SMIN_CUSTL
XMIX0001 E000X SMIX_ITEM SMIN_CU_DURA
XMIX0001 E000X SMIX_ITEM SRQ_TOT_DUR
XMIX0001 E000X SMIX_ITEM SRV_RR_DURA
See the meaning of the Duration fields:

/wp-content/uploads/2013/09/image023_280208.png

– Duration Until First Reaction:

This period of time is defined within the Response Profile and represents the basis for IRT calculation. Based on the selected incident priority, you should see the same values as defined in the Response Profile (dependencies between Incident Priority Level and “Duration Until First Reaction”).

 

– Duration Until Service End:

This period of time is defined within the Response Profile and represents the basis for MPT calculation. Based on the selected incident priority, you should see the same values as defined in the Response Profile (dependencies between Incident Priority Level and “Duration Until Service End”).

 

– Total Customer Duration:

The time duration when an incident message is assigned to the reporter (incident status is set to “Customer Action”, “Proposed Solution” or “Sent to SAP”) is
added and visible via the parameter “Total Customer Duration”.

 

– Total Duration of Service Transaction:

 

The time duration for the whole processing of the incident message is added and visible via the parameter “Total Duration of Service Transaction”.

 

– Work Duration of Service Transaction:

 

The time duration when an incident message is assigned to the processor is added and visible via the parameter “Work Duration of Service Transaction”.

 

 

See the meaning of Date Types fields:

/wp-content/uploads/2013/09/image025_280209.png

 

– Notification Receipt:

When an incident message is created by the reporter the system sets the timestamp “Notification Receipt” which represents the initialization of the service start. This timestamp is the basis for all future SLA time calculations.

 

– First Response By:

The IRT (Initial Response Time) represents the calculated point in time between the creation of the incident message and the first reaction by the processor contracted in the SLA. This is realized via the “First Response By” timestamp which clarifies until what point in time the processor’s reaction at the created incident has to be performed at the latest.

 

– First Reaction:

When the processor starts processing the incident then it is enriched with the timestamp “First Reaction” for actual first reaction by the processor.

 

– ToDo By:

The MPT (Maximum Process Time) represents the calculated point in time between the creation of the incident message and the total processing time of the message contracted in the SLA. The MPT is realized via the timestamp “ToDo By”. Until this timestamp the incident has to be processed at the latest by the processor.

 

– Completed:

When the incident is closed by the reporter (in the case that a newly created incident is withdrawn or a proposed solution is confirmed) then the incident is  enriched with the timestamp “Completed” for actual incident completion.

 

– Customer Status Changed:

The timestamp “Customer Status Changed” is set every time when the processor changes the status of an incident message to a customer status like “Customer Action”, “Proposed Solution” or “Sent to SAP”.

 

This information represents at what given point in time the incident was assigned to the reporter.

It is also the basis for IRT & MPT recalculation because customer times do not affect the SLA calculation.

 

 

Step 5. Specify Customer Time Status

 

/nSPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Specify Customer Time Status

 

Identify non-relevant customer times in the step “Specify Customer Time Status”. That means the clock is stopped while time is spent in these statuses.

 

Customer times are specified by the user status of an incident message. Defined Customer Times Statuses do not affect the SLA calculation (MPT calculation). This mechanism should prevent mainly for SLA  escalations if an incident has to be processed by another person than the processor.

 

The processor requires additional information from the reporter which is not included at the moment within the created message description. For an adequate processing, the incident will be commented with a request for providing additional information and assigned back to the reporter by the incident status change to “Customer Action”. The duration the reporter requires for enrichment of the incident should be excluded from calculation of SLA times because the processor is not able to take any influence on the time the reporter needs to provide the information (in the worst case the message is sent back to the processor and the MPT would be already exceeded). The period of time the message is on reporter’s side is added to the parameter “Total Customer Duration” and the MPT will be recalculated according to this value.

/wp-content/uploads/2013/09/image027_280220.png

 

Step 6. Create a product

 

If you decide to use the SLA determination based on Service Product Item you need to create a product.

Product INVESTAGATION will be created automatically when you perform in solman_setup for ITSM activity Create Hierarchy for Service products.

Execute transaction COMMPR01, find product ID  INVESTIGATION.

 

/wp-content/uploads/2013/09/image029_280221.png

Note: Use Unit of Measure MIN

That avoids errors which could be caused be  time rounds.

Ensure that SRVP is entered in the Item Cat. Group:

/wp-content/uploads/2013/09/image031_280222.png

Enter your service and response profiles.

 

Step 7. Check the Item Categories

 

SM34: CRMV_ITEM_MA  ( /nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Categories)

You can use SRVP:

/wp-content/uploads/2013/09/image033_280232.png

/wp-content/uploads/2013/09/image035_280233.png

 

Step 8. Check the Item Category Determination

 

SE16:   CRMC_IT_ASSIGN (/nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Category Determination)

You should see the relation between ZMIN, SRVP and SMIP.

/wp-content/uploads/2013/09/image039_280234.png

 

 

Step 9. Check SMIP Item category

 

/nSPRO IMG -> CRM -> Transactions -> Basic Settings -> Define Item Categories

Pay attention to the Date Profile.

/wp-content/uploads/2013/09/image041_280241.png

 

With these settings the SLA times (IRT and MPT) will be calculated for any created incident message according to the parameters set within “Investigation”.

 

 

Step 11. SLA Escalation

 

The following clarifies how SLA Escalation is working including the configuration of the email notification service.

The SLA Escalation mechanism is used to inform responsible staff like IT Service Managers immediately about expiration of deadlines and SLA infringements.

 

In the case that an incident message reaches the calculated IRT or MPT timestamp, the systems sets the status automatically at first to “Warning”. If the timestamp is exceeded than the incident’s status is set to “Exceeded”. In both cases an email notification will be triggered to defined partner functions.

 

Report AI_CRM_PROCESS_SLA is responsible for setting the warning/escalated status values once these thresholds are exceeded.

So firstly ensure that your incidents are receiving the correct status values (IRT/MPT warning/escalated).

 

Note that these are “additional” status values, which are not reflected in the main status of the incident. To view these status values, make the “Status” assignment block visible in the CRM UI, or view the Incident in the old CRMD_ORDER transaction.

 

If your incidents are not receiving the correct status values, the e-mail actions will not function correctly.

 

Then ZMIN_STD_SLA_IRT_ESC/ZMIN_STD_SLA_MPT_ES are intended to be scheduled based on the status of the incident, not directly on the evaluation of the respective durations.

 

11.1. Maintaining SLA E-mail Actions

In the standard SMIN_STD profile delivered by SAP, the following actions (smartform based) are responsible for generating e-mails once escalation conditions have been reached since SP04:

– ZMIN_STD_SLA_IRT_ESC

– ZMIN_STD_SLA_MPT_ESC

/wp-content/uploads/2013/09/image047_280242.png

/wp-content/uploads/2013/09/image049_280243.png

/wp-content/uploads/2013/09/image051_280248.png

/wp-content/uploads/2013/09/image053_280249.png

/wp-content/uploads/2013/09/image055_280250.png

/wp-content/uploads/2013/09/image057_280251.png

/wp-content/uploads/2013/09/image059_280252.png

/wp-content/uploads/2013/09/image061_280256.png

Please see the scheduling/starting conditions to ensure that they are appropriate for your customized transaction type ZMIN and ZMIN_STD action profile.

 

If you need to send also emails at warning times you will need to create actions:

 

– ZMIN_STD_SLA_IRT_WRN

– ZMIN_STD_SLA_MPT_WRN

 

Use the same settings than for the shown actions *ESC, the only difference is in the Start condition that you need to use IRT_WRN and MPT_WRN that do not exists by default, for fixing this:

1. Open BAdI implementation AI_SDK_SLA_COND in t-code SE19.

2. Change to Edit mode and deactivate this BAdI implementation.

3. Add Filter Values “IRT_WRN” and “MPT_WRN”.

4. Save and activate the BAdI implementation.

Then, you will be able to select IRT_WRN / MPT_WRN from the start condition list.

/wp-content/uploads/2013/09/image063_280259.png

 

11.2. Schedule SLA Escalation Background Job for triggering Email Notifications

 

Since SAP Solman 7.1 SP04:

/n SPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Schedule Escalation Background Job

 

Schedule a job for report AI_CRM_PROCESS_SLA running every 10 minutes for example.

This job is updating the SLA data for the incidents setting the additional user statuses (IRT Exceeded/IRT Warning/MPT Exceeded/MPT Warning).

 

Note: It could happen that in sm_crm->Incident search the search result shows for example IRT warning at IRT Status text for an incident, however in the incident itself this additional status is not set. The search is making his own calculation. But the emails are only triggered when the status is really set by
this report in the incident document.

 

Before SAP Solman 7.1 SP04 you need to schedule report RSPPFPROCESS.

 

11.3. Email Notification

 

In case that all previous described configuration activities were performed probably, email notifications will be sent automatically by following IRT and MPT
status conditions:

– Warning

– Exceeded

 

A default email will be sent with following parameter:

– In case that IRT is impacted (incident status “Warning” or “Exceeded”):

  • Subject: “Transaction: <Incident ID> First Response Exceeded”
  • PDF attachment with the same file name like the subject

 

/wp-content/uploads/2013/09/image065_280260.png

/wp-content/uploads/2013/09/image067_280265.png

– In case that MPT is impacted (incident status “Warning” or “Exceeded”)

  • Subject: “Transaction: <Incident ID> Completion Exceeded”
  • PDF attachment with the same file name like the subject

 

 

Step12. Activate SLA Escalations

 

/nSPRO -> SAP Solution Manager IMG -> SAP Solution Manager -> Capabilities (optional) -> Application Incident Management (service Desk) -> SLA Escalations -> Activate SLA Escalations

 

In transaction DNO_CUST04 set the attribute SLA_ESCAL_ACTIVE to ‘X’

 

Related Content

Related Documentation

SLA Management guide

 

Related Notes

Always check the SLA notes relevant for your patch level and ensure that you have implemented the latest version of the notes.

 

To report this post you need to login first.

28 Comments

You must be Logged on to comment or reply to a post.

  1. Raquel Pereira da Cunha

    Thanks for sharing Dolores.

    One of my customers is testing it right now, we’ll go live this week (I hope). Everything seems to be ok. We are using the Factory Calendar and Service Product Investigation.

     

    I had to do the additional steps that you explained to include the 2 new e-mail notifications: one for IRT Warning (IRT_WRN) and other for MPT Warning (MPT_WRN). I don’t understand why this is not included in the standard, if the standard configuration is prepared for WRN threshold. That was not included in the standard documentation (SLA guide) so it took me sometime to figure it out.

     

    I only miss in the blog the step where we configure the thresholds: table AIC_CLOCKNAME. I needed to change the standard limits that are:

    – Warning: 60%

    – Exceeded: 100%

    They need different values.

     

    Best regards,

    Raquel

    (0) 
    1. Prakhar Saxena

      HI Raqual

       

      in the sm30 …enter table AIC_CLOCKNAME…you will standard entries like below

       

      IRT_ESC    IRT Escalation    SRV_RFIRST    100

      IRT_WRN    IRT Warning    SRV_RFIRST    60

      MPT_ESC    MPT Escalation    SRV_RREADY    100

      MPT_WRN    MPT Warning    SRV_RREADY    60

       

      just update these entries as per your reqiurements

       

      Hope this resolves

      Regards

      Prakhar

      (0) 
  2. Vivek Hegde

    Thank You for the concise guide on SLA Management. I recently configured SLA Management for one of our clients and we were looking for IRT/MPT Warning notifications. This helped us to understand the mechanish involved and configured the same.

     

    I agree with Raquel Pereira da Cunha ; IRT/MPT Warning notifications should have been part of standard package.

     

    Best Regards,

    Vivek

    (0) 
  3. Lue Wang

    Hi Dolores,

    It’s a very good guide.

    I have a requirement for different service time on different priorities.

    For example, a “Very High” priority message need 7X24 working hours  and other priorities need only 5X8 working hours.

    Can it be realized?

     

    Best regards,

    Wang Lue

    (0) 
      1. Jorge Luis Marquez Hernandez

        Hi Dolores

         

        You mentioned that we can not configure escenario  with a “Very High” priority message that needs 7X24 working hours  and other priorities need only 5X8 working hours.

         

        Do you know any way to achive this?

         

        Thanks

         

        Best Regards.

         

        Jorge Luis Marquez

        (0) 
        1. Dolores Correa Post author

          Hi Jorge,

          If you need your own SLA determination check BAdI Implementation CRM_SLADET_BADI  (IMG: Customer Relationship Management -> Transactions -> Settings for Service Requests -> Business Add-Ins -> Business Add-In for SLA Determination).

          Best regards,

          Dolores

          (0) 
      2. Srikanth reddy Koppula

        Hi Dolores,

         

        Thanks for such a nice blog on SLA configuration. I have configured SLA for one of a client and struggling with a requirement in which client want to have it.

         

        We have two support group created in the system. 1st one is L1 PP / MM/ SD module and another one L2 PP/MM / SD etc.. for every module. Similarly multiple ticket statuses are already created. The SLA is applicable for New and In process status.

         

        – Issue – Every ticket is initially assigned to L1 support group with New ticket status. L1 is handled by Client Team and if they want our (Service Provider) help then the support group will change to L2 but SLA clock will not reset as it is being measured based on status and Service Profiles. I have created separate priorities for Service Provider as the SLA’s reset in priority change, but i see the IRT and MPT are the same.

         

        Request you to please suggest what configuration i have to do for reset the clock when Business Partner changed to L2 support in the Support team field.

         

        Reagrds,

        Sri Kanth

        (0) 
      3. Rashmi ranjan behera

        Hello Dolores

         

        I am newly configuring the solman.I can’t understand how the escalation will work.Is it needed to change the status of the incident to “IRT excedded” or “MPT excedded” before the escalation should work.I am confused in that part.I have already scheduled the background job but still can’t understand how the data will be picked by that job.I have found Item is also having action profile and all the actions are inactive.Please guide.

         

        Regards

        Rashmi ranjan behera

        (0) 
  4. G. Jacobs

    Hello Dolores,

     

    Thanks for your blog!  We have configured SLA Management within SAP Solution Manager

    ITSM. Everything is working fine except the calculation and population of the SLA dates is not performed automatically when the message is created from for example a managed system.

     

    Only when I change the priority or the service profile manually in the message within the CRM_UI  the date calculation is performed and the dates and durations are populated.

    We are on support pack 10.  Do you know why the date calculation is not performed when a message is created from a managed system and the priotity is already assigned?

     

    Thanks,

     

    Guido Jacobs

    (0) 
  5. Javier Eduardo Vega Torres

    Thanks for this great post. I have an issue, all my config is as you mentioned. The only thing is that the icon status and the percentage at the incidente are not changing, but the date calculations is working fine. In SM30-AIC_CLOCKNAME the entries are as suggested too. Any suggestions?. Thanks and best regards.

    SLA1.gif

    SLA2.gif

    (0) 
  6. Yessen Sypatayev

    Hi Dolores,

     

    thanks for your blog about SLA Escalation!

     

    I have 1 additionally question about email notification..

    Is it possible to send SLA Escalation email notification to Message processor and also to some special SLA Manager?

     

    regards,

    Yessen Sypatayev

    (0) 
    1. Haseeb Mirza

      Though the question is directed to Dolores, but I would like to reply to it with a yes, it is possible to do that.

       

      Just that you have to have an action profile for the specific partner function + have the action condition based on the item escalation status.

       

      Best Regards.

      (0) 
      1. Yessen Sypatayev

        Thanks Jacob.

         

        Now as workaround I solved my problem by this way:

        • I have added 1 email of Head of team to Support Team and send SLA ESC types (IRT and MPT) notifications only to head.
        • Also I have created SLA WRN types (IRT and MPT) and send notifs about it to Message Processor only.

        best regards,

        Yessen

        (0) 
        1. Haseeb Mirza

          Hi Yessen,

           

          If you are still looking forward to notifying other parties, what you can do is link those partner functions to the support team (which is already determined in the transaction), that way you will be able to notify them based on the same conditions you maintained before.

           

          Action profiles will be partner function dependent and there you go!

          (0) 
  7. Suresh Narasimhan

    Thanks for your post. We have the following requirement:

     

    If the notification receipt of the incident message is before 2 pm, set MPT (ToDo By) as Notification Receipt + 2 hrs.

    Else the notification receipt of the incident message is after 2 pm, set MPT (ToDo By) as Notification Receipt + 1 day 2 hrs.Please advise how we can achieve.

     

    Please also clarify the following:

    In this Post,

    1) A date profile “ZMIN_HEADER” is assigned to the transaction type ZMIN and it has its own date rule logic for IRT and MPT.

    2) Status profile and responsible profile have been assigned and it has its own duration logic as per the priority.

    3) Date Profile SMIN_ITEM has been assigned for status “New-E0001” under “Define settings for Duration” and it has its duration logic.

    4) SLA Determination Procedure has been defined .

    5) Status profile and responsible profile have been assigned to the item category.

     

    In what sequence the IRT and MPT will be calculated and If the SLA Determination procedure is good enough then why we need to assign date profile under transaction type and in “Define settings for Duration” .

     

    Thanks

    (0) 
  8. D. Aarts

    Dear Dolores,

    Interesting blog. For my requirement i’m missing something. I want to put a SLA on a status from the status profile. This means the transaction type can have a status like ‘On hold’ for only 30 days. After 30 days the user has to be warned about the breach.

     

    Do you have any suggestions?

     

    Thank you!

    Stefan Melgert

     

    (0) 
  9. Andrés Vargas

    Hola Dolores,

    He seguido todos los pasos pero al momento de la primera reacción no se detiene el medidor de tiempo. Cada vez que el mensaje está en manos nuestras continúa sumando tiempo al indicador IRT.

     

    ¿qué puede estar pasando?

     

    Espero me puedas ayudar, saludos.

    (0) 

Leave a Reply