Köpribban för röst-AI har flyttats: från naturligt tal till snabb och säker iteration

Utvärderingskriterier för röst-AI är de tester en köpare använder för att avgöra om en plattform för röstagenter håller på de egna telefonlinjerna. Naturligt klingande tal var tidigare det avgörande testet. Nu är det instegsribban. När alla leverantörer på kortlistan låter bra i ett samtal blir den avgörande frågan hur snabbt ditt team kan ändra agenten, och hur säkert.

Ett mönster återkommer i köpsamtal. Den första utvärderingsrundan jämför röster, latens och avbrott. Den andra rundan frågar vad som händer dag 40, när en policy ändras, en utgående kampanj behöver ett nytt manus eller en nyare modell lanseras. En leverantör som inte kan besvara de frågorna med en livedemo av ändringsprocessen säljer lanseringen och lämnar driften åt dig.

Retell AI publicerar den här guiden och säljer en plattform för röstagenter. Frågorna fungerar för alla leverantörer, även oss, och vi anger var våra egna dokumenterade svar har begränsningar.

Varför räcker inte naturligt tal längre för att välja leverantör?

Eftersom röstkvaliteten avgör agentens första vecka och förändringsförmågan avgör resten. Du måste fortfarande kontrollera att agenten låter rätt i dina samtal: så utvärderar du en plattform för röstagenter före driftstart går igenom latens, avbrott, transkribering och överföringar i en pilot. Men en röstagent blir aldrig färdig. Uppringare formulerar sig på sätt som dina manus inte förutsåg, priser och policyer ändras, och nya samtalstyper tillkommer.

Varje sådan ändring är en produktionsrelease på en telefonlinje, där en dålig mening når en uppringare innan någon har läst transkriptet. Därför har ribban två delar, snabbhet och säkerhet, och därför bör du poängsätta båda.

Mjukvaruteam mäter redan leveranser på det här sättet. DORA, ett forskningsprogram som drivs av Google Cloud, delar upp mjukvaruleveransens prestanda i genomströmning och instabilitet: hur snabbt ändringar når produktion och hur ofta de kräver en återställning eller snabbfix. DORA rapporterar att ”snabbhet och stabilitet inte är avvägningar mot varandra” och att måtten korrelerar för de flesta team. En leverantör ska inte be dig välja mellan att ändra agenten snabbt och att ändra den säkert.

Vilka ändringar bör du poängsätta en leverantör på?

Poängsätt de ändringar du faktiskt kommer att göra, inte ett generellt betyg för ”användarvänlighet”. Varje typ av ändring innebär olika risk, så fråga om var och en separat.

Resten av guiden gör om tabellen till frågor. För den praktiska releaseprocessen när du har valt plattform, se så testar och släpper du ändringar i röstagenter.

Vad bör du fråga om iterationshastighet?

Fråga vem som kan göra en ändring och hur lång tid en verklig fix tar, och låt sedan leverantören visa det.

• Vem i vårt team kan ändra agenten, och behöver de en utvecklare? Svaret ska ange en roll på din sida, inte leverantörens tjänsteteam. I Retell skiljer åtkomstkontrollen roller som kan bygga, testa och redigera agenter från en skrivskyddad Member-roll.
• Hur lång tid tar det från ett misslyckat samtal till en fix i skarpa samtal? Godta inte en uppskattning. Välj ett misslyckat pilotsamtal, helst ett som visar ett känt felmönster för röstagenter, och låt din egen ansvarige åtgärda, kontrollera och släppa fixen medan du tittar på.
• Kan vi prova mer än en fix åt gången? Med agentversioner i Retell kan du skapa ett utkast från vilken tidigare version som helst och ha flera utkast samtidigt för att pröva olika angreppssätt.
• Kan ett misslyckat samtal bli ett testfall utan att skrivas för hand? I Retell kan Conductor göra om ett samtal från Call History eller AI QA till ett simuleringstestfall och skissa persona och framgångskriterier. Dokumentationen varnar för att du ändå bör granska varje fall och mocka alla funktioner som når en skarp endpoint.
• Kan regressionssviten köras från vår egen pipeline? API:t för batchtester i Retell startar en batch och returnerar vid pollning antalet godkända, underkända och fel, så att ett CI-jobb kan kontrollera resultaten innan du driftsätter.
• Innebär ett modellbyte en omskrivning? För single- och multi-prompt-agenter säger dokumentationen för Retell att du kan byta modell senare utan att skriva om prompten.
• Vad kostar iteration? I Retell debiteras tester till produktionspris, per meddelande för texttester och per minut för webb- och telefontester. Budgetera för det, eftersom en svit du inte har råd att köra om inte kommer att köras om.

Vad bör du fråga om iterationssäkerhet?

Fråga hur en ändring avgränsas före release, hur den exponeras efter release och hur snabbt den kan ångras.

• Är varje ändring en fast version du kan återgå till? I Retell blir en agentversion skrivskyddad när du publicerar utkastet, ”vilket ger dig en fast konfiguration du kan återgå till senare”. Konceptet förklaras i promptversionering.
• Kan vi se exakt vad som ändrats? Versionsjämförelse i Retell visar två versioner sida vid sida, med diffar på ordnivå för långa prompttexter och ändringar i länkade kunskapsbaser och funktioner.
• Kan en ändring nå några få uppringare innan den når alla? Googles SRE-arbetsbok definierar canarying som ”en partiell och tidsbegränsad driftsättning av en ändring i en tjänst samt utvärderingen av den”. I Retell delar A/B-testning upp ett nummers inkommande eller utgående trafik mellan agenter procentuellt. Varje agent har också från början miljötaggarna prod och staging, så du kan peka staging mot en ny version och ringa den på ett testnummer först.
• Hur rullar vi tillbaka, och följer alla nummer med? I Retell flyttar du prod-taggen tillbaka till föregående version, och nummer som är kopplade till taggen följer med. Nummer som tilldelats en version direkt stannar på den versionen, så fråga hur du kontrollerar vilka nummer som använder taggen.
• Vad visar att en ändring gjorde saken värre? Analysdashboarden i Retell bryter ner mått per agentversion, larmregler kan begränsas till miljötaggar och jämföras med föregående period, och AI QA poängsätter ett urval av samtal för problem som hallucinationer.

Ställ sedan frågan som de flesta utvärderingar hoppar över: vilka ändringar går förbi releaseflödet? Alla plattformar har några. En leverantör som namnger sina egna är lättare att driva säkert än en som påstår att det inte finns några. Här är de som gäller för Retell, enligt dokumentationen:

• Delade subflöden. Ett bibliotekssubflöde delas mellan agenter, och en redigering når alla agenter som använder det, även publicerade versioner. Dokumentationen säger att du ska konvertera det till ett lokalt subflöde före publicering om du vill förhindra det.
• Automatiskt uppdaterad kunskap. Med automatisk uppdatering påslagen hämtar en kunskapsbas om sina URL-källor och synkroniserar om ändrade anslutna filer var 24:e timme, så en ändring på en källsida kan nå svaren vid nästa uppdatering i stället för via en ny agentversion.
• Kampanjer inställda på senaste utkastet. Ett kampanjsteg kan använda en fast version, den senast publicerade versionen, en tagg eller den senast skapade versionen. Dialer-dokumentationen varnar för Latest Created, eftersom ett utkast du fortfarande redigerar når skarpa samtal vid nästa uppringning.

Behöver utgående kampanjer och modellbyten andra frågor?

Ja, eftersom båda ändrar skarpa samtal på sätt som en promptredigering inte gör.

Kampanjer. En pågående utgående kampanj är många framtida samtal köade mot en och samma agent. Fråga vilken version varje uppringning använder och vad du kan ändra när kampanjen väl är igång. Dialer i Retell bestämmer agentversionen vid varje uppringning, inte vid start, så en fast version håller agenten stabil under hela kampanjen medan Latest Published för in publicerade ändringar i den. Sekvensen och kontaktlistan låses vid start, och att ändra dem innebär att duplicera kampanjen. En paus stoppar nya uppringningar inom ungefär en minut medan samtal som redan pågår avslutas.

Modeller. Ett modellbyte kan ändra formuleringar, verktygsanrop och timing på en gång. Fråga om samma testsvit kan köras på den gamla och den nya modellen, och om du kan köra en snabb reservmodell. För röstagenter på modeller som hanteras av Retell erbjuder LLM-inställningarna en snabb fallback-modell som körs parallellt med den primära, och dokumentationen säger att du ska kontrollera att båda modellerna följer instruktionerna och anropar verktyg korrekt innan du driftsätter. Den säger också att du ska testa om instruktioner och verktygsanrop efter att ha ändrat temperaturen.

Hur poängsätter du leverantörer på snabb och säker iteration?

Kör samma fyra övningar på varje plattform på kortlistan under piloten, låt personen som ska äga agenten göra jobbet och ta tid på varje övning.

Poängsätt snabbhet och säkerhet separat, ett till fem för vardera, och låt inte ett högt betyg på det ena dölja ett lågt betyg på det andra. En plattform där fixar släpps på en timme men inte kan rullas tillbaka blir underkänd. Det blir även en där varje ändring är säker men kräver ett ärende hos leverantören. DORA:s eget råd för att förbättra båda samtidigt är att hålla varje ändring liten: ”Mindre ändringar är också lättare att återhämta sig från om något går fel.”

Två andra sidor täcker närliggande beslut. Om du ska bygga, köpa eller använda en hanterad tjänst avgör vem som över huvud taget kör de här övningarna; se bygga eller köpa AI-röstagenter. Det ekonomiska underlaget för satsningen finns i ROI för AI-röstagenter. Den här poängmallen förutsätter att båda är avgjorda och frågar bara om ditt team kan fortsätta förbättra agenten. Vilka samtal du ska automatisera först är ett eget beslut, som tas upp i så väljer du användningsfall för röst-AI.

Vanliga frågor

Vilka är de viktigaste kriterierna när du utvärderar en plattform för röst-AI?

Börja med om den slutför ditt arbetsflöde i dina egna samtal, passar dina telefoni- och datasystem och låter naturlig. När leverantörerna på kortlistan klarar det är iteration det kriterium som skiljer dem åt: hur snabbt ditt team kan ändra promptar, kunskap, flöden, kampanjer och modeller, och hur säkert de ändringarna når uppringare i skarp drift.

Hur testar du hur snabbt en leverantör låter dig ändra en röstagent?

Välj ett misslyckat samtal från piloten och be personen som ska äga agenten att åtgärda det, kontrollera det, släppa det till ett testnummer och rulla tillbaka det medan du tar tid. Upprepa med en kunskapsändring och ett modellbyte på ett utkast. En inspelad demo av leverantörens egen personal räknas inte.

Vad gör en ändring i en röstagent säker?

En säker ändring är en fast version med en synlig diff, klarar en sparad testsvit före release, når först en liten andel av samtalen och kan rullas tillbaka i ett steg. Du behöver också veta vilka ändringar som går förbi det flödet, som delade komponenter eller automatiskt uppdaterad kunskap.

Vem bör köra iterationsövningarna under en pilot?

Personen som ska äga agenten efter lanseringen, inte leverantörens team. Vissa team ger det jobbet till en CX-automationsingenjör, den interna ansvariga som hittar dåligt hanterade samtal, bygger fixar, kontrollerar dem och driftsätter dem.

Kan du byta språkmodellen bakom en röstagent utan att bygga om den?

Många plattformar låter dig göra det, men du bör inte byta i blindo. Kör samma testsvit på båda modellerna, jämför resultaten och släpp den nya modellen till en andel av samtalen först. För single- och multi-prompt-agenter i Retell säger dokumentationen att du kan byta modell senare utan att skriva om prompten, och att du ska kontrollera att en fallback-modell följer dina instruktioner och testa om verktygsanrop efter att ha ändrat temperaturen.

Lägg till iteration i din utvärderingsmall

Köpribban för röst-AI har flyttats från ”låter den mänsklig” till ”kan vi ändra den snabbt utan att samtal går sönder”. Retell är en plattform för AI-röstagenter för kontaktcenter, med utkastversioner, versionsjämförelse, miljötaggar, simulering och batchtester, A/B-uppdelning av trafik och AI QA, så att personen som äger agenten kan testa, släppa och rulla tillbaka en ändring utan att vänta på en leverantör. Prissättningen är betala per användning från 0,07 $ per minut på prissidan. Ta med din svåraste ändring till piloten och ta tid på den.