Πότε εντάσσουμε τη Zendesk στο διαδικτυακό μάρκετινγκ: απαιτήσεις πριν από την υλοποίηση
Η Zendesk μπορεί να ενταχθεί σε μια δραστηριότητα διαδικτυακού μάρκετινγκ όταν υπάρχει σαφής ανάγκη να οργανωθούν τα εισερχόμενα αιτήματα που δημιουργούν οι επισκέψεις, οι φόρμες και οι επικοινωνίες πελατών. Η σωστή αφετηρία δεν είναι η εγκατάσταση ενός εργαλείου, αλλά η καταγραφή της σημερινής ροής, των αρμοδιοτήτων, των δεδομένων που επιτρέπεται να ανταλλάσσονται και της μετρήσιμης βελτίωσης που αναζητούμε. Ένα έργο χωρίς αυτές τις αποφάσεις συνήθως καταλήγει με περιττές συνδέσεις ή με αβεβαιότητα για το ποιος απαντά σε κάθε ενδιαφερόμενο.
Ορίζουμε το πρόβλημα με ένα συγκεκριμένο περιστατικό
Πριν ζητήσουμε προσφορά υλοποίησης, περιγράφουμε τι συμβαίνει σήμερα όταν κάποιος συμπληρώνει μια φόρμα μετά από διαφήμιση. Το μήνυμα φτάνει σε ένα κοινό γραμματοκιβώτιο; Αναλαμβάνεται από υπάλληλο; Υπάρχει τρόπος να διαπιστωθεί αν απαντήθηκε και αν επανήλθε ο πελάτης; Κρατάμε τη διαδρομή από τη δημιουργία έως το κλείσιμο του αιτήματος. Αν δεν υπάρχει πραγματική δυσκολία σε αυτό το στάδιο, η προσθήκη Zendesk μπορεί να είναι πρόωρη. Αρχικός στόχος είναι μια διατυπωμένη ανάγκη που μπορούν να επιβεβαιώσουν οι άνθρωποι που χειρίζονται τις επικοινωνίες.
Διαχωρίζουμε την εξυπηρέτηση από την προώθηση
Η Zendesk παρουσιάζει δυνατότητες συγκέντρωσης υποστήριξης, συνομιλιών και ιστορικού αιτημάτων. Η δημιουργία διαφημίσεων, η αγορά επισκεψιμότητας ή η γενική παραγωγή περιεχομένου απαιτούν διαφορετικές διαδικασίες. Γι' αυτό καταγράφουμε δύο ροές: πώς αποκτάμε νέες επαφές και πώς τις εξυπηρετούμε όταν απευθυνθούν σε εμάς. Η σύνδεση έχει νόημα μόνο στο σημείο όπου μεταφέρεται συγκεκριμένο γεγονός ή απαιτείται συγκεκριμένη ενέργεια. Το να αποκαλούμε όλες τις επαφές «δυνητικούς πελάτες» δεν αρκεί για να αποφασίσουμε ποια πληροφορία θα μπει στο σύστημα υποστήριξης.
Αποτυπώνουμε κανάλια, όγκους και κατηγορίες αιτημάτων
Η λίστα απαιτήσεων ξεκινά από τα πραγματικά σημεία επαφής: ηλεκτρονικό ταχυδρομείο, φόρμα ιστοσελίδας, συνομιλία, τηλέφωνο ή εφαρμογή μηνυμάτων. Για κάθε κανάλι σημειώνουμε ενδεικτικά τι είδους ερωτήσεις εμφανίζονται, ποιοι τις αναλαμβάνουν και ποιο αποτέλεσμα θεωρείται ολοκλήρωση. Δεν εφευρίσκουμε αριθμούς όταν λείπουν μετρήσεις· καταγράφουμε ότι απαιτείται αρχική αποτύπωση. Ξεχωρίζουμε τα αιτήματα τεχνικής βοήθειας από τις ερωτήσεις για προϊόντα ή συνεργασίες. Αυτή η ταξινόμηση θα καθορίσει ομάδες, δικαιώματα, αυτοματισμούς και μορφές αναφοράς χωρίς να προκαθορίζει κάποια εμπορική συνδρομή.
Προσδιορίζουμε τι ακριβώς πρέπει να παραδοθεί
Το εύρος του έργου χρειάζεται γραπτά όρια. Περιλαμβάνει μόνο την εισαγωγή ενός καναλιού ή και μεταφορά παλαιών αιτημάτων; Χρειάζεται βάση γνώσεων, κανόνες ανάθεσης, φόρμες ή σύνδεση με άλλη εφαρμογή; Για κάθε στοιχείο ορίζουμε υπεύθυνο αποδοχής και παραδοτέο που μπορεί να δοκιμαστεί. Μια αόριστη αναφορά σε «πλήρη αυτοματοποίηση» δεν αποτελεί προδιαγραφή. Καλύτερα να συμφωνήσουμε ποιες κατηγορίες αιτημάτων θα δρομολογούνται αυτόματα και πότε θα χρειάζονται ανθρώπινη παρέμβαση, ώστε η υλοποίηση να έχει σαφή όρια και δυνατότητα ασφαλούς επέκτασης.
Λίστα προϋποθέσεων πριν από την έναρξη
Για να διαπιστώσουμε αν είμαστε έτοιμοι, ελέγχουμε τα εξής:
- Υπάρχει ιδιοκτήτης έργου και υπεύθυνοι για κάθε κανάλι επικοινωνίας.
- Έχουν καταγραφεί τα δικαιώματα και οι ομάδες που θα χειρίζονται αιτήματα.
- Έχει αποφασιστεί ποια δεδομένα μεταφέρονται και ποια παραμένουν στην αρχική εφαρμογή.
- Υπάρχουν παραδείγματα πραγματικών περιπτώσεων για δοκιμή και κριτήρια αποδοχής.
- Έχει οριστεί τι γίνεται όταν αποτύχει η σύνδεση, λείπει συγκατάθεση ή προκύψει διπλή εγγραφή.
- Είναι γνωστό ποιος θα συντηρεί τους κανόνες, τις απαντήσεις και τη βάση γνώσεων μετά την έναρξη.
Μόνο οι επιβεβαιωμένες απαντήσεις θεωρούνται κλεισμένες απαιτήσεις· τα υπόλοιπα σημειώνονται ως ανοικτά θέματα.
Δεδομένα, συστήματα και τεχνικές εξαρτήσεις
Σε κάθε ενσωμάτωση ορίζουμε «πηγή αλήθειας» για την ταυτότητα επαφής, την κατάσταση αιτήματος και τις σχετικές προτιμήσεις επικοινωνίας. Αν χρειάζεται API (Διεπαφή Προγραμματισμού Εφαρμογών, Application Programming Interface), επαληθεύουμε τη διαθεσιμότητα των συγκεκριμένων λειτουργιών στο σχετικό πρόγραμμα. Σχεδιάζουμε χειρισμό σφαλμάτων, επαναπροσπάθειες και καταγραφή συμβάντων που δεν αποκαλύπτει περιττά προσωπικά δεδομένα. Η τεχνική επιτυχία δεν είναι απλώς να μεταφερθεί ένα μήνυμα μία φορά, αλλά να ξέρουμε αν παραδόθηκε, αν αντιστοιχίστηκε σωστά και πώς διορθώνεται μια αποτυχία χωρίς απώλεια ιστορικού.
Προσωπικά δεδομένα και δικαιώματα πρόσβασης
Τα αιτήματα υποστήριξης μπορεί να περιλαμβάνουν περιγραφές προβλημάτων, στοιχεία επικοινωνίας ή πληροφορίες που δεν πρέπει να φτάνουν σε κάθε συνεργάτη μάρκετινγκ. Καθορίζουμε σκοπό επεξεργασίας, απαιτούμενες πληροφορίες, ελάχιστα δικαιώματα, περίοδο διατήρησης και ασφαλή διαδικασία διαγραφής. Ειδικά αν υπάρχει σύνδεση με υπηρεσίες αποστολής μηνυμάτων, δεν υποθέτουμε ότι η αρχική επικοινωνία επιτρέπει απεριόριστη εμπορική χρήση. Η απόφαση για οποιαδήποτε νέα χρήση δεδομένων πρέπει να προηγείται της τεχνικής υλοποίησης, όχι να προστίθεται μετά ως απλή ρύθμιση.
Αποσαφηνίζουμε ρόλους, εκπαίδευση και διακυβέρνηση
Ακόμη και μια σωστά ρυθμισμένη πλατφόρμα αποτυγχάνει λειτουργικά όταν κανείς δεν γνωρίζει ποιος αναλαμβάνει το αίτημα και ποιος ενημερώνει τον πελάτη. Συμφωνούμε αρμοδιότητες διαχειριστή, υπευθύνου ομάδας και χειριστή. Ορίζουμε ποιος εγκρίνει νέες κατηγορίες, ποιος συντηρεί πρότυπες απαντήσεις και πότε μια δυσκολία κλιμακώνεται. Η εκπαίδευση πρέπει να βασίζεται σε συνήθη περιστατικά, όχι σε πλήρη περιήγηση όλων των επιλογών. Έτσι εντοπίζονται νωρίς ασάφειες που σε παραγωγικό περιβάλλον θα μπορούσαν να οδηγήσουν σε καθυστερήσεις ή αντιφατικές απαντήσεις.
Δοκιμή αποδοχής χωρίς αναστάτωση της λειτουργίας
Πριν μεταφερθεί πραγματικός φόρτος, ετοιμάζουμε αντιπροσωπευτικά σενάρια: νέο αίτημα, επαναλαμβανόμενο μήνυμα, αλλαγή υπευθύνου, αποτυχία διασύνδεσης και κλείσιμο που χρειάζεται επανεξέταση. Για κάθε σενάριο σημειώνουμε το αναμενόμενο αποτέλεσμα και το πρόσωπο που θα εγκρίνει τη λειτουργία. Αποφεύγουμε να χρησιμοποιούμε πραγματικά ευαίσθητα δεδομένα όπου αρκούν δοκιμαστικά. Η αρχική πιλοτική εφαρμογή επιτρέπει να αλλάξουν οι κανόνες χωρίς να διαταραχθεί η εξυπηρέτηση. Αν λείπει κριτήριο αποδοχής, δεν μπορεί να χαρακτηριστεί ολοκληρωμένο ένα συγκεκριμένο παραδοτέο.
Κόστος, συντήρηση και απόφαση έναρξης
Εκτός από τις άδειες εξετάζουμε παραμετροποίηση, εκπαίδευση, συνδέσεις, επαναλαμβανόμενη υποστήριξη και πιθανή αύξηση χρηστών ή καναλιών. Δεν υποθέτουμε ότι κάθε λειτουργία περιλαμβάνεται στην ίδια συνδρομή. Συγκρίνουμε προσφορές με κοινό κατάλογο παραδοτέων, ώστε η φθηνότερη αρχική τιμή να μη συγκαλύπτει πρόσθετο έργο. Η έναρξη εγκρίνεται όταν οι κρίσιμες εξαρτήσεις έχουν υπεύθυνο, οι κίνδυνοι έχουν αντιμετώπιση και η ομάδα μπορεί να επιβεβαιώσει το επιθυμητό αποτέλεσμα. Για ευρύτερο υπόβαθρο βοηθούν οι ενότητες εργασίες διαδικτυακού μάρκετινγκ και σχεδιασμός της γενικής στρατηγικής.
Ελάχιστο αρχείο έναρξης που παραδίδεται στον υλοποιητή
Μαζί με το αίτημα εργασίας συγκεντρώνουμε έναν πίνακα καναλιών, τα είδη αιτημάτων, τις ομάδες που τα χειρίζονται, τα απαραίτητα πεδία και τα αναμενόμενα αποτελέσματα. Χρειάζεται και ένα διάγραμμα με το σημείο στο οποίο εισέρχεται η πληροφορία στη Zendesk και το σημείο όπου επιστρέφει απάντηση στο άλλο σύστημα. Η ομάδα δεν χρειάζεται να λύσει προκαταβολικά κάθε τεχνική λεπτομέρεια, αλλά πρέπει να μπορεί να εξηγήσει τι θεωρεί λάθος και τι επιτυχία. Όταν υπάρχουν άγνωστες παράμετροι, τις σημειώνουμε ξεχωριστά, ώστε να μην παρουσιαστούν αργότερα ως υποτιθέμενα συμφωνημένα χαρακτηριστικά.
Τι αποκλείουμε ρητά από το πρώτο στάδιο
Μια σωστή περιγραφή απαιτήσεων αναφέρει και όσα δεν θα υλοποιηθούν. Μπορεί να αποφασίσουμε ότι η πρώτη φάση δεν καλύπτει ιστορική μεταφορά όλων των συνομιλιών, μαζική προωθητική επικοινωνία ή σύνδεση με κάθε διαθέσιμη εφαρμογή. Η απόφαση αυτή δεν είναι έλλειψη φιλοδοξίας, αλλά τρόπος να ελεγχθεί η βασική ροή πριν προστεθούν εξαρτήσεις. Χωρίζουμε τα μελλοντικά αιτήματα από τα δεσμευτικά παραδοτέα και ορίζουμε πώς θα εγκρίνεται οποιαδήποτε επέκταση. Με αυτή τη διάκριση μπορούν να συμφωνηθούν ακριβέστερο κόστος, χρονοδιάγραμμα και έλεγχοι χωρίς αμφισημίες.
Τι χρειάζεται να επιβεβαιωθεί με τον πάροχο
Δεν θεωρούμε δεδομένες τις δυνατότητες ενός προγράμματος Zendesk επειδή αναφέρονται σε γενική παρουσίαση. Ζητάμε να επαληθευτούν οι λειτουργίες της συγκεκριμένης άδειας, οι περιορισμοί πρόσβασης, οι υποστηριζόμενοι τρόποι σύνδεσης και η δυνατότητα εξαγωγής των απαραίτητων δεδομένων. Αν η λύση απαιτεί επέκταση ή ξεχωριστή υπηρεσία, καταγράφεται ως εξάρτηση πριν την έγκριση. Εξίσου σημαντικό είναι να γνωρίζουμε ποιο πρόσωπο θα έχει τη διαχειριστική πρόσβαση και πώς θα συνεχιστεί η λειτουργία αν σταματήσει η εξωτερική τεχνική συνεργασία.