Κατασκευή ιστοσελίδας για helpdesk υπηρεσία

Κατασκευή ιστοσελίδας για helpdesk υπηρεσία

Μια helpdesk υπηρεσία κρίνεται από το πόσο καθαρά μετατρέπει ένα πρόβλημα σε καταγεγραμμένο αίτημα, σωστή προτεραιότητα, υπεύθυνο επίλυσης και ενημέρωση προς τον χρήστη. Η ιστοσελίδα πρέπει να δείχνει αυτή τη λειτουργία πριν επιχειρήσει να πουλήσει πακέτα. Ο υποψήφιος πελάτης χρειάζεται να καταλάβει τι καλύπτει το helpdesk, πώς ανοίγει ένα αίτημα, πότε γίνεται κλιμάκωση και ποια όρια συμφωνούνται.

Το κατάλογος υπηρεσιών προηγείται της φόρμας

Η πρώτη ουσιαστική σελίδα πρέπει να είναι ένας κατάλογος υπηρεσιών με σαφή όρια. Άλλο αίτημα είναι ένα πρόβλημα πρόσβασης, άλλο η ρύθμιση νέου χρήστη και άλλο μια αλλαγή υποδομής. Όταν όλα εμφανίζονται ως «τεχνική υποστήριξη», ο πελάτης δεν μπορεί να γνωρίζει ποια εργασία ανήκει στο helpdesk και ποια χρειάζεται ξεχωριστό έργο.

Ο κατάλογος μπορεί να οργανώνεται σε συμβάντα, αιτήματα υπηρεσίας και αλλαγές. Η ιστοσελίδα δεν χρειάζεται να υιοθετεί βαριά ορολογία, αλλά πρέπει να βοηθά τον πελάτη να επιλέγει σωστή κατηγορία. Έτσι βελτιώνεται και η ποιότητα των αίτημαs που φτάνουν στην ομάδα.

Διαλογή αιτημάτων με απλή γλώσσα

Η διαλογή ενός αίτημα πρέπει να εξηγείται με παραδείγματα. Ένα θέμα που επηρεάζει έναν χρήστη δεν έχει την ίδια προτεραιότητα με ένα συμβάν που σταματά κρίσιμη λειτουργία για ολόκληρη ομάδα. Η ιστοσελίδα μπορεί να δείχνει πώς εξετάζονται έκταση, επίπτωση και δυνατότητα προσωρινής λύσης, χωρίς να ανακοινώνει αυθαίρετους χρόνους απόκρισης.

Ένας μικρός οδηγός πριν από την υποβολή μπορεί να ζητά τι δεν λειτουργεί, πόσοι επηρεάζονται, πότε άρχισε το πρόβλημα και αν εμφανίζεται μήνυμα σφάλματος. Αυτές οι πληροφορίες επιταχύνουν τη διάγνωση και είναι πολύ πιο χρήσιμες από ένα ελεύθερο πεδίο «έχω πρόβλημα».

• Τι ακριβώς δεν λειτουργεί
• Ποιοι και πόσοι χρήστες επηρεάζονται
• Πότε εμφανίστηκε το ζήτημα
• Υπάρχει προσωρινός τρόπος εργασίας ή πλήρης διακοπή

SLA χωρίς ασαφείς υποσχέσεις

SLA σημαίνει συμφωνία επιπέδου υπηρεσίας (Service Level Agreement). Η ιστοσελίδα μπορεί να εξηγεί τι είδους στοιχεία ορίζονται συνήθως σε μια τέτοια συμφωνία: ώρες κάλυψης, κατηγορίες προτεραιότητας, κανάλια υποβολής, στόχοι απόκρισης όπου συμφωνούνται και κανόνες κλιμάκωσης. Οι πραγματικοί όροι πρέπει να προκύπτουν από τη σύμβαση και όχι από γενικές προωθητική επικοινωνία φράσεις.

Ένας πίνακας παραδειγμάτων μπορεί να δείχνει τη λογική χωρίς να δεσμεύει σε αριθμούς που δεν έχουν δοθεί. Για κάθε κατηγορία περιγράφει είδος επίπτωσης, ποιος ενημερώνεται και ποια είναι η επόμενη ενέργεια. Αυτό βοηθά τον αγοραστή να ρωτήσει σωστά όταν συγκρίνει διαφορετικές υπηρεσίες.

Πύλη πελάτη με κατάσταση που έχει νόημα

Η περιοχή πελάτη πρέπει να δείχνει ενεργά και προηγούμενα αίτημαs, κατάσταση, υπεύθυνη ομάδα και τελευταία ενημέρωση. Οι ονομασίες καταστάσεων χρειάζονται ανθρώπινη μετάφραση. Το «αναμονή» πρέπει να εξηγεί αν περιμένει απάντηση από τον χρήστη, από τρίτο προμηθευτή ή από εσωτερική ομάδα.

Η διαφάνεια μειώνει επαναλαμβανόμενα τηλεφωνήματα για ενημέρωση. Παράλληλα, το πύλη πρέπει να προστατεύει τα δεδομένα και να εμφανίζει μόνο όσα αντιστοιχούν στον συγκεκριμένο λογαριασμό. Η δημόσια ιστοσελίδα μπορεί να δείχνει στιγμιότυπα οθόνης με δοκιμαστικά δεδομένα, όχι πραγματικές υποθέσεις πελατών.

Βάση γνώσης ως εναλλακτική πριν ανοίξει αίτημα

Μια καλή βάση γνώσης οργανώνεται γύρω από εργασίες και συμπτώματα. Ο χρήστης δεν πρέπει να ξέρει το εσωτερικό όνομα ενός συστήματος για να βρει βοήθεια. Τίτλοι όπως «δεν μπορώ να συνδεθώ» ή «πώς προσθέτω νέο λογαριασμό» είναι πιο χρήσιμοι από ασαφείς κατηγορίες προϊόντων.

Το περιεχόμενο χρειάζεται ημερομηνία αναθεώρησης, υπεύθυνο συντήρησης και σύνδεση με τη φόρμα αίτημα όταν η οδηγία δεν λύνει το πρόβλημα. Η ιστοσελίδα έτσι χτίζει αυτοεξυπηρέτηση χωρίς να αφήνει τον χρήστη σε αδιέξοδο. Τα άρθρα που δημιουργούν πολλά αίτημαs μπορούν να αναθεωρούνται με βάση πραγματικές απορίες.

Η κλιμάκωση πρέπει να είναι ορατή ως μηχανισμός

Όταν η πρώτη γραμμή δεν μπορεί να λύσει ένα περιστατικό, το αίτημα χρειάζεται να περάσει σε κατάλληλο ειδικό μαζί με το ιστορικό, τις ενέργειες που έγιναν και τα στοιχεία διάγνωσης. Η σελίδα υπηρεσίας μπορεί να εξηγεί αυτή τη ροή ώστε ο πελάτης να ξέρει ότι δεν θα επαναλαμβάνει από την αρχή το πρόβλημα σε κάθε επίπεδο.

Για πιο σύνθετες υποδομές, η κλιμάκωση μπορεί να περιλαμβάνει τρίτους προμηθευτές. Τότε πρέπει να αποσαφηνίζεται ποιος διατηρεί την επικοινωνία με τον τελικό χρήστη και ποιος παρακολουθεί την εξέλιξη. Η ευθύνη της ενημέρωσης είναι μέρος της εμπειρίας helpdesk, ακόμη κι όταν η τεχνική επίλυση γίνεται αλλού.

Νέα αιτήματα έναντι έργων αλλαγής

Ένα helpdesk μπορεί να δεχτεί αίτημα «θέλω νέο χρήστη», αλλά μια μεγάλη αλλαγή δικτύου ή μετάβαση συστήματος δεν πρέπει να κρύβεται μέσα σε αίτημα ρουτίνας. Η ιστοσελίδα πρέπει να δείχνει πότε ένα αίτημα μετατρέπεται σε έργο που χρειάζεται εκτίμηση, σχεδιασμό και ξεχωριστή έγκριση.

Αυτό προστατεύει και τις δύο πλευρές. Ο πελάτης καταλαβαίνει γιατί μια εργασία δεν ολοκληρώνεται σαν απλή υποστήριξη, ενώ ο πάροχος αποφεύγει ασαφή όρια υπηρεσίας. Ένα μικρό δέντρο απόφασης μπορεί να ρωτά αν υπάρχει αλλαγή σε πολλούς χρήστες, υποδομή, άδειες ή προγραμματισμένο παράθυρο εργασιών.

Έλεγχος κινδύνων και επαλήθευσης πριν υπογραφεί η υπηρεσία

Ο υποψήφιος πελάτης πρέπει να ελέγξει ποιες συσκευές, εφαρμογές και τοποθεσίες καλύπτονται, ποιες ώρες λειτουργεί το helpdesk, ποιοι χρήστες έχουν δικαίωμα υποβολής και πώς αντιμετωπίζονται θέματα τρίτων προμηθευτών. Αν αυτά δεν είναι σαφή, η καθημερινή συνεργασία θα γεμίσει εξαιρέσεις.

Η ιστοσελίδα μπορεί να προσφέρει λίστα ελέγχου σύγκρισης που ζητά γραπτές απαντήσεις. Δεν βαθμολογεί παρόχους και δεν υπόσχεται ότι ένα μοντέλο ταιριάζει σε όλους. Απλώς μετατρέπει τα συνηθισμένα σημεία τριβής σε ερωτήσεις πριν από την ανάθεση.

• Τι περιλαμβάνεται και τι εξαιρείται από την υποστήριξη
• Ποιες ώρες και ποια κανάλια είναι διαθέσιμα
• Πώς ορίζονται προτεραιότητες και κλιμάκωση
• Πώς χειρίζονται περιστατικά που εξαρτώνται από τρίτους

Περιεχόμενο που απαντά πριν από το αίτημα

Για βελτιστοποίηση για μηχανές αναζήτησης, οι πιο χρήσιμες σελίδες προκύπτουν από πραγματικά θέματα υποστήριξης και όχι από δεκάδες παραλλαγές του ίδιου λέξη-κλειδί. Οδηγοί για προετοιμασία αίτημα, βασική ασφάλεια λογαριασμού, διαδικασία ένταξη χρηστών ή κατανόηση των επιπέδων υπηρεσίας μπορούν να απαντούν σε συγκεκριμένες προθέσεις.

Κάθε άρθρο πρέπει να οδηγεί φυσικά είτε σε σχετική οδηγία είτε στο κατάλληλο κανάλι υποβολής. Αυτό δημιουργεί μια πληροφοριακή αρχιτεκτονική όπου η αναζήτηση και η υποστήριξη δουλεύουν μαζί. Ο χρήστης βρίσκει απάντηση και η ομάδα λαμβάνει λιγότερα ατελή αιτήματα.

Η κύρια προτροπή είναι ο έλεγχος κάλυψης της υπηρεσίας

Η κατασκευή ιστοσελίδας για helpdesk υπηρεσία πρέπει να καταλήγει σε μια σαφή ερώτηση: «τι θέλετε να υποστηρίξουμε;». Μια φόρμα αξιολόγησης μπορεί να συλλέγει αριθμό χρηστών σε εύρος, βασικές κατηγορίες συστημάτων, τοποθεσίες, ώρες κάλυψης και επιθυμητά κανάλια, χωρίς να ζητά κωδικούς ή ευαίσθητα τεχνικά στοιχεία.

Με αυτά τα δεδομένα, η επόμενη συζήτηση μπορεί να ορίσει κατάλογος υπηρεσιών, SLA, ρόλους και κλιμάκωση. Το ιστοσελίδα μετατρέπεται έτσι σε εργαλείο οριοθέτησης της υπηρεσίας, κάτι πολύ πιο σημαντικό για μια μακροχρόνια συνεργασία από μια γενική φόρμα επικοινωνίας.

Σχετικό περιεχόμενο

Ιστοσελίδα για helpdesk πληροφορικής Παράδειγμα ιστοσελίδας υπηρεσίας

Επόμενο βήμα

Ορίστε πρώτα κατάλογος υπηρεσιών, κατηγορίες προτεραιότητας, ώρες κάλυψης και κανόνες κλιμάκωσης. Η ιστοσελίδα πρέπει να κάνει αυτά τα όρια ορατά πριν οδηγήσει σε αίτημα συνεργασίας.

Χρήσιμη είναι επίσης η σαφής αναφορά στο ποιος μπορεί να ανοίγει αιτήματα και ποιος εγκρίνει αλλαγές, ώστε η καθημερινή εξυπηρέτηση να μην μπλοκάρει από ασαφείς ρόλους.