Κατασκευή ιστοσελίδας για helpdesk πληροφορικής
Η κατασκευή ιστοσελίδας για helpdesk πληροφορικής πρέπει να αντιμετωπίζει το helpdesk ως σημείο οργανωμένης τεχνικής υποστήριξης και όχι ως γενικό κουμπί «βοήθεια». Ο χρήστης χρειάζεται να περιγράψει σωστά το πρόβλημα, ενώ ο υπεύθυνος της επιχείρησης χρειάζεται να γνωρίζει ποια περιστατικά καλύπτονται, πώς γίνεται η αρχική ταξινόμηση αιτήματος και πότε χρειάζεται άλλη μορφή τεχνικής παρέμβασης. Η ιστοσελίδα οφείλει να ξεκαθαρίζει αυτά τα όρια πριν δημιουργηθεί πίεση.
Το καλό δελτίο υποστήριξης ξεκινά πριν από το πεδίο «περιγραφή»
Όταν μια φόρμα ζητά μόνο ελεύθερο κείμενο, ο χρήστης συχνά γράφει «δεν δουλεύει» και η τεχνική ομάδα αναγκάζεται να ξεκινήσει από το μηδέν. Η ιστοσελίδα μπορεί να ζητά κατηγορία συστήματος, συσκευή ή εφαρμογή, τι προσπαθούσε να κάνει ο χρήστης, ποιο μήνυμα είδε και αν το πρόβλημα επηρεάζει έναν ή περισσότερους ανθρώπους. Τα πεδία πρέπει να είναι απλά, με παραδείγματα που βοηθούν χωρίς να απαιτούν τεχνικές γνώσεις.
Η προτεραιότητα ορίζεται από την επίπτωση
Ένας χρήστης μπορεί να θεωρεί κάθε πρόβλημα επείγον. Η ιστοσελίδα χρειάζεται να εξηγεί με ουδέτερη γλώσσα πώς αξιολογείται η επίπτωση: αν σταμάτησε κρίσιμη λειτουργία, αν υπάρχει εναλλακτικός τρόπος εργασίας, αν επηρεάζεται ολόκληρη ομάδα ή μία θέση. Δεν χρειάζεται να δημοσιεύονται περίπλοκοι εσωτερικοί πίνακες. Αρκεί να δίνεται ένα κατανοητό πλαίσιο ώστε οι προσδοκίες να είναι ρεαλιστικές.
Για γενική παρουσίαση υπηρεσιών τεχνολογίας, μπορεί να υπάρχει σύνδεση με την κατασκευή ιστοσελίδας για εταιρεία πληροφορικής. Για τον ίδιο τον μηχανισμό υποστήριξης είναι θεματικά συναφής η κατασκευή ιστοσελίδας για υπηρεσία helpdesk.
Απομακρυσμένη βοήθεια με ξεκάθαρη συναίνεση και οδηγίες
Αν η υπηρεσία χρησιμοποιεί απομακρυσμένη σύνδεση, η ιστοσελίδα πρέπει να εξηγεί τι χρειάζεται να κάνει ο χρήστης πριν συνδεθεί ο τεχνικός, πότε πρέπει να είναι παρών και πώς θα γνωρίζει ότι μιλά με εξουσιοδοτημένο μέλος της ομάδας. Δεν χρειάζεται να περιγράφονται εσωτερικά εργαλεία ή ευαίσθητες διαδικασίες. Χρειάζεται όμως να αποφεύγεται η αίσθηση ότι «κάποιος μπαίνει στον υπολογιστή» χωρίς ορατή διαδικασία.
Πίνακας αρχικής ταξινόμησης αιτήματος
| Σύμπτωμα | Τι ζητά η φόρμα | Πιθανή διαδρομή |
|---|---|---|
| Δεν ανοίγει εφαρμογή | Όνομα εφαρμογής και μήνυμα | Αρχικός τεχνικός έλεγχος |
| Δεν υπάρχει πρόσβαση σε υπηρεσία | Ποιος επηρεάζεται και από πότε | Έλεγχος πρόσβασης ή συστήματος |
| Πρόβλημα συσκευής | Τύπος συσκευής και σύμπτωμα | Απομακρυσμένος ή επιτόπιος έλεγχος |
| Αίτημα αλλαγής | Τι πρέπει να αλλάξει και γιατί | Προγραμματισμένη εργασία |
Η βάση γνώσης πρέπει να είναι μικρή, σαφής και συντηρήσιμη
Ένα helpdesk δεν χρειάζεται εκατοντάδες άρθρα που κανείς δεν ενημερώνει. Χρειάζεται αρχικά τις λύσεις που πραγματικά επαναλαμβάνονται: σύνδεση, βασικές ρυθμίσεις, απλές ενέργειες ανάκτησης και σαφή σημεία όπου ο χρήστης πρέπει να σταματήσει και να ανοίξει αίτημα. Κάθε άρθρο πρέπει να έχει υπεύθυνο ανανέωσης και να γράφεται για ανθρώπους που δεν είναι τεχνικοί. Αν μια οδηγία έχει αλλάξει, η παλιά έκδοση δεν πρέπει να παραμένει προσβάσιμη χωρίς σήμανση.
Σελίδα υπηρεσίας για όσους αγοράζουν helpdesk
Ο υπεύθυνος μιας επιχείρησης χρειάζεται διαφορετικές πληροφορίες από τον τελικό χρήστη. Θέλει να καταλάβει ποια συστήματα μπορούν να υποστηριχθούν, τι χρειάζεται για να ξεκινήσει η συνεργασία, πώς γίνεται η καταγραφή αιτημάτων και πώς οργανώνεται η επικοινωνία με υπεύθυνους της επιχείρησης. Για συμβουλευτική γύρω από ευρύτερη τεχνολογική οργάνωση, μπορεί να είναι χρήσιμη η κατασκευή ιστοσελίδας για σύμβουλο πληροφορικής.
Ο κατάλογος υπηρεσιών πρέπει να συνδέεται με παραδείγματα αιτημάτων
Όροι όπως «υποστήριξη χρηστών» ή «τεχνική βοήθεια» γίνονται πιο χρήσιμοι όταν συνοδεύονται από παραδείγματα: πρόβλημα πρόσβασης, δυσλειτουργία εφαρμογής, νέα συσκευή, αλλαγή λογαριασμού ή ανάγκη για επιτόπιο έλεγχο. Τα παραδείγματα δεν αποτελούν υπόσχεση ότι κάθε αντίστοιχο περιστατικό λύνεται με τον ίδιο τρόπο. Δείχνουν όμως στον επισκέπτη τι ανήκει συνήθως στη συζήτηση και τι χρειάζεται να περιγράψει.
Για νέους πελάτες, μια ξεχωριστή σελίδα έναρξης συνεργασίας μπορεί να εξηγεί πώς καταγράφονται υπεύθυνοι, βασικά συστήματα, εξουσιοδοτημένοι χρήστες και κανάλια επικοινωνίας. Η ιστοσελίδα δεν πρέπει να συλλέγει ευαίσθητα τεχνικά στοιχεία δημόσια. Μπορεί όμως να κάνει σαφές ότι η σωστή υποστήριξη απαιτεί οργάνωση πριν εμφανιστεί το πρώτο περιστατικό.
Έλεγχος κινδύνων πριν δημοσιευτεί η πύλη υποστήριξης
- Να μην εμφανίζονται στοιχεία εσωτερικής υποδομής που δεν χρειάζεται να γνωρίζει ο χρήστης.
- Να μην υπόσχονται χρόνοι ανταπόκρισης που δεν αποτελούν πραγματικό μέρος της υπηρεσίας.
- Να υπάρχει σαφής τρόπος για περιστατικά που δεν μπορούν να περιμένουν τη συνηθισμένη ροή.
- Να εξηγείται ποια στοιχεία δεν πρέπει να γράφονται σε ένα απλό δελτίο υποστήριξης.
- Να ελέγχεται τακτικά ότι οι οδηγίες αυτοβοήθειας εξακολουθούν να ισχύουν.
Η λειτουργική σαφήνεια είναι ισχυρότερο επιχείρημα από τις γενικές υποσχέσεις
Ο επισκέπτης εμπιστεύεται περισσότερο μια υπηρεσία helpdesk όταν βλέπει πώς θα ζητήσει βοήθεια, τι πληροφορίες θα χρειαστεί, ποιος τύπος προβλήματος ανήκει στην υπηρεσία και τι συμβαίνει όταν το θέμα ξεπερνά την πρώτη γραμμή. Η ιστοσελίδα γίνεται έτσι μέρος της τεχνικής λειτουργίας: οργανώνει τις εισόδους, μειώνει το πηγαινέλα ερωτήσεων και βοηθά την ομάδα να ξεκινά κάθε περιστατικό με καλύτερο πλαίσιο.
Η ένταξη νέου πελάτη ξεκινά με απογραφή, όχι με κωδικούς
Ένα helpdesk πληροφορικής χρειάζεται βασική εικόνα του περιβάλλοντος που θα υποστηρίζει: κατηγορίες συσκευών, βασικές εφαρμογές, σημεία δικτύου, υπεύθυνους επικοινωνίας και κρίσιμες υπηρεσίες. Η ιστοσελίδα μπορεί να παρουσιάζει αυτή την απογραφή ως οργανωμένο πρώτο βήμα χωρίς να ζητά από δημόσια φόρμα συνθηματικά ή άλλα μυστικά πρόσβασης. Τα ευαίσθητα στοιχεία συλλέγονται αργότερα από συμφωνημένο ασφαλές κανάλι. Έτσι ο υποψήφιος πελάτης καταλαβαίνει ότι η υποστήριξη προετοιμάζεται με δομή και όχι με πρόχειρη ανταλλαγή πληροφοριών.
Άλλο προγραμματισμένη εργασία και άλλο περιστατικό
Η σελίδα αιτήματος βοηθά όταν ξεχωρίζει τη βλάβη που επηρεάζει την εργασία από μια προγραμματισμένη αλλαγή, όπως εγκατάσταση λογισμικού, δημιουργία νέου χρήστη ή μεταφορά εξοπλισμού. Οι δύο κατηγορίες χρειάζονται διαφορετικές πληροφορίες και διαφορετικό προγραμματισμό. Ένα απλό επιλογέα «πρόβλημα τώρα» ή «εργασία που μπορεί να προγραμματιστεί» αποτρέπει τεχνητή αίσθηση επείγοντος και επιτρέπει στο helpdesk να διαχειρίζεται καλύτερα τις προτεραιότητες. Ο πελάτης βλέπει επίσης πιο καθαρά ποια αιτήματα χρειάζονται συνεννόηση πριν εκτελεστούν.
Τα όρια υπηρεσίας και ασφάλειας πρέπει να είναι ορατά
Η αξιοπιστία ενισχύεται όταν η ιστοσελίδα δηλώνει ότι ο τεχνικός δεν θα ζητήσει ευαίσθητο συνθηματικό μέσα από κοινή φόρμα ή μη ασφαλές μήνυμα και ότι εργασίες υψηλού κινδύνου χρειάζονται επιβεβαίωση από εξουσιοδοτημένο πρόσωπο. Χρήσιμη είναι και μια σύντομη ενότητα για το τι δεν καλύπτεται από την τυπική υποστήριξη ή τι απαιτεί ξεχωριστή προσφορά. Τα σαφή όρια μειώνουν τις παρεξηγήσεις, προστατεύουν τον πελάτη από βιαστικές ενέργειες και βοηθούν την ομάδα να αντιμετωπίζει κάθε αίτημα με το κατάλληλο επίπεδο προσοχής.
Η κατάσταση ενός αιτήματος πρέπει να είναι κατανοητή χωρίς τεχνικό λεξιλόγιο
Αν υπάρχει περιοχή πελάτη, λίγες καθαρές καταστάσεις αρκούν: παραλήφθηκε, εξετάζεται, περιμένει πληροφορία από τον χρήστη, προγραμματίστηκε ενέργεια ή ολοκληρώθηκε. Οι εσωτερικοί κωδικοί ομάδας δεν χρειάζεται να εμφανίζονται αυτούσιοι. Δίπλα στην κατάσταση είναι χρήσιμο να φαίνεται ποια είναι η επόμενη αναμενόμενη ενέργεια και από ποιον. Έτσι ο πελάτης δεν τηλεφωνεί μόνο για να μάθει αν «κινείται» το αίτημα και το helpdesk αποφεύγει έναν δεύτερο κύκλο επικοινωνίας που δεν προσθέτει τεχνική πληροφορία.
Η ίδια λογική κάνει και την ενημέρωση προς τον υπεύθυνο της επιχείρησης απλούστερη, επειδή κάθε ανοιχτό θέμα έχει σαφές επόμενο βήμα και δεν χάνεται σε αόριστες τεχνικές σημειώσεις.