Databeheer

Contactcentra gaan om met grote hoeveelheden gegevens, van rapportagegegevens tot oproeplijsten. U moet de gegevens mogelijk overdragen naar en van CXone en u moet mogelijk werken met gegevens binnen CXone. Hoe u werkt met gegevens in Studio-scripts of API's hebben invloed op de prestaties van uw systeem en de kwaliteit van uw interacties. Deze pagina helpt u bij een efficiënt beheer van gegevens.

Het juiste gereedschap voor de juiste taak

Het primaire doel van Studio is het beheren van de contactroutering. Alles wat u doet in een Studio-script moet gericht zijn op contacten. Elke gegevensverwerking die u nodig hebt die niet verwant is met contacten, moet buiten Studio gebeuren. Studio is niet ontworpen voor het verwerken van grote hoeveelheden gegevens, zodat deze een gegevenslimiet heeft van 32KB. Dit volstaat wanneer wordt gewerkt met contacten en de servers efficiënt blijven werken.

Het volgende is een taak die gegevensbeheer vereist, met twee voorbeelden voor het realiseren van de taak.

Voorbeeld taak: analyseer dagelijks agentgegevens om potentiële problemen te identificeren, zoals overmatig lange pauzen of niet geplande pauzes.

Ongeschikte oplossing: maak een gepland Studio-script dat dagelijks wordt uitgevoerd. Het script plaatst eerst API-oproepen om de agentlijst voor de dag op te halen en vervolgens de agentstatusgeschiedenis voor de dag op te halen. Het script controleert vervolgens of een agent een ongeplande pauze van meer dan 30 minuten heeft genomen. Het zoekt ook naar overmatige lange pauzes, zoals een plaspauze van vier uur. Het script bepaalt ook welke agents de meeste tijd in een niet-beschikbare tijd hebben doorgebracht en welke agents de meeste tijd hebben besteed aan een specifieke skill Skills worden gebruikt om de aanlevering van interacties te automatiseren op basis van de vaardigheden, capaciteiten en kennis van de agent.

Waarom deze methode slecht is:

Deze taak is niet gericht op één contact,; Studio is niet het juiste hulpmiddel voor de taak.
Studio is niet bedoeld voor het verwerken van grote hoeveelheden gegevens, maar is ontworpen voor contactafhandeling. Uw tenant Een organisatorische eenheid die wordt gebruikt om technische ondersteuning, facturering en globale instellingen voor uw CXone-omgeving te beheren kan problemen ondervinden met de prestaties omdat veel gegevens in het geheugen leiden tot slechte prestaties van de server.
Studio heeft een gegevenslimiet van 32KB. Deze methode vereist dat u gegevens in kleine hoeveelheden opsplitst om onder die limiet te blijven. Daarom kan het script langere tijd lopen, wat een intensief brongebruik inhoudt.
Deze taak wordt beter opgelost door de technische dienst die CXone API's kunnen gebruiken in plaats van een Studio-script.
Studio werkt het beste door het identificeren van een agent die de meeste tijd in een bepaalde status heeft doorgebracht of die het kleinste aantal oproepen heeft afgehandeld. Door het verwerken van de gegevens op een externe server, kunt u meer waardevolle metrics produceren.

Goede oplossing: dit is slechts één potentiële methode voor het oplossen van de taak. Oplossingen voor uw scenario's kunnen aan andere aanpak vereisen.

Een methode voor het oplossen van deze taak is met Python die wordt uitgevoerd op de AWS-server en die meer verwerkingsvermogen biedt. Plaats vanaf de server dezelfde API-oproepen om de agentlijst en agentstatusgeschiedenis voor de dag op te halen. Plaats de gegevens in een tabel of eventueel een matrix. Een databasetabel zou de voorkeur zijn zodat u de gegevens in de toekomst gemakkelijker kunt vergelijken en analyseren. De geretourneerde gegevens zullen mogelijk in megabytes zijn, wat geen probleem is voor de database, maar die de gegevenslimiet overschrijdt in Studio. U kunt de volledige statusgeschiedenis hebben voor elke agent binnen het geheugen. U zou de volledige dataset op één plaats kunnen hebben in plaats van kleine stukjes gegevens in een Studio-script.

U kunt nu beginnen werken met de gegevens om de gewenste metrics te produceren, zoals een geordende lijst van agents op basis van de tijd die is doorgebracht in bepaalde statussen. Een database helpt u om deze gegevens weer te geven zoals u dat wenst, in plaats van binnen de beperkingen van een Studio-script.

Leer over een goed voorbeeld van het maken en toewijzen van een oproeplijst in CXone:

De volgende instructies zijn een voorbeeld van de stappen en API-oproepen die u kunt plaatsen om een nieuwe oproeplijst te maken met gedefinieerde kleurtoewijzingen.

Authenticeren:
1. Voer de authenticatiedetectie uit om een tokenlink te verkrijgen. De resulterende token kan in cache worden opgeslagen.
2. Vraag een token aan bij het token-eindpunt dat is gedetecteerd in de vorige stap:
  1. Maak een POST-aanvraag voor https://cxone.niceincontact.com/auth/token met een x-www-form-url-gecodeerde inhoud.
  2. Haal de vijf sleutelwaardeparen op, zoals uw client_secret en client_id.

Voer API-eindpuntdetectie uit:

Pak de tenantId van de token uit die is geretourneerd in stap 1 hierboven.

Maak een GET-aanvraag voor https://cxone.niceincontact.com/.well-known/cxone-configuration?tenantId={YOUR TENANT ID}. Voorbeeld van antwoord:

{
	"private": false,
	"area": "na1",
	"cluster": "B32",
	"domain": "niceincontact.com",
	"acdDomain": "nice-incontact.com",
	"uhDomain": "nice-incontact.com",
	"ui_endpoint": "https://na1.nice-incontact.com",
	"auth_endpoint": "https://na1.nice-incontact.com",
	"api_endpoint": "https://api-na1.niceincontact.com",
	"tenantId": "11eb0358-724b-3970-97e5-0242ac110003"
}

Extract the "area" and "domain" fields from the reply.
Construct a base URI in the form of: https://api-{area}.{domain}.

Maak een toewijzing van een oproeplijst met POST /lijsten/oproeplijsten .

Deze API maakt een oproeplijst die is geïdentificeerd met een {listId}. Elke oproep werkt de gegevenstoewijzing bij van de bronkolomnamen naar CXone-velden. In het algemeen zou u dat alleen doen wanneer kolomkopteksten in de gegevens wijzigen. Voor deze API moet u waarden definiëren als queryparameters, dan een JSON-inhoud opgeven me een matrix van destinationMappings-paren, waarbij elk daarvan is samengesteld uit een fieldName en een fieldValue. Deze worden gebruikt voor het toewijzen van de gegevens die zijn geüpload in stap 4 hieronder.

U kunt de veldnamen vinden die hier zijn gedefinieerd door CXone in de online help. De veldwaarden zijn de kolomnamen in de brongegevens die moeten worden toegewezen aan het veld CXone.

Een voorbeeld-POST moet de volgende zijn: https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists?{listname}&externalIdColumn={fieldValue} met een JSON-inhoud De verwachte retour zou een 200-code zijn met een responsinhoud:
```
{
	"listId": 0
}
```
Upload de gegevens van de oproeplijst met POST /lists/call-lists/{listId}/upload met de listId die is gemaakt in stap 3. De listId is opgegeven in het pad van het API-oproep en de werkelijke oproeplijstgegevens worden geleverd in de verzoekinhoud.
Eén belangrijk detail is de opmaak van het bestand. De listFile-parameter zijn oproeplijstgegevens als een met base64 gecodeerd bestand.
U kunt ook kiezen om de dialer-skill te starten bij het voltooien van de upload door de "startSkill"-vlag in te stellen op "true" als onderdeel van de verzoekinhoud.
Een voorbeeld-POST zou de volgende zijn: https://api-{area}.{domain}/incontactapi/services/v27.0/lists/call-lists/{listId}/upload.

Tijdens actieve oproepen wilt het Jungle-contactcentrum klantgegevens ophalen van hun CRM en weergeven in hun agentapplicatie. In Studio leggen ze eerst standaard identificerende informatie van het contact vast, zoals een accountnummer. Daarna maakt het script een GET-verzoek aan hun CRM, waarbij wordt gecontroleerd of de informatie overeenkomt met een klantrecord. Als er een record bestaat, worden alle klantgegevens geretourneerd. De Jungle wil niet alle klantgegevens weergeven en de API staat hen niet toe om op te geven wat moet worden geretourneerd.

Hun oplossing is het bouwen van een middleware die bestaat tussen Studio en de CRM. De API retourneert de JSON naar de middleware, die de gewenste klantdetails eruit haalt. Daarna geeft het de details door in Studio. Hierdoor kan de Jungle ook binnen de 32KB gegevenslimiet blijven.

Pushen vs pollen

In het algemeen wilt u een op push gebaseerde architectuur gebruiken. Wachten tot er iets gebeurt door te pollen kost van nature bronnen, waarbij het pushen van gegevens op aanvraag is. Dit verbruikt geen bronnen wanneer het niet nodig is. Het pushen van gegevens staat u normaal toe om te gaan met kleinere stukjes gegevens. Het pushen van gegevens gebeurt vaak voor realtime behoeften, zoals één actief contact. Polling wordt vaak gebruikt voor integraties en kan niet zo vaak worden uitgesplitst of gesegmenteerd.

U wilde bijvoorbeeld de UI van de agent bijwerken wanneer u een telefoongesprek in wacht plaatste. Als u de /get-next-event API hebt gebruikt in een script om te luisteren (of te pollen) voor de gebeurtenis in wacht van de agentclient, zou dit constant een thread blokkeren. In plaats daarvan wilt u gegevens pushen in één instantie om constant gebruik van serverbronnen te vermijden. In soortgelijke instanties, misschien met CRM-integraties, plaatst u een API-oproep die gegevens pusht en de thread vrijmaakt in plaats van te wachten tot een aanvraag terugkeert. Gebruik daarna de signaal API om de gegevens terug te sturen naar het script. U kunt ook een API-oproep plaatsen om te zien of dat verzoek is geëindigd en, indien dat het geval is, de gegevens te verzenden.

Grote hoeveelheden gegevens verwerken

Als u grote datasets wilt beheren, zoals historische gegevens voor uw volledig contactcenter, gebruikt u CXone API's of CXone Data Share. Op grote schaal kunt u Snowflake gebruiken om alle gegevens op te halen voor uw bedrijfseenheid; CXone Data Share geeft u een directe pijplijn voor uw contactcentergegevens zodat u niet beperkt bent tot het plaatsen van API-oproepen om gegevens op te halen. Op kleinere schaal kan de hierboven toegelichte voorbeeldtaak optimaal zijn. Voor kleine bedrijven die geen gigantische hoeveelheid gegevens hebben of voor bedrijven die specifieke metrics willen vinden, kunnen kleine apps worden gebouwd voor soortgelijke taken. U kunt bijvoorbeeld een app bouwen die e-mails stuurt naar managers als ze medewerkers hebben die teveel tijd in een bepaalde status doorbrengen.

Voorbeelden van het vermijden van grote gegevenssets in scripts

Het volgende toont voorbeelden van vaak voorkomende scenario's die grote datasets gebruiken in uw Studio-scripts. U kunt ook het bovenstaande voorbeeld raadplegen dat vermijdt dat teveel klantgegevens worden overgedragen van een CRM in Studio.

API-reacties filteren op veld:

Sommige API's bieden de mogelijkheid om te filteren welke informatie wordt geretourneerd. Als u bijvoorbeeld een CRM vraagt om informatie te retourneren voor een casus, laten sommige CRM-API's u exact bepalen welke informatievelden u wilt retourneren. Als de API die u gebruikt, deze functionaliteit biedt, kunt u grote datasets vermijden door alleen te werken met de informatie die u nodig hebt. Als de API van een leverancier deze functionaliteit niet heeft, moet u mogelijk werken met de leverancier om de optie toe te voegen of kunt u een middleware bouwen. De middleware kan de gegevens ontvangen vóór Studio, kunt u uitfilteren wat onnodig is en dan de gegevens retourneren naar Studio.
API-reacties filteren op tijd

Als een API u toestaat om te filteren op een periode, gebruikt u deze functionaliteit om de hoeveelheid gegevens te minimaliseren. Als u slechts gegevens van een dag of week nodig hebt, moet u de respons filteren om alleen de gegevens binnen dat tijdbereik op te nemen.
Filter gegevens voor individuele contacten:

Studio is geen tool voor databeheer, maar wel voor contactbeheer. Dankzij de capaciteiten van de acties Studio en Studio kunt u werken met gegevens die in de eerste plaats gericht zijn op een individueel contact. U kunt uw gegevens specifiek voor individuele contacten bewaren met technieken, zoals het verzamelen van informatie via een IVR of door het ophalen van CRM-gegevens voor één record of casus tegelijk.

Dataopslag

U hebt veel opties voor het opslaan van gegevens. Als u een Snowflake-account hebt, kunt u uw contactcentergegevens verplaatsen van CXone naar Snowflake met Studio. NICE slaat uw gegevens op voor 24 maanden. U kunt deze ophalen van Snowflake. U kunt ook de Cloudopslagservices gebruiken om bestanden op te slaan, zoals oproepopname of chattranscripts, of u kunt ze verplaatsen naar uw eigen servers. Neem contact op met uw CXone ondersteuningsvertegenwoordiger voor meer informatie.

Onverwachte kosten

U zult doorgaans geen extra kosten oplopen door teveel API-oproepen te plaatsen of iets dergelijks. De manier waarop u bepaalde gegevens opslaat, kan echter kosten genereren. Het volgende zijn voorbeelden van gevallen waarbij een onjuiste gegevensopslag onverwachte facturatiekosten heeft gemaakt:

Maak talrijke scriptvariabelen en sla ze op in een tekstbestand voor elk contact zonder een proces op te nemen voor het reinigen van die bestanden.
Sla informatie van het IVR-selectiepad op in bestanden voor later gebruik. U wilt de informatie misschien gebruiken voor rapportagedoeleinden in de toekomst.
Sla API-resultaten op in een bestand dat voortdurend uitbreidt terwijl nieuwe resultaten worden toegevoegd. Na verloop van tijd en naarmate het bestand groter wordt, genereert dit opslagkosten.
Bestanden opslaan op CXone Cloudopslag. Als u Cloudopslag gebruikt, moet u rekening houden met eventuele parameters rond opslag. U kunt de helpinhoud raadplegen voor Cloudopslag of contact opnemen met een ondersteuningsvertegenwoordiger.

API-oproepen van Studio

API's helpen u om efficiënt en effectief te werken met gegevens. U kunt API-oproepen plaatsen vanaf Studio met de onderstaande acties. De volgende lijst legt de technische verschillen uit tussen de verschillende acties.

SNIPPET: hiermee kunt u aangepaste code toevoegen aan een script. U kunt deze actie gebruiken om API-oproepen te plaatsen, payloads voor te bereiden, dynamische gegevensobjecten te ontleden enz. Wanneer u API-oproepen plaatst met deze actie, moet u letten op de responssnelheid. Deze actie gebruikt een thread gedurende de volledige tijd dat deze actief is. Als de respons langzaam is, wat betekent dat de thread de hele tijd is geblokkeerd, kan dit een negatieve impact hebben op de serverprestaties. Een beller kan bijvoorbeeld dode lucht horen als alle threads tegelijk worden gebruikt.
REST API: hiermee kunt u REST API-oproepen plaatsen en gebruikt u minder serverbronnen. U moet deze actie gebruiken om API-oproepen te plaatsen wanneer dat mogelijk is, maar dit accepteert specifiek JSON. Als een API geen JSON retourneert, moet u in plaats daarvan mogelijk de SNIPPET-actie gebruiken. Afhankelijk van uw taak, moet u deze actie mogelijk gebruiken in combinatie met SNIPPET, omdat SNIPPET zaken kan doen zoals het voorbereiden van payloads.
ConnectAuth: authenticeert een connector die is gemaakt in Integration Hub. Integration Hub is een gecentraliseerde bron voor het bouwen, beheren en uitvoeren van integraties van CXone in platforms van derden. Deze actie blokkeert geen threads.
ConnectRequest: triggert een Integration Hub-verzoek nadat het werd geauthenticeerd. Deze actie blokkeert geen threads.

Andere met gegevens gerelateerde Studio-acties

Studio heeft verschillende acties die tijdelijk kleine hoeveelheden gegevens opslaan en ophalen van een databasetabel om de gegevens toegankelijk te maken voor andere scripts. Deze acties gedragen zich als een lijst van velden of waarden. Gebruik deze acties voor het opslaan van een groot aantal waarden of van waarden die op een later moment nodig zijn voor andere scripts. De complete lijst van acties omvat: PUTVALUE, GETVALUE, REMVALUE, GETLIST en CLEARLIST.

Deze acties maken gebruik van een uniek gegevenstype dat alleen toegankelijk is via deze Studio-acties. De gegevens zijn op geen enkele andere manier toegankelijk. Gebruikers kunnen deze database niet openen en gebruiken, ongeacht hun machtigingen.

De waarden worden weergegeven in een databasetabel voor een beperkte tijd, zoals geconfigureerd in de TTL hrs-eigenschap (time to live) van de PUTVALUE-actie. De standaardinstelling is 24 uur, maar dit kan gaan van 1 uur tot 168 uur (zeven dagen). U kunt de actie REMVALUE gebruiken om gegevens vóór het verstrijken van de TTL-tijd te verwijderen. Zo krijgt u volledige controle over de gegevens in uw scripts. De beste praktijk is het verwijderen van waarden wanneer ze niet meer worden gebruikt en om de TTL op de standaard 24 uur te laten.

Opmerkingen:

Als er meerdere variabelen moeten worden geraadpleegd door andere scripts of contacten, is een database over het algemeen de beste oplossing.
Niet-persistente publieke variabelen kunnen worden gedeeld met andere scripts of contacten gedurende de levensduur van het script dat deze variabelen instelt. De variabelen worden automatisch opgeschoond na de vrijgave.
Deze acties hebben een limiet van 1000 items in de "lijst". Eén item of een stuk gegeven heeft ook een limiet van 5 KB.