Corthex · WooCommerce / Klantidentiteit
Van wie mag de chatbot een bestelling zien?
Een antwoord over bestelstatus begint bij de identiteit van de klant en daarna de winkelkoppeling. Een bestelnummer kennen betekent niet dat je de bestelling mag lezen.
Rechtendiagram · Fictief voorbeeld
Met de koppeling en tools ingeschakeld kan de geverifieerde klantcontext de eigen order opvragen. De echte winkelrespons bepaalt wat je kunt beantwoorden.
Een klantaccount is een grens, niet alleen een begroeting.
Een klant die vraagt waar zijn bestelling is, geeft je twee verschillende taken. Stel eerst vast welke klant de webshop werkelijk heeft geverifieerd. Vraag daarna de informatie op die bij die klant hoort. Het chatbericht zelf bewijst geen eigendom: iemand kan een bekend e-mailadres typen of een nummer van een bon overnemen. Gebruik zulke gegevens pas als zoekcontext nadat de winkel de vereiste geverifieerde identiteit heeft geleverd.
De eigen-bestellingtools van de native WooCommerce-koppeling gebruiken de geverifieerde ingelogde winkelklant. Die identiteit verschilt van een Corthex-beheerdersaccount, een optioneel contactformulier en de gespreksgeschiedenis van een bezoeker. De widget op een pagina plaatsen maakt daarvan geen klantsessie. Test het klantaccount in de webshop waar de widget draait en vertrouw hiervoor niet op een dashboardpreview van een beheerder.
Vier voorwaarden moeten in dezelfde winkel samenkomen.
Installeer en activeer Corthex AI met WooCommerce ingeschakeld. Kies Verbinden met Corthex in WordPress, selecteer de juiste assistent en bevestig de koppeling. Schakel de benodigde winkeltools voor die assistent in. Open vervolgens de winkel als ingelogde klant van wie het account de testbestelling bezit. Een werkend algemeen chatantwoord bewijst dat de assistent kan antwoorden, maar zegt op zichzelf niets over deze keten van vier voorwaarden.
De plugin koppelt met een beperkt connectortoken; voor deze route hoef je geen WooCommerce REST API-sleutel handmatig aan te maken. Het volledige klantprofiel delen is een aparte keuze die standaard uitstaat. Schakel dit niet in om een gastopvraag werkend te krijgen: het vervangt geverifieerde klantidentiteit niet. Gebruik je alleen de algemene JavaScript-embed, beoordeel dan eerst of de native winkelkoppeling of een bewust ontworpen eigen integratie nodig is.
Houd de relatie tussen assistent en winkel expliciet als je meerdere winkels of omgevingen test. Een testwinkel die aan de ene assistent is gekoppeld en een productiegesprek onder een andere assistent vormen geen bruikbare toegangscontrole. Noteer omgeving, assistentnaam, pluginversie en klantrol in je testverslag. Gebruik fictieve bestellingen en eigen testaccounts; klantgesprekken en echte bezorgadressen zijn hiervoor geen noodzakelijke bewijzen.
Een bestelstatus is geen bezorgbelofte.
Scheid drie vragen: heeft de winkel de order ontvangen, welke status heeft die registratie nu en wanneer komt het pakket aan? WooCommerce-bestelstatussen beschrijven het bestelproces. In behandeling en Afgerond hebben een betekenis binnen dat proces; ze leveren niet vanzelf een actuele vervoerdersscan of bezorgafspraak. Aanvullende verzendextensies kunnen informatie toevoegen, maar controleer de beschikbaarheid in je eigen gekoppelde inrichting.
Een bruikbaar antwoord noemt wat de winkel werkelijk teruggeeft en legt uit wat onbekend blijft. Bijvoorbeeld: de fictieve testbestelling staat In behandeling; de beschikbare uitkomst bevat geen bezorgdatum, dus de assistent kan morgen niet bevestigen. Een bron over levervoorwaarden kan gebruikelijke doorlooptijden uitleggen, maar is geen actuele verzendstatus van deze privébestelling. Bied bij ontbrekende gegevens de supportroute aan zonder te doen alsof de opvraag is geslaagd.
Herhaalbare rechtencontrole
Test de afwijzing net zo zorgvuldig als het antwoord.
Eigen account, eigen order
Log in met testklant A. Vraag naar de actuele status van diens testorder. Vergelijk het antwoord met de winkelregistratie en tooluitkomst, niet met een aangenomen bezorgdatum.
Geslaagd: alleen de ordercontext van de toegestane klant wordt gebruikt. Ontbrekende velden worden benoemd. Bewaar een geanonimiseerde opname en de verwachte status.
Gast die het nummer kent
Log uit of gebruik een privévenster. Vul hetzelfde e-mailadres en bestelnummer in de chat in. Die gegevens mogen de vereiste aanmelding niet vervangen.
Geslaagd: er verschijnen geen privébestelgegevens. De bezoeker krijgt een bruikbare aanmeld- of supportroute, zonder bevestiging dat de bestelling van iemand anders bestaat.
Andere ingelogde klant
Log in als testklant B en vraag om de order van A. Daarmee onderscheid je eigendom van de veel zwakkere voorwaarde dat er iemand is ingelogd.
Geslaagd: de opvraag overschrijdt de klantgrens niet. Herhaal na uitloggen, accountwisselen en wijzigingen aan koppeling of sessieafhandeling.
Bepaal wat er gebeurt als toegang ontbreekt.
Een afwijzing moet de klant nog steeds verder helpen. Leg uit welk winkelaccount nodig is, verwijs waar passend naar het normale accountgedeelte of vertel hoe support het verzoek via de bestaande procedure kan controleren. Vraag nooit om wachtwoorden en plak geen geheime API-sleutel in de chat. Maak bij de uitleg niet bekend of een niet-gerelateerde bestelling bestaat.
Als menselijke overdracht vanaf Pro is ingesteld, test die dan afzonderlijk met medewerkers online en offline. Een verzoek dat op een medewerker wacht, verschilt van een direct live antwoord. Noteer de beloofde vervolgstap en controleer of het team die kan waarmaken. Gebruik bij fouten eerder in de keten de diagnosegids in plaats van klantrechten steeds ruimer te maken.