Από το demo φωνητικού AI στην παραγωγή: Τι χρειάζονται οι αγοραστές τις πρώτες 30 ημέρες

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

Γιατί ένα καλό demo δεν σας φέρνει στην παραγωγή;

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

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

Πώς εκτελείτε ένα proof of concept φωνητικού AI στις δικές σας οριακές περιπτώσεις;

Εκτελέστε ένα proof of concept (POC) φωνητικού AI στις κλήσεις που παρέλειψε το demo: το δικό σας προσωπικό υποδύεται τους πιο δύσκολους καλούντες σας, σε εγγραφές με τη μορφή των πραγματικών, με κριτήρια επιτυχίας που έχουν υπογράψει πρώτα και οι δύο πλευρές και με το κόστος των δοκιμών συμφωνημένο εκ των προτέρων. Ένα demo τρέχει το ιδανικό σενάριο. Ένα POC δείχνει αν ο πράκτορας αντέχει στους κανόνες που κάνουν τις κλήσεις σας δύσκολες.

Δοκιμάστε με το δικό σας προσωπικό σε πραγματικές εγγραφές

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

Ρυθμίστε τον χειρισμό δεδομένων πριν φτάσουν πραγματικές εγγραφές σε μια δοκιμή. Η τεκμηρίωση συμμόρφωσης της Retell απαιτεί υπογεγραμμένο BAA πριν περάσουν προστατευμένες πληροφορίες υγείας μέσω της Retell. Αν οι κανόνες σας δεν επιτρέπουν ακόμη πραγματικές εγγραφές, αντιγράψτε τη μορφή τους: σε μια δοκιμή προσομοίωσης της Retell, κάθε περίπτωση ορίζει τις δικές της τιμές δυναμικών μεταβλητών και τα δικά της mocked αποτελέσματα συναρτήσεων. Ελέγξτε τι επιτρέπουν οι κανόνες σας με τον νομικό σας σύμβουλο ή την ομάδα συμμόρφωσης.

Συμφωνήστε τα κριτήρια επιτυχίας πριν ξεκινήσει το πιλοτικό

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

Υπολογίστε το κόστος των δοκιμών και για τις δύο πλευρές

Η δική σας πλευρά ξοδεύει ώρες προσωπικού για την πραγματοποίηση και βαθμολόγηση κλήσεων, συν χρόνο του IT και της ομάδας συμμόρφωσης. Ο πάροχος ξοδεύει χρόνο υλοποίησης για να προσαρμόσει έναν πράκτορα στους κανόνες σας. Έπειτα υπάρχει η χρήση της πλατφόρμας: η τιμολόγηση δοκιμών της Retell αναφέρει ότι οι δοκιμές χρεώνονται με τιμές παραγωγής, χωρίς δωρεάν sandbox, με τη φωνή από $0.07 ανά λεπτό και το κείμενο ανά μήνυμα, οπότε εκτελέστε τις περισσότερες περιπτώσεις σε κείμενο. Καταγράψτε ποιος καλύπτει κάθε κόστος, πόσο διαρκεί το POC και αν προσμετράται σε σύμβαση. Μια σταθερή λίστα περιπτώσεων και ένα σταθερό χρονικό παράθυρο το κρατούν οικονομικό και για τις δύο πλευρές.

Πώς πρέπει να είναι οι πρώτες 30 ημέρες, εβδομάδα προς εβδομάδα;

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

Ορίστε το εύρος για έναν τύπο κλήσης (ημέρες 1 έως 7)

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

Το έγγραφο εύρους πρέπει να απαντά σε πέντε ερωτήματα:

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

Υλοποίηση και σύνδεση (ημέρες 8 έως 14)

Υλοποιήστε σε μια πρόχειρη έκδοση. Στη Retell, μια νέα έκδοση ξεκινά ως πρόχειρη που μπορείτε να επεξεργαστείτε και να δοκιμάσετε, και η δημοσίευση την καθιστά μόνο για ανάγνωση, ώστε να έχετε πάντα μια σταθερή διαμόρφωση στην οποία να επιστρέψετε. Συνδέστε μόνο το ένα σύστημα του εύρους σας. Αν αυτή η σύνδεση είναι νέα για την ομάδα σας, η ροή εργασίας από το CRM στο φωνητικό AI εξηγεί ποια δεδομένα μετακινούνται σε κάθε σημείο της κλήσης.

Ρυθμίστε τη μετρική επιτυχίας τώρα, όχι μετά το λανσάρισμα. Η λειτουργία Post Call Extraction της Retell εκτελείται μετά το τέλος κάθε κλήσης και περιλαμβάνει ένα ενσωματωμένο πεδίο call_successful καθώς και προσαρμοσμένα πεδία που ορίζετε ως boolean, κείμενο, αριθμό ή selector. Ένα πεδίο όπως το «appointment_booked» είναι αυτό που θα απεικονίσετε σε γράφημα και για το οποίο θα ρυθμίσετε ειδοποιήσεις την τέταρτη εβδομάδα.

Δοκιμές με προσομοιωμένες και πραγματικές κλήσεις (ημέρες 15 έως 21)

Δοκιμάστε πρώτα σε κείμενο, μετά σε φωνή και μετά στο τηλέφωνο. Οι δοκιμές προσομοίωσης της Retell εκτελούν μια δοκιμαστική περίπτωση χωρίς να πραγματοποιηθεί κλήση: ένα AI υποδύεται τον καλούντα βάσει μιας persona που γράφετε, και η εκτέλεση βαθμολογείται ως επιτυχής ή αποτυχημένη με βάση τα κριτήρια επιτυχίας σας, με γραπτή αιτιολόγηση. Οι αποθηκευμένες περιπτώσεις εκτελούνται μαζί ως batch, το οποίο αναφέρει ποσοστό επιτυχίας, οπότε η σουίτα γίνεται ο έλεγχος παλινδρόμησης (regression) μετά από κάθε αλλαγή. Ο Conductor, ο copilot της Retell μέσα στο dashboard, μπορεί να συντάξει δοκιμαστικές περιπτώσεις από το μηδέν ή από πραγματικές κλήσεις.

Τρία πράγματα που πρέπει να κάνετε σωστά αυτή την εβδομάδα:

• Κάντε mock ό,τι γράφει σε ζωντανό σύστημα. Η τεκμηρίωση της Retell προειδοποιεί ότι μια custom function χωρίς mock καλεί το πραγματικό της endpoint κατά τη διάρκεια μιας δοκιμής, οπότε μια δοκιμή μπορεί να δημιουργήσει πραγματική κράτηση ή εγγραφή.
• Χρησιμοποιήστε web calls για τη φωνή και τηλεφωνικές κλήσεις για την τηλεφωνία. Μια κλήση μέσω browser σάς επιτρέπει να ακούσετε τις διακοπές και την εναλλαγή σειράς ομιλίας, αλλά οι μεταβιβάσεις σε αριθμό τηλεφώνου αποτυγχάνουν εκεί. Χρησιμοποιήστε μια πραγματική τηλεφωνική κλήση για να ελέγξετε τις μεταβιβάσεις, την εισαγωγή από το πληκτρολόγιο και τον ήχο του παρόχου τηλεφωνίας.
• Προϋπολογίστε το. Οι δοκιμές χρεώνονται με τιμές παραγωγής στη Retell: οι δοκιμές κειμένου ανά μήνυμα, οι δοκιμές φωνής ανά λεπτό.

Κλείστε την εβδομάδα με το προσωπικό να καλεί όπως θα καλούσαν πραγματικοί καλούντες, συμπεριλαμβανομένων των δύσκολων.

Ήπιο λανσάρισμα και παρακολούθηση (ημέρες 22 έως 30)

Στείλτε ένα μικρό μέρος της πραγματικής κίνησης στον πράκτορα, παρακολουθήστε τον καθημερινά και έχετε έτοιμη μια επαναφορά με μία κίνηση. Για το πρώτο μέρος, ο υπεύθυνος τηλεφωνίας σας δρομολογεί ένα ποσοστό κλήσεων στον αριθμό του πράκτορα από το υπάρχον IVR ή την ουρά σας. Μετά από αυτό, η Retell σάς δίνει τρία εργαλεία:

• Το A/B testing μοιράζει την κίνηση ενός αριθμού τηλεφώνου ανάμεσα σε πράκτορες κατά ποσοστό, ώστε μια διόρθωση να λαμβάνει ένα μικρό μερίδιο ενώ το υπόλοιπο παραμένει στον πράκτορα που εμπιστεύεστε.
• Τα environment tags συνδέουν έναν αριθμό τηλεφώνου με μια έκδοση. Η μετακίνηση του tag prod σε νέα έκδοση μεταφέρει τις ζωντανές κλήσεις σε αυτήν· η επαναφορά του κάνει rollback.
• Οι κανόνες ειδοποιήσεων στέλνουν email ή webhook όταν το ποσοστό επιτυχίας κλήσεων, ο όγκος κλήσεων, η χρησιμοποιούμενη ταυτοχρονία, το αρνητικό συναίσθημα ή το κόστος ξεπεράσουν ένα όριο που ορίζετε.

Ελέγχετε κλήσεις κάθε μέρα. Το Call History φιλτράρει κατά αποτέλεσμα, αιτία αποσύνδεσης και έκδοση πράκτορα. Το Live Monitoring επιτρέπει σε έναν επόπτη να παρακολουθεί μια ζωντανή απομαγνητοφώνηση, να ακούει σιωπηλά ή να αναλαμβάνει μια κλήση. Το dashboard αναλυτικών στοιχείων μπορεί να απεικονίσει το προσαρμοσμένο πεδίο εξαγωγής σας δίπλα στον όγκο κλήσεων, ανά έκδοση πράκτορα, ώστε να βλέπετε αν μια διόρθωση άλλαξε τον αριθμό. Αν χρειάζεστε δομημένη βαθμολόγηση σε μεγάλο όγκο, το AI QA της Retell βαθμολογεί ένα δείγμα κλήσεων με βάση κριτήρια που ορίζετε.

Ποιος είναι υπεύθυνος για τι κατά την ανάπτυξη;

Ένας υπεύθυνος ανά γραμμή. Στις κοινές γραμμές είναι που κολλάνε οι αναπτύξεις.

Η γραμμή που μετράει περισσότερο είναι η δεύτερη. Αν κανείς στην ομάδα σας δεν μπορεί να αλλάξει τον πράκτορα χωρίς να ανοίξει ticket, ο πράκτορας βελτιώνεται με την ταχύτητα της ουράς κάποιου άλλου. Σε όλο και περισσότερες ομάδες, αυτή η γραμμή ανήκει σε έναν CX automation engineer: έναν εσωτερικό υπεύθυνο που λειτουργεί τον πράκτορα καθημερινά, αφού οι forward deployed engineers του παρόχου έχουν βοηθήσει στην υλοποίηση της πρώτης έκδοσης και έχουν εκπαιδεύσει την ομάδα.

Τι πρέπει να ρωτήσετε έναν πάροχο για την υποστήριξη και εκπαίδευση (enablement) πριν υπογράψετε;

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

Στη Retell, η σελίδα τιμολόγησης αναφέρει υποστήριξη μέσω κοινότητας και email στο πλάνο πληρωμής με τη χρήση. Το πλάνο Enterprise περιλαμβάνει υποστήριξη 24/7 με αποκλειστική πύλη, ονομαστικό account manager και Dedicated Implementation Support ως πρόσθετη υπηρεσία. Αν θέλετε πρακτική βοήθεια υλοποίησης από τρίτο, ο κατάλογος συνεργατών λύσεων της Retell περιλαμβάνει πιστοποιημένους συνεργάτες που μπορείτε να φιλτράρετε κατά τοποθεσία, γλώσσα, ενσωματώσεις, αν η πρώτη συμβουλευτική συνάντηση είναι δωρεάν και εύρος τιμών.

Ερωτήσεις που πρέπει να θέσετε σε κάθε πάροχο:

1. Ποια κανάλια και ώρες υποστήριξης περιλαμβάνει το πλάνο μας και τι θεωρείται επείγον;
2. Η βοήθεια υλοποίησης περιλαμβάνεται, είναι πρόσθετη υπηρεσία ή παρέχεται μέσω συνεργάτη; Πόσο κοστίζει και είναι σταθερή τιμή ή ορίζεται ανά έργο;
3. Θα ελέγξει κάποιος το εύρος, τον σχεδιασμό του πράκτορα και τη σουίτα δοκιμών πριν από το ήπιο λανσάρισμα;
4. Με ποιον επικοινωνούμε κατά την εβδομάδα του ήπιου λανσαρίσματος αν κάτι χαλάσει και πόσο γρήγορα ανταποκρίνεται;
5. Μπορεί η δική μας ομάδα να εκτελέσει ολόκληρο τον κύκλο αλλαγών (εντοπισμός αποτυχημένης κλήσης, διόρθωση, δοκιμή, δημοσίευση, επαναφορά) χωρίς tickets προς τον πάροχο;
6. Πώς γνωστοποιούνται τα περιστατικά της πλατφόρμας;

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

Πώς βαθμολογείτε ένα πιλοτικό AI πριν το μεταφέρετε στην παραγωγή;

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

Γράψτε τον πήχη στο έγγραφο εύρους πριν από το ήπιο λανσάρισμα, ώστε κανείς να μην προσπαθήσει να τον χαμηλώσει αφού δει τους αριθμούς. Βαθμολογήστε κάθε γραμμή με 0 (δεν επιτεύχθηκε), 1 (επιτεύχθηκε εν μέρει) ή 2 (επιτεύχθηκε). Οι γραμμές-πύλες πρέπει να πάρουν 2 ανεξάρτητα από το σύνολο. Εννέα γραμμές δίνουν μέγιστο 18, και το 16 είναι ένας λογικός προεπιλεγμένος πήχης.

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

Αυτό το scorecard προορίζεται για τη μετάβαση ενός ήπιου λανσαρίσματος στην παραγωγή σε μια πλατφόρμα που έχετε ήδη επιλέξει. Για να συγκρίνετε παρόχους σε ένα πιλοτικό, χρησιμοποιήστε τη λίστα go/no-go στον οδηγό αξιολόγησης πλατφόρμας.

Τι πρέπει να επεκτείνετε πρώτα;

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

Ξεκινήστε με το σωστό επίπεδο βοήθειας

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

Συχνές ερωτήσεις

Τι σημαίνει μετάβαση από πιλοτικό AI σε παραγωγή;

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

Τι πρέπει να περιλαμβάνει ένα proof of concept φωνητικού AI;

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

Μπορείτε να δοκιμάσετε έναν φωνητικό πράκτορα χωρίς να στείλετε πραγματικά δεδομένα πελατών στον πάροχο;

Ναι. Αντιγράψτε αντί γι' αυτό τη μορφή των πραγματικών εγγραφών σε δοκιμαστικές περιπτώσεις. Στις δοκιμές προσομοίωσης της Retell, κάθε περίπτωση ορίζει τις δικές της τιμές δυναμικών μεταβλητών και τα δικά της mocked αποτελέσματα συναρτήσεων. Κάντε mock κάθε συνάρτηση που φτάνει σε ζωντανό σύστημα και δώστε σε κάθε mock ένα αποτέλεσμα, γιατί ένα κενό mock εκτελεί την πραγματική συνάρτηση και τα εργαλεία MCP αγνοούν τα mocks. Αν πρέπει να διακινηθούν πραγματικά δεδομένα, υπογράψτε πρώτα τις συμφωνίες: η Retell απαιτεί υπογεγραμμένο BAA πριν περάσουν μέσω αυτής προστατευμένες πληροφορίες υγείας. Ελέγξτε τους δικούς σας κανόνες με τον νομικό σας σύμβουλο ή την ομάδα συμμόρφωσης.

Πόσο διαρκεί ένα πιλοτικό φωνητικού AI πριν από την παραγωγή;

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

Πώς ξέρετε ότι ένας φωνητικός πράκτορας είναι έτοιμος για παραγωγή;

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

Τι πρέπει να κάνετε αν το πιλοτικό δεν αποδίδει;

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