Benodigde licentie
| Abonnement | Suite Professional of hoger, Explore Professional of hoger |
| Toegang | Admin |
In kalenderuren wel, uit de dataset met ticketbijwerkingen. In kantooruren niet voor een aangepast veld. Controleer dat voor je gaat bouwen.
Waar zit het antwoord?
De dataset Support - Updates history legt elke wijziging met een tijdstempel vast, dus tijd in een waarde is het gat tussen de wijziging die hem zette en die hem verving. De ticketdataset bevat alleen de huidige waarde, dus daar is de vraag helemaal niet te stellen.
Bij kantooruren houdt het op
Zendesk is er stellig over: er is geen kant-en-klare metriek voor de duur van een ticketveld in kantooruren, en duurberekeningen voor ticketvelden in aangepaste metrieken zijn beperkt tot kalenderuren. Dit is dus geen kwestie van meer werk. Het kan niet.
De duurmetrieken in kantooruren die er wél zijn, liggen vast: First resolution time, Full resolution time en Requester wait time. Die dekken vaste ticketgebeurtenissen, niet je eigen veld.
Waarom dat telt
Een ticket dat van vrijdagmiddag tot maandagochtend op één waarde staat is 65 kalenderuren en misschien 1 kantooruur. Alleen het tweede is eerlijk tegenover je team, en juist dat kun je niet berekenen.
Wat gebruik je dan wel?
Een SLA-beleid op de toestand waar het je om gaat. Dat meet van nature in kantooruren, waarschuwt terwijl het nog telt in plaats van achteraf in een rapport, en vraagt geen formule.
Is de vraag "laten we tickets te lang in deze toestand staan", dan is dat geen omweg maar het juiste middel: de rapportageroute ging die vraag in kantooruren toch nooit beantwoorden.
Zet het rooster goed vóór je het nodig hebt
Maten in kantooruren zijn niet beter dan het rooster erachter, en er is geen weg terug: de metrieken leggen het rooster vast zoals het op dat moment stond en herberekenen eerdere gebeurtenissen niet.
Opmerkingen
0 opmerkingen
Artikel is gesloten voor opmerkingen.