Benodigde licentie
| Abonnement | Elk abonnement |
| Toegang | Admin |
Het kan: de Ticket Import API bestaat hier precies voor, met een bulk-endpoint voor historische ladingen of alles boven de 1000 tickets. De reden om het niet te doen, is een gedocumenteerde beperking.
Wat geïmporteerde tickets niet kunnen
Metrics en SLA's worden er niet op ondersteund. Zendesk is er duidelijk over: metrics of SLA's over geïmporteerde tickets draaien levert onvolledige en onjuiste gegevens op. Precies de gebruikelijke reden om te importeren, de cijfers van vorig jaar in het nieuwe systeem hebben, is dus het ene wat de import niet kan leveren.
Nog twee gedragingen om te verwachten. Triggers lopen niet op een geïmporteerd ticket tenzij de status gesloten is; ze hervatten zodra het later wordt bijgewerkt. En er gaan geen meldingen naar wie op die tickets in cc staat, wat voorkomt dat een migratie duizenden klanten mailt over tickets van twee jaar terug.
Met de tijdstempels valt het mee: created_at, updated_at en solved_at kun je zetten, en die van opmerkingen ook, dus de historie klapt niet samen op de importdatum.
Wat mensen werkelijk nodig hebben
Vraag waarom de historie ertoe doet en het antwoord is vrijwel altijd een van twee dingen. Geen van beide vraagt een volledige import.
Af en toe iets opzoeken. Het oude systeem leesbaar houden of exporteren naar een doorzoekbaar archief dekt dat voor een fractie van de moeite.
Rapporteren over vorig jaar. Haal die cijfers één keer uit het oude systeem en bewaar ze als document. Nu metrics op geïmporteerde tickets niet worden ondersteund, is dat de enige manier om cijfers te krijgen die je kunt verdedigen.
Importeer je toch, behandel het dan als een project met eigen budget en bepaal vooraf welke velden mee moeten. Boven ruwweg 750.000 tickets houdt archive_immediately de belasting weg bij je live wachtrij.
Opmerkingen
0 opmerkingen
Artikel is gesloten voor opmerkingen.