LAN Cal! Center. Demonstratie in Visual Basic. éd54s

éD54S

Faculteit Elektrotechniek Technische Universiteit Eindhoven Vakgroep Digitale Infonnatiesystemen (EB)

LAN Cal! Center Demonstratie in Visual Basic door: E.H.H. Slob

Rapport van het stagewerk uitgevoerd van 4 juli tot 4 oktober 1994 onder leiding van Dr. Ir. J. Simons en Prof. J. de Stigter

DE FACULTEIT DER ELEKTROTECHNIEK VAN DE TECHNISCHE UNIVERSITEIT EINDHOVEN AANVAARDT GEEN AANSPRAKELIJKHEID VOOR DE INHOUD VAN STAGE- EN AFSTUDEERVERSLAGEN

Voorwoord Tijdens mijn studie aan de faculteit Elektrotechniek van de Technische Universiteit van Eindhoven kreeg ik steeds meer het idee dat de nadruk te veel op theorie werd gelegd en er te weinig aandacht aan praktijkproblemen werd geschonken. Ik heb daarom besloten om mijn tweede stage buiten de TU uit te voeren om meer praktijkervaring te krijgen. Na een aantal omzwervingen ben ik vervolgens via prof. de Stigter op de afdeling NSC van PTf Research Leidschendam terechtgekomen. De opdracht "Call Center Demonstratie" die ik hier kon doen sprak mij erg aan omdat de probleemstelling naar mijn idee genoeg ruimte overliet voor creativiteit. Verder sloot de opdracht goed aan op mijn studierichting (digitale informatiesystemen) en interesse. Tijdens de eerste weken bij PTf Research kwam ik er al snel achter dat ik nog helemaal niets wist. Termen als accounts, e-mail, Internet en zelfs Windows waren vrijwel nieuw voor mij. Ik had op deze gebieden in ieder geval geen ervaring. Na de nodige hulp van NSC-medewerkers en medestudenten zat ik er gelukkig al vrij snel in. De werksfeer bij PTf Research beviel me uitstekend. Ik kreeg de kans om zelfstandig te werken. Terwijl vrijwel iedereen bereid was om te helpen als ik iets wilde weten of voor elkaar probeerde te krijgen. Het contact met NSC-medewerkers en medestudenten was goed. Ik heb tijdens mijn stage veel geleerd en heb ook nog een leuke tijd gehad. Wat mij betreft was de stage dan ook een succes.

2

INHOUD SAMENVATTIN'G

S

1. INLEIDIN'G

7

1.1 VERSCHllENDE UIlVOERINGSVORMEN •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••..•...•.•.••••••••••••••••• 7 1.2 DE PROBLEEMSlELLING •••••.•••••••••••••••••••••.•.••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 9 1.3 DE DEMONSTRA11EOPSTELLING ••••••.•.....•...•.••••••••••••••••....••.•.......••••••••••••••.••••••••••••••••••••••.•..•••••.••.•••••• 10 1.4 CALL CENTER SOFIWARE .•••••••••••.••••••.•••••••••••••••••••..•••••••••••••....•..••••••••••••••••••••••••••••••••••••••••••••••.••••••• 11 2. FUNCTIONELE SPECIFICATIE

12

12 2.1 OUTBOUND CALL CENTER 2.2 INBOUND CALL CENTER•••.••••••••••••••.••..•••••••••.•.•••••.•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••..••••••••••••••• 15 2.3 EISEN CALLCENTER DEMONSTRATIE.•..•..•...•.•.••.•.....••••••••••••••...••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 16 3. TECHNISCH ONTWERP

17

3.1 GLOBAAL MODEL 3.2 OUTBOUND CALL CENTER

17 19

3.2.1 Data Hand/er 3.2.2 CaU List 3.2.3 Agent 3.2.4 Te/ephony Server 3.25 Typische werking outbound CaU Center

19 21 22 24 25 27 27

3.3 INBOUND CALL CENTER 3.3.1 Data Hand/er

3.3.2 Inbound Server 3.3.3 Aanpassingen Agent 3.3.4 Uitbreidingen Te/ephony Server 3.3.5 Typische werking inbound CaU Center 3.3.6 Interactive Voice Response-Agents

28

29

30

31 33 3.4 VRAGENSTRUCTUUR •••••••••••••••••••••••••••••••••••.•••••••••••••••••••••••••••••••••••••..•..••.....••••••.•.....•••..•.••.•••••••••.•..• 34 3.5 OPSLAG VAN KLANTENINFORMA11E 36 39 3.6 COMMUNICA11E TUSSEN DE PARALLEL LOPENDE APPLICATIES

4. IMPLEMENTATIE

42

4.1 REMOTE PROCEDURE CALLS 42 4.2 TELEPHONY SERVER IN VBVOICE•••••••••••••••••••••••••••••••••••••••••.•.••.•••..•.•.•.•••.•••••••••••.••.••.••.•••••.•.•••••••••••• 45 4.2.1 Outbound CaU Center 45

4.2.2 Inbound CaU Center

46

4.3 CALL CENTER FILESTRUCTUUR •••••••••••.•••••••••••••..••••••.•••.••••••••••••.•••••••••••••••••••••••••••••••••••••••••••••••••••••••• 47

s. RESULTATEN

48

5.1 GEREALISEERDE SOFIWARE 48 5.2 BOTTLENECK 1: COMMUNICATIESNELHElD 48 5.3 BOTTLENECK 2: ANALOGE SIGNALERING .••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 48

6. CONCLUSIES

SO

7. OPMERKINGEN EN AANBEVELINGEN

51

LITERATUUROPGA VE

S2

3

LUST VAN GEBRUIKTE AFKORTINGEN

53

BULAGE A: GEBRUIKSAANWIJZING CALL CENTER SOFTWARE

54

BULAGE B: NETWORK DDE IN VISUAL BASIC

68

4

Samenvatting In het kader van het project "Call Centers" is in de periode van 4 juli t/m 4 oktober 1994 bij PTT Research, afdeling NSC, gewerkt aan de ontwikkeling van LAN Call Center demonstratie-software. Het doel hiervan is dat wordt aangetoond dat met moderne middelen geavanceerde Call Center functionaliteit kan worden gerealiseerd, terwijl de benodigde hardware eenvoudig kan blijven. Verder dient te worden gedemonstreerd dat door gebruik te maken van een hoog niveau programmeertaal zeer snel een op een bepaald bedrijf toegespitst Call Center kan worden gerealiseerd. De hoge rekensnelheid van de moderne pc's zorgt er hierbij voor dat de performance van het Call Center toch goed blijft. Een Call Center is een deel van een bedrijf waar medewerkers van dat bedrijf (agents genoemd) de vragen van bellers beantwoorden, bestellingen ontvangen, informatie geven, problemen oplossen of andere soortgelijke activiteiten uitvoeren. Een Call Center kan bestaan uit vier mensen die rond een tafel zitten of het kunnen honderden agents zijn, eventueel verspreid over verschillende locaties. Functioneel gezien zijn Call Centers onder te verdelen in twee categorieên: gericht op uitgaand verkeer (outbound) en gericht op binnenkomend verkeer (inbound). In het eerste geval is het de bedoeling dat de groep agents zo efficiënt mogelijk een bepaalde groep klanten kan bellen. Een Outbound Call Center kan behulpzaam zijn bij het beheer van relaties, het inzamelen van geld voor goede doelen, marktonderzoeken ofbij telefonische verkoop (telemarketing). Bij een inbound Call Center is het de bedoeling dat binnenkomende gesprekken met een bepaalde reden (bijvoorbeeld technische vragen) worden afgehandeld door een groep agents. Op het moment dat een klant naar het Call Center belt bepaalt een arbiter applicatie (genaamd Inbound Server) welke agent het gesprek gaat afhandelen of, indien er geen agents vrij zijn, dat de klant m.b.v. Interactive Voice response door de computer zelf wordt afgehandeld. Een inbound Call Center kan handig zijn voor help desks, het verwerken van reacties op grote campagnes (bijvoorbeeld televisiereclame), het afhandelen van bestellingen, etc. Voor de implementatie van het LAN Call Center is gebruik gemaakt van de programmeertaal "VisuaI Basic". Hiermee is een zogenaamde client-server structuur gerealiseerd De agents beschikken hierbij over een telefoontoestel (headset) en een PC waarop een zelfstandige Agent applicatie loopt. Deze applicatie maakt via remote procedure calls gebruik van de verschillende op het LAN aanwezige servers, zoals de Telephony Server, de Data Handier, de Call List en de Inbound Server. Deze servers verzorgen respectievelijk de telefoonfuncties, database- en netwerkfuncties, de bellijst voor naar buiten bellen en routering naar een agent voor naar binnen bellen. De telefoonserver wordt in de huidige opstelling nog gerealiseerd door een (wat zwaardere) PC die voorzien is van een D/41E voice card van Dialogic. Deze insteekkaart kan op het moment vier telefoonlijnen besturen, maar dit aantal is eenvoudig uit te breiden door meerdere kaarten naast elkaar te gebruiken of een kaart met een grotere capaciteit te gebruiken. In de nabije toekomst zal de telefoonserver waarschijnlijk worden vervangen door een speciale telefoonserver zoals de NoveIVAT&T Telephony Server. Zowel een outbound als een inbound LAN Call Center demonstratie zijn gerealiseerd. Hierbij kwamen een aantal zaken aan het licht die voor verbetering vatbaar zijn. Zo blijkt bijvoorbeeld de snelheid van het Call Center door een tweetal bottlenecks te worden beperkt: De communicatiesnelheid van het RPCmechanisme in het Call Center en het gebruik van analoge signalering voor de realisatie van de telefoniefuncties. Verder zijn nog een aantal uitbreidingen mogelijk. Zo worden op het moment lang niet alle gebruikers- en systeemfouten door de software opgevangen. Verder moet bijvoorbeeld de weergave van management informatie over het CaU Center verder worden uitgewerkt.

5

Door gebruik te maken van ISDN-lijnen naar de telephony server kan de signalering worden verbeterd. Verder maakt ISDN ook thuiswerk door de agents mogelijk. De RPC's die nu over het ethernet lopen voor de communicatie van het Agent programma met de rest van het Call Center kunnen via een ISDN-kanaal worden verstuurd. De ethernet-verbinding kan eenvoudig worden vertaald naar een ISDN-verbinding. De programmeertaal "Visual Basic" is, na toevoeging van speciale "Call Center Controls", goed bruikbaar voor snelle realisatie van een Call Center Solution. De extra controls zorgen hierbij voor de interface van Visual Basic met een lager niveau taal (zoals C++) waarin tijdkritische zaken zaols RPC's efficil!nter geprogrammeerd kunnen worden.

6

1.

Inleiding

In het kader van het project "Call Centers" is in de periode van 4 juli t/m 4 oktober bij P1T Research, afdeling NSC, gewerkt aan de ontwikkeling van demonstratie-software. Deze software is als stageopdracht door Erwin Slob, student Informatietechniek aan de Technische Universiteit Eindhoven, onder begeleiding van Dr. Ir. J. Simons, Drs. B.l. Lippolt, Ir M.J.P. Smit en Ir. M.W. van der Schrier uitgevoerd. Dit rapport is in de eerste plaats bedoeld om de huidige status van het softwareontwikkelproces vast te leggen, maar dient tevens ter beoordeling van het verichtte stagewerk. De doelgroep waarvoor het rapport is geschreven bestaat uit de medewerkers van de afdeling NSC van P1T Research, de opdrachtgevers voor dit project van P1T Telecom en de toekomstige afstudeerder of stagiair die met deze opdracht verder gaat. Er wordt uitgegaan van enige kennis omtrent het besturingssysteem MS-Windows. Voor algemeen begrip van de demonstratie-opzet is echter geen detailkennis nodig. Bij de meeste bedrijven verloopt het contact met klanten via vertegenwoordigers die persoonlijk de klanten bezoeken. Deze vertegenwoordigers zijn daardoor voortdurend onderweg van de ene naar de andere klant. Dergelijk contact met de klant wordt zo duur en inefficiênt dat alternatieve methodes nodig zijn. In de hedendaagse zakenwereld zijn kwaliteit en klantgerichtheid de belangrijkste wapens in de concurrentiestrijd. De essentie van klantgerichtheid is dat het (toekomstige) klanten gemakkelijk gemaakt wordt om zaken te doen met de organisatie. Call centers kunnen helpen klantgerichtheid en kwaliteit te bewerkstelligen. Een Call Center is een deel van een bedrijf waar medewerkers van dat bedrijf (agents genoemd) de vragen van bellers beantwoorden, bestellingen ontvangen, informatie geven, problemen oplossen of andere soortgelijke aktiviteiten uitvoeren. Een Call Center kan bestaan uit vier mensen die rond een tafel zitten of het kunnen honderden agents zijn, eventueel verspreid over verschillende locaties.

1.1 Verschillende uitvoeringsvormen Het begrip Call Center is als volgt gedefinieerd: "Een Call Center biedt telecom-intensieve ondernemingen de functionaliteit om op effectieve en efficiênte wijze inkomende en uitgaande oproepen af te handelen en bevat in ieder geval componenten uit een telecommunicatieomgeving (pBXen, ACDs. IVRs of een openbare infrastructuur) en uit een computeromgeving met daarin een computer (bijvoorbeeld PC's, mainframes, PC-netwerken), een database en software. Beide omgevingen zijn functioneel geïntegreerd" [Schr '94A]. Zoals duidelijk moge zijn uit deze defmitie is een Call Center een erg breed begrip. Een Call Center kan vele uitvoeringsvormen hebben afhankelijk van de grootte van het gewenste Call Center en de toepassing in een bepaald bedrijf. In dit verband wordt daarom vaak gesproken over Call Center Solutions in plaats van Call Centers. Een Call Center Solution is hierbij een bepaalde hardware en software configuratie die optimaal is aangepast aan een bedrijfsprofiel. Door te kijken naar de manier waarop de telecommunicatie- en computeromgeving aan elkaar zijn gekoppeld is een ruwe onderverdeling in de verzameling van Call Center solutions te maken. Hier worden een drietal mogelijke configuraties bekeken. Voor het gemak wordt uitgegaan van een telecommunicatieomgeving bestaande uit een aan het openbare net verbonden PBX.

7

1. Geen koppeling. Elke agent heeft de beschikking over een telefoontoestel en wordt voor zijn informatievoorziening ondersteund door een PC (al dan niet in een computernetwerk).

o PC

o PC

Figuur 1: Geen koppeling Er is geen koppeling tussen de PC en de PBX, er is dus geen sprake van Computer Aided Telecommunication (CAT). Dit betekent dat alle voor het Call Center benodigde telefoniefuncties door de PBX moeten worden gerealiseerd. Dit is dus een weinig flexibele oplossing waarbij het nog maar de vraag is of alle gewenste Call Center functionaliteit zelfs daadwerkelijk is te realiseren.

2. Lokale koppeling (standalone configuratie). De koppeling tussen de PC en de PBX is op de werkplek van de agent aangebracht (desktop CAT). Voor analoge netwerken kan deze koppeling bijvoorbeeld m.b.v. een CATVOX worden gerealiseerd.

Figuur 2: Lokale koppeling Een aantal telefoniefuncties zoals het bellen van een klant of het aannemen van binnenkomende gesprekken kan nu met behulp van de PC worden uitgevoerd. De routering van een binnenkomend gesprek naar een bepaalde agent gebeurt echter nog steeds uitsluitend door de PBX. Deze configuratie is daardoor geschikt voor kleine Call Centers.

3. Centrale koppeling. A) Centrale koppeling m.b.v. mainframe of mini: De PBX wordt gekoppeld aan een grote computer, bijvoorbeeld een mainframe. Dit mainframe verzorgt vervolgens zowel de telefoniefuncties als de informatievoorziening van de agents

8

MAINFRAME

D

Figuur 3: Centrale koppeling Elke agent heeft de beschikking over een telefoontoestel of headset en een terminal die met het mainframe is verbonden. Deze configuratie is in verband met de hoge prijs van een mainframe eigenlijk alleen nog geschikt voor grote Call Centers. B) Client-server configuratie (LAN Call Center): Deze configuratie is voor de in dit rapport beschreven Call Center demonstratie gebruikt. Elke agent wordt hier ondersteund door een PC die via een LAN is verbonden met een centrale telefoon-server die alle telefoonfuncties voor zowel uitgaande als binnekomende gesprekken voor zijn rekening neemt. Voor de informatievoorziening zal in praktijk vaak ook een database-server aanwezig zijn.

Figuur 4: Centrale koppeling m.b.v. LAN Deze configuratie heeft een aantal voordelen ten opzichte van de oplossing met een mainframe. De kosten voor dit soort Call Center solutions zullen bijvoorbeeld beduidend lager zijn aangezien de meeste bedrijven al de nodige PC's hebben staan. Verder is de flexibiliteit groter. Er kunnen eenvoudig agents toegevoegd of verwijderd worden en het computernetwerk kan ook voor andere doeleinden worden gebruikt. Zo kunnen bijvoorbeeld diverse servers zoals een mail-server of een fax-server aanwezig zijn.

1.2 De probleemstelling Zoals al is gezegd is het doel van dit project de realisatie van een Call Center demonstratieopstelling. Het is namelijk de bedoeling dat wordt aangetoond dat met moderne middelen geavanceerde Call Center functionaliteit kan worden gerealiseerd, terwijl de benodigde hardware eenvoudig kan blijven. Verder dient te worden gedemonstreerd dat door gebruik te maken van een hoog niveau programmeertaal zeer snel een op een bepaald bedrijf toegespitst Call Center kan worden gerealiseerd. De hoge rekensnelheid van de moderne PC's zorgt er hierbij voor dat de performance van het Call Center toch goed blijft. In dit rapport wordt ingegaan op de realisatie van een Call Center demonstratie m.b.v. de in paragraaf 1.3 gegeven opstelling. In de hoofdstukken 3 t/m 5 wordt de gerealiseerde Call Center software in toenemende

9

mate van detail behandeld. De lezer kan daardoor zelf bepalen hoe diep hij op de stof in wil gaan. Voor een uitgebreide gebruiksaanwijzing wordt verwezen naar bijlage A.

1.3 De demonstratieopstelling De werkplek van elke agent bestaat uit een telefoontoestel (headset) en een PC. M.b.v de PC kan elke agent (klanten-) informatie opvragen uit een centrale database server en kan de agent gebruik maken van de telefonie-functies die door de telefoonserver worden aangeboden.

I!-

· . - - ...............,....,~ PC

..,

·

. . . .........:"""'""""""' · ..... -.......-..,'

·. ·

....,....,~

PC

Figuur 5: De Call Center demonstratieopstelling De telefoonserver wordt in de huidige opstelling nog gerealiseerd door een (wat zwaardere) PC die voorzien is van een D/4IE voice card van Dialogic. Deze insteekkaart kan op het moment vier telefoonlijnen besturen, maar dit aantal is eenvoudig uit te breiden door meerdere kaarten naast elkaar te gebruiken of een kaart met een grotere capaciteit te gebruiken. In de nabije toekomst zal de telefoonserver waarschijnlijk worden vervangen door een speciale telefoonserver zoals de NoveIVAT&T Telephony Server. De vier telefoonlijnen van het Call Center zijn analoog (op termijn worden ook ISDN lijnen voorzien) en komen binnen op de huiscentrale van PTT Research, Vox 6200. Deze PBX heeft een aantal functies, zoals driegesprek en groepsnummerschakeling, die voor de demonstratie wordt gebruikt. Deze doorschakelfuncties kunnen in principe ook door de telefoonserver zelf worden gerealiseerd door naast de voice card nog een analoge schakelmatrix (AMX) te installeren die de verschillende lijnen van de voice card kan doorverbinden. Dit zou echter betekenen dat er steeds twee voicelijnen voor een gesprek nodig zijn. Van deze mogelijkheid is door het toch al beperkte aantal lijnen daarom geen gebruik gemaakt. Het LAN tussen de verschillende agent pc's en de server wordt gerealiseerd door een ethemet, bestuurd door het programma Windows For Workgroups.

10

1.4 eaU center software Voor de realisatie van de Call Center demo is gekozen voor de taal Visual Basic. Visual Basic is een hoog niveau taal die speciaal bedoeld is voor de snelle realisatie van windows applicaties. Deze taal is hierdoor meer geschikt voor de implementatie van demonstratiesoftware dan een meer gestructureerde, maar lager niveau, taal zoals bijvoorbeeld Visual C++. In de demonstratie wordt de flexibiliteit van de ontwikkelde software benadrukt. De software en het interface kunnen volledig aan de wensen van de klant worden aangepast. Visual Basic heeft een event-driven structuur, wat betekent dat de programmacode niet sequentieel wordt uitgevoerd maar dat een programma is opgebouwd uit subroutines die als gevolg van een bepaald opgetreden (windows-) event worden aangeroepen. Hierdoor is het mogelijk dat binnen één applicatie een aantal subroutines simultaan worden uitgevoerd. Tevens is het mogelijk om verschillende VB applicaties tegelijk op één syteem te laten lopen. Visual Basic ondersteunt verder het windows communicatieprotocol DDE (Dynamic Data Exchange) dat is gebruikt voor de communicatie van de verschillende agent-applicaties met de centrale telefoonserver en database server. Aan het eind van hoofdstuk 3 en in bijlage B wordt dieper ingegaan op dit communicatieprincipe en het gebruik ervan in VisuaI Basic. Voor de realisatie van de software voor de telefoonserver is gebruik gemaakt van het software-pakket VBVoice. Deze programmeeromgeving is gebaseerd op Visual Basic en heeft als doel om op een zo eenvoudig mogelijke manier (m.b.v. een grafische user-interface) de voice card te besturen. VBVoice ondersteunt meerdere lijnen per applicatie en doorschakelen van lijnen m.b.v. een AMX. Verder wordt gebruik gemaakt van het programma "Announce!" t.b.v. voice opnamen (in *.vap files).

11

2.

Functionele specificatie

Een CaU Center is een onderdeel van een bedrijf waar een groep mensen (agents) verantwoordelijk is voor het telefonisch contact met (potenti~le) klanten. Functioneel gezien zijn CaU Centers onder te verdelen in twee categorieën: gericht op uitgaand verkeer (outbound) en gericht op binnenkomend verkeer (inbound) [Schr '94B]. In de nu volgende paragrafen zal de functionele specificatie van een outbound en inbound Call Center verder worden bekeken. In de laatste paragraaf zal vervolgens een lijst van eisen worden gegeven waaraan, als gevolg van deze specificaties en van een aantal gestelde wensen, het te realiseren Call Center zal moeten voldoen.

2.1 Outbound CaU Center In dit geval is het de bedoeling dat de groep agents zo efficiënt mogelijk een bepaalde groep klanten kan bellen. Een Outbound Call Center kan behulpzaam zijn bij het beheer van relaties, het inzamelen van geld voor goede doelen, marktonderzoeken of bij telefonische verkoop (telemarketing). Voor de demonstratie is uitgegaan van een specifieke case: Een bedrijf heeft een reeks proefnummers van zijn tijdschriften verzonden naar potentiële abonnees. Nu gaat het aan de hand van het aangelegde bestand de personen opbellen die een proefnummer hebben ontvangen. Deze personen wordt gevraagd of zij een beslissing hebben genomen: - willen zij een abonnement nemen? - willen zij nog een proefnummer voordat zij beslissen? - komt het gesprek nu niet uit en moeten we op een ander ogenblik terugbellen? Het scenario van vragen die de agent stelt kan verder worden uitgewerkt. Vervolgens worden deze vragen in schermen op de PC klaargezet, zodat de opbelIer deze kan oplezen en de antwoorden direct in kan voeren. Aan de hand van de antwoorden beslist de opbelIer (door gebruik van de applicatie) welke vervolghandelingen noodzakelijk zijn. Een groep van agents werkt op deze wijze het bestand af. De resultaat-file wordt (evt. elektronisch) aan de opdrachtgever van het Call Center overgedragen. Een vergelijkbaar scenario is mogelijk met bijvoorbeeld: - voorwerpen die pas aangeschaft zijn. - voorwerpen waarvan de leentermijn dreigt te verstrijken. - contracten die (binnenkort) verlengd moeten worden. Voor de realisatie van het outbound Call Center is, zoals al eerder is gesteld, uitgegaan van het clientserver principe. Dit resulteert in de volgende onderdelen: 1. Centraal databeheer: Alle voor het Call Center nodige centrale informatie wordt door een bepaalde applicatie beheerd. Onder centrale informatie wordt verstaan: klanteninformatie, vragenlijsten en de lijst van mogelijke cases. De klanteninformatie is hierbij geordend op klantnummer en bevat in ieder geval de items "naam" en "telefoonnummer". Klanteninformatie kan bestaan uit een speciale Call Center fIle, maar kan indien een bedrijf al een database heeft ook bestaan uit verwijzingen naar bepaalde velden in deze database.

12

Vragenlijsten horen bij een bepaalde case (in de software "application" genoemd). Bij de case "abonnementen" zoals aan het begin van deze paragraaf beschreven horen bijvoorbeeld vragen als "Wilt U een abonnement?", "Wilt U volgend jaar weer een proefabonnement ontvangen?". Deze vragen dienen als ondersteuning van de agent tijdens zijn gesprek met de klant. Om de lijst van vragen overzichtelijk aan de agents te representeren zijn de vragen verder zo gestructureerd dat indien een klant op de vraag "Wilt U een abonnement?" negatief antwoord de agent vervolgens niet meer de vraag "hoe wilt U betalen?" op zijn scherm krijgt. 2. Agent applicatie: Deze applicatie zorgt voor de interface tussen het Call Center en de gebruiker (de agent). Met behulp van een ergonomisch opgebouwd agent-window is de agent in staat om zo snel en eenvoudig mogelijk gebruik te maken van de nodige telefonie-functies en de beschikking te krijgen over de nodige ondersteunende klanteninformatie. Op het ogenblik dat een agent aangeeft dat hij klaar staat om een (volgende) klant te gaan bellen wordt door de bellijst bepaald welke klant aan de beurt is. De informatie die bij deze klant hoort wordt vervolgens evenals de vragenlijst uit de centrale data applicatie opgehaald en aan de agent doorgegeven. Als dit eenmaal is gebeurd kan de agent aangeven dat de klant (automatisch) moet worden gebeld. In het geval dat de klant opneemt kan de agent aan de hand van de lijst van standaardvragen de klanteninformatie wijzigen en uiteindelijk weer laten opslaan door het centrale databeheer. Als de klant echter niet opneemt of aangeeft op dat moment geen tijd te hebben kan aan de centrale data applicatie worden doorgegeven dat de klant later moet worden teruggebeld. 3. De bellijst: De bellijst is niets anders dan een applicatie die een lijst van te bellen klantnummers bevat. Om die klanten te specificeren die in de bellijst moeten komen (bijvoorbeeld alle klanten die nog niet zijn gebeld, of alle klanten die in den Haag wonen) kan een selectiecriterium worden gegeven. 4. De telefoonserver: De telefoonserver moet de voor het outbound Call Center nodige telefonie-functies kunnen realiseren en de relevante telefonie-events aan de agent kunnen terugmelden [Man '92]. Voor een outbound Call Center zijn de volgende (standaard) telefonie-functies noodzakelijk: - MakeCall: Bouw een uitgaande verbinding op - ClearConnection: Leg de hoorn neer tijdens een gesprek Verder zijn de volgende events van belang: - ConnectionCleared: Verbinding is verbroken - Delivered: Toestelopgeroepene gaat over - Established: Oproep is beantwoord - Failed: Opbouw verbinding is mislukt Voor de demonstratie wordt de activiteit van de Telephony Server op het scherm van de server PC zichtbaar gemaakt. 5. Call center statistieken: Met Call Center statistieken wordt meestal informatie over de voortgang en de resultaten van de groep agents bedoeld. Deze informatie hoeft niet alleen voor het management van het Call Center interessant te zijn, maar kan ook zorgen voor een (positieve) terugkoppeling naar de agents. Hieronder worden een aantal concrete voorbeelden in het kader van de case "abonnementen" gegeven:

13

Managemantinformatie: - Hoeveel gebelde klanten hebben daadwerkelijk een abonnement genomen? Is dit aantal lager dan normaal dan zou het vragenscenario voor de agents kunnen worden aangepast. - Hoe veel klanten heeft een bepaalde agent gedurende een bepaalde tijd gebeld? - Hoeveel abonnementen heeft een bepaalde agent verkocht? - Welke abonnementen worden door een bepaald groep klanten het meest gekocht? Terugkoppeling naar de agent: - Hoeveel klanten zijn al gebeld? - Hoeveel klanten moeten nog gebeld worden? - Hoeveel abonnementen zijn er verkocht?

14

2.2 Inbound CaU Center Hier is het de bedoeling dat binnenkomende gesprekken met een bepaalde reden (bijvoorbeeld technische vragen) worden afgehandeld door een groep agents. Op het moment dat een klant naar het CaU Center belt bepaalt een arbiter applicatie (genaamd Inbound Server) welke agent het gesprek gaat afhandelen of, indien er geen agents vrij zijn, dat de klant m.b.v. interactive voice response door een IVR-applicatie wordt geholpen (zie paragraaf 3.3.6 voor NR in het inbound CaU Center). Een inbound CaU Center kan handig zijn voor help desks, het verwerken van reacties op grote campagnes (bijvoorbeeld televisiereclame), het afhandelen van bestellingen, etc. Ook voor de demonstratie van het inbound CaU Center is uitgegaan van een uitgewerkt voorbeeld scenario, namelijk de storingsdienst van een gasbedrijf.: Een verzameling klanten laat hun gastoestellen door het gasbedrijf onderhouden. Het bedrijf heeft één toegangsnummer voor alle storingsmeldingen. De klanten worden daar te woord gestaan door het Call Center. Als een klant op het desbetreffende storingsnummer inbelt, dient eerst geverifieerd te worden dat hij inderdaad een onderhoudscontract heeft. Hiertoe wordt m.b.v. IVR het klantnummer gevraagd. De klant wordt nu doorverbonden met een agent. Deze bepaalt vervolgens zo goed mogelijK wat de aard van de storing is. Hierbij kan de applicatie behulpzaam zijn, aangezien bekend is welke toestellen de klant in huis heeft. Per toestel kan een aantal vragen worden gesteld (en algemeen over de aansluiting). Op basis van deze informatie krijgt (achteraf) een reparateur de opdracht bij de klant langs te gaan. Het inbound Call Center is een uitbreiding van het outbound Call Center. Op het moment dat een klant via een centraal nummer naar het Call Center belt wordt naar een aantal geschikte agents, die eventueel nog bezig zijn met een bellijst, de boodschap "binnenkomend gesprek" gestuurd. Een agent die op dat moment niets te doen heeft of bijna klaar is met een klant kan vervolgens aangeven dat hij de klant binnenkort kan behandelen. De bellende klant krijgt vervolgens te horen dat hij even moet wachten of wordt doorverbonden met de agent. Het Call Center is zo opgebouwd dat meerdere configuraties met dezelfde software kunnen worden gerealiseerd. Het is mogelijk om meerdere inbound applicaties (bijvoorbeeld technische vragen en het opvragen van brochures) en één outbound applicatie parallel te laten lopen. Hierdoor is het bijvoorbeeld mogelijk dat een groot Call Center dat voornamelijk gericht is op uitgaand verkeer een, in verhouding klein aantal binnenkomende gesprekken, tussen twee uitgaande gesprekken door, afhandelt De agents van het outbound Call Center zijn ten slotte vaak bereikbaar. Voor de realisatie van een inbound Call Center volgens het client-server principe zijn de volgende onderdelen noodzakelijk: 1. Agent selectie
15

Als een gesprek binnenkomt wordt de agent gevraagd of hij deze wil accepteren. Indien hij dit doet en tevens de agent is die dit het snelst doet dan krijgt hij de klant aan de lijn. De bijbehorende klanteninfonnatie komt automatisch op het schenn. 4. Telefoonserver: Op het moment dat een klant naar het CaU Center belt wordt hij eerst te woord gestaan door ( de opgenomen stem van) de telefoonserver die de klant vertelt dat hij verbonden is met een CaU Center. vervolgens dient de klant, indien meer dan één inbound applicatie actief is, via een gesproken menu een bepaalde applicatie te kiezen. De klant kan nu een bepaalde keuze maken m.b.v. de druktoetsen van zijn telefoon. De telefoonserver vraagt nu aan de klant om even geduld te hebben totdat een geschikte agent vrijkomt. Telefonie-functies: - TransferCall: - AnswerCall:

Schakel een verbinding door Beantwoord een binnenkomend gesprek

Telefonie-events: als outbound Call Center

2.3 Eisen CaU Center demonstratie Aan de hand van de functionele specificaties en enkele extra wensen zijn een aantal eisen opgesteld waaraan de te realiseren CaU Center demonstratie moet voldoen. Het is handig om deze eisen in het achterhoofd te houden bij het ontwerp van een Call Center. Deze eisen zijn: • •

,. • • • • • •

M.b.v. het Call Center moet het aantal te bellen klanten sneller kunnen worden afgewerkt dan door de afzonderlijke agents. Indien een bellijst m.b.v. meer agents wordt afgewerkt moet het ook daadwerkelijk sneller gaan. De agent heeft steeds de controle. Hij moet zélf kunnen bepalen of hij een nieuwe klant gaat bellen of dat hij een bellende klant gaat helpen. Verschillende agents moeten verschillende klanten krijgen toegewezen. De configuratie van het Call Center moet eenvoudig zijn aan te passen (flexibel). Er moeten minimaal één outbound en twee verschillende inbound applicaties simultaan kunnen lopen. Het Call Center moet ergonomisch verantwoord zijn. De agent moet een duidelijk overzicht hebben op de beschikbare infonnatie en moet zo eenvoudig mogelijk met het systeem kunnen communiceren. Klanteninfonnatie moet vlot voor een agent beschikbaar zijn. Omdat we hier te maken hebben met een demonstratie moet de werking van de software zo veel mogelijK zichtbaar worden gemaakt (statusbar). Met name geldt dit voor de Telephony Server die nonnaliter geheel onzichtbaar in de achtergrond werkt.

16

3.

Technisch ontwerp

In dit hoofdstuk wordt ingegaan op de technische realisatie van een Call Center demonstratie. Hierbij is gebruik gemaakt van de functionele specificatie en de gestelde eisen uit het vorige hoofdstuk. In het hierna volgende hoofdstuk zal aandacht worden besteed aan de daadwerkelijke implementatie van het geheel in de taal "Visual Basic". Lezers die niet zo ver in detail willen treden kunnen dit eventueel overslaan en zich tot dit hoofdstuk beperken.

3.1 Globaal model Vanwege de eis van de aan te passen configuratie en om de software overzichtelijk te houden is gekozen voor een object-geori~nteerde opbouw van het Call Center (Zie Figuur 6). Voor elk object zijn hierbij een aantal functies gedefinieerd die door de andere objecten zijn te gebruiken.

---

;' Ägent2'

"

-"

Figuur 6: Het Call Center software model Binnen Visual Basic is bovenstaand model vertaald naar een aantal, onder Windows for Workgroups, parallel lopende applicaties op de verschillende systemen binnen het computernetwerk. De verschillende functies van elk object zijn geïmplementeerd als een aantal procedures die op afstand, vanaf een willekeurig systeem binnen het netwerk zijn aan te roepen. Het aanroepen van zo'n procedure wordt verder in het verslag een remote procedure call (RPC) genoemd. Verder zijn de verschillende objecten ook verticaal zo veel mogelijk gelaagd opgebouwd. Zo hebben alle applicaties een communicatiemodule en heeft de Data Handler een informatieopslag-module. Deze modules zijn via een verzameling vaste procedureaanroepen binnen een applicatie te gebruiken. De

17

achterliggende gedachte van deze structuur is het feit dat de communicatie tussen de applicaties of de opslag van klanteninformatie in de toekomst nog moet kunnen worden gewijzigd. In paragraaf 2 en 3 worden de verschillende objecten uit het software model in het kader van respectievelijk een outbound en een inbound CaU Center behandeld. De informatieopslag-module en de communicatiemodule worden vervolgens behandeld in paragraaf 5 en 6. In paragraaf 4 wordt verder ingegaan op de representatie van klanteninformatie aan de agents via een speciale vragenstructuur.

18

3.2 Outbound CaU Center De minimale configuratie voor een outbound Call Center bestaat uit de DataHandler, de Call List, één of meerdere Agents en de Telephony Server. In dit hoofdstuk. zal op elk van deze applicaties afzonderlijk dieper worden ingegaan. Elke applicatie wordt steeds van vier kanten belicht. Eerst wordt de functionaliteit van de applicatie bekeken. Vervolgens wordt aandacht besteed aan de belangrijkste interne datastructuren. Daarna worden de door andere objecten te gebruiken functies van de applicatie behandeld. Als laatste worden per object de geboden RPC's opgesomd. Aan het eind van deze paragraaf wordt de werking van het outbound Call Center als geheel beschouwd. Hier wordt duidelijk gemaakt hoe de verschillende applicaties samenwerken om alle Call Center functionaliteit te realiseren.

3.2.1 Data Handier De Data Handier beheert alle centrale informatie van het Call Center. Hiermee wordt alle informatie bedoeld die door meerdere applicaties tegelijk kan worden gebruikt. Door al dit soort informatie centraal te beheren worden verschillende vormen van inconsistentie tegengegaan. Binnen de Data Bandier is verder een Editor aanwezig waarmee de vragenlijsten voor de agents kunnen worden aangemaakt en de bijbehorende klanteninformatie kan worden gespecificeerd. A) Functionaliteit: De Data Bandier bevat een lijst van applicatienamen (toepassingen). Een applicatienaam kan hierbij inbound of outbound zijn en bevat een verwijzing naar de bijbehorende vragenlijst en de klanteninformatie van een bepaalde groep klanten. De applicatienaam "Abonnementen" is bijvoorbeeld outbound en verwijst naar de vragen horende bij het vragenscenario van de abonnementenservice.

Type (inbound / outbound)

vragenlijst

Klant 1

Applicatienaam Klanteninformatie

""'!E'-------

Klant 2

Status (in use I not in use)

Voor deze constructie met applicatienamen is gekozen om tegen te gaan dat client-applicaties direct de files moeten specificeren waarin de klanteninformatie en vragen staan. De manier van dataopslag kan immers in de toekomst nog veranderen. Voor de opslag van klanteninformatie en vragenlijsten is voor de demo gekozen voor zelf gedefinieerde "Call Center Demo" files (ccd-files, zie paragraaf 3.5). Deze files bestaan uit de klanteninformatie van een bepaalde groep klanten en de bijbehorende vragenlijst die voor deze groep klanten van toepassing is. Tijdens de ontwikkeling van deze ccd-files had een hoge opvraagsnelheid van klanteninformatie de

19

hoogste prioriteit. De files zijn daardoor helaas niet leesbaar door andere programma's. Om dit gedeeltelijk op te lossen is het mogelijk om de klanteninfonnatie in een ccd-file als textfile te exporteren.

EXP-file

Voor het aanmaken van een ccd-file beschikt de Data HandIer over een speciale editor. Hierin moet eerst een bepaalde vragenslructuur (zie paragraaf 3.4) worden gemaakt Door deze vragenstructuur te saven heb je nu een ccd-file zonder klanten. De vragenstructuur in de ccd-file is achteraf tevens te wijzigen door de ccd-file weer te openen, de vragen te veranderen en de nieuwe vragenstructuur weer te saven. De oude ccd-file wordt nu onder een andere naam opgeslagen en de nieuwe ccd-file krijgt een hoger versienummer. Dit is nodig om de agents te laten weten dat de vragenlijst is veranderd. Wijzigen van een ccd-file waarnaar wordt verwezen door een applicatienaam die door de Call List of Inbound Server wordt gebruikt (status "in use'') wordt door de Data Handier verboden. Dit zou namelijk consistentieproblemen kunnen geven met agents die nog met de oude vragenlijst werken en nog klanteninfonnatie kunnen gaan saven. Door bepaalde velden uit een textfile met klanteninfonnatie aan velden in een ccd-file te koppelen is het mogelijk klanten in een ccd-file te importeren. Hierbij wordt uitgegaan van textfiles waarin elk infonnatieveld op een aparte regel staat en elke klant evenveel velden heeft

B) Datastructuren: ApplicationsO As AppType: QuestionO As QuestionType: ccd-file: EXP-file:

Lijst van applicatienamen Huidige vragenstructuur in editor File van het Call Center Demo fonnaat. Bevat een vragenlijst en de klanteninfonnatie van een groep klanten. Textfiles die ontstaan na exporteren van ccd-files

C) Objectprocedures:

Voor de namen van de door andere applicaties aan te roepen procedures (RPC's) zijn de volgende conventies gebruikt: 1. Procedures die voornamelijk infonnatie naar het aanroepende object moeten sturen krijgen het voorvoegsel "Give". 2. Procedures die juist voornamelijk infonnatie krijgen van het aanroepende object krijgen het voorvoegsel ''Take''. 3. Procedures waarbij de nadruk niet ligt op infomatieoverdracht (wals bijvoorbeeld "MakeCall'') krijgen geen voorvoegsel. Hieronder worden kort de door andere objecten toegankelijke Data Handier object-functies uitgelegd. Hierbij worden input- (J,) en output-parameters (Î) expliciet aangegeven. Bij de RPC's is het belangrijk dit aan te geven omdat ze ieder op een aparte manier over het LAN worden verstuurd.

20

-GiveAppInfo (J..ApplicationName As String, Î AppInfo As AppType): Deze procedure geeft alle in de Data HandIer aanwezige infonnatie over een bepaalde applicatienaam. Deze infonnatie bestaat uit: het applicatietype (outbound of inbound), een verwijzing naar de ccd-file die de klanteninfonnatie en vragenlijst bevat, de versie van deze ccd-file en de toestand waarin de applicatie zich bevindt (In Use / Not In Use) -GiveAppNames (ÎAppNamesO As String, J..AppType As String) Geeft alle aanwezige applicatienamen van een bepaald type. -GiveClientInfo (J..ApplicationName As String, J..ClientNumber As Long, ÎTempClientInfoO As String) Geeft de klanteninfonnatie van de klant met het gespecificeerde klantnummer uit de ccd-file die bij de aangegeven applicatienaam hoort. -GiveClients (J..ApplicationName As String, J..SelectQuestion As Integer, J..SelectValue As String, J..ClientLabel As Integer, ÎClientO As ClientType) Deze functie wordt alleen gebruikt door de Call List applicatie. Geeft een lijst van klantnummers en bijbehorende klantlabels (bijvoorbeeld de naam van de klant) die voldoen aan een bepaald selectiecriterium. Het selectiecriterium is hierbij gedefinieerd door aan te geven welke waarden een bepaald infonnatieveld van de gewenste klanten hoort te hebben (bijvoorbeeld alle klanten waarvan het infonnatieveld horende bij "woonplaats:" gelijk is aan den Haag. Het klantlabel wordt gebruikt om de geselecteerde klanten aan de opsteller van de bellijst weer te geven. Het klantlabel wordt gespecificeerd door m.b.v. de inputparameter "ClientLabel" een bepaald infonnatieveld aan te geven. -GiveQuestions (J..ApplicationName As String, ÎTempQuestionO As QuestionType) Deze procedure geeft de klantenlijst uit de ccd-file die door de applicatienaam wordt gespecificeerd. -TakeAddServ (J..ServAppName As String, Î Accepted As Integer) M.b.v. deze functie kan de Call List applicatie aan de Data HandIer doorgeven dat hij een bepaalde applicatienaam in gebruik heeft De bijbehorende ccd-ftle wordt nu door de Data Handler geloekt. -TakeClientInfo (J..ApplicationName As String, J..ClientNumber As Long, J..ClientInfoO As String) Deze functie wordt gebruikt door de agent applicaties om gewijzigde klanteninfonnatie weer op te slaan op de plaats in de ccd-file waar de infonnatie vandaan kwam. - TakeRemServ (J..ServAppName As String) De Call List applicatie kan aangeven dat hij een bepaalde applicatienaam niet meer gebruikt. De ccdfile horende bij deze applicatienaam kan nu weer worden gewijzigd. D)RPC's: geen

3.2.2 eaU List Het programma Call List verwrgt de lijst van klanten die door de agents moeten worden gebeld. Er is uitgegaan van maximaal één bellijst in de Call Center demonstratie. A) Functionaliteit:

21

Voordat een bellijst kan worden gemaakt moet de gebruiker eerst aangeven met welke applicatie hij werkt De CaU List applicatie haalt daarvoor eerst alle mogelijk outbound applicatienamen op uit de Data Handier m.b.v. de RPC "GiveAppNames". Nadat de gebruiker een bepaalde applicatienaam heeft geselecteerd wordt alle bijbehorende applicatieinformatie uit de Data Handier opgehaald (RPC: ''GiveAppInfo''). Vervolgens kunnen klanten uit de bij de applicatie horende ccd-file worden geselecteerd door een selectiecriterium te definieren. Dit wordt gedaan door aan te geven dat een bepaald informatieveld van de gewenste klanten groter, kleiner of gelijk moet zijn aan een bepaalde waarde. De nummers van de op deze wijze geselecteerde klanten worden vervolgens d.m.v. de RPC "GiveClients" opgehaald en via een geselecteerd klantlabel in een lijst weergegeven. Eventueel kan de gebruiker nog individuele klanten uit deze lijst verwijderen.

B) Datastructuren: Application As AppType: QuestionO As QuestionType: ClientO As ClientType

De geselecteerde applicatienaam Lijst van bij de klanteninformatievelden horende labels. Worden gebruikt voor de definitie van het selectiecriterium en weergave van de klanten. De lijst van te bellen klanten.

C) Objectprocedures: - GiveNextClient (ÎClientNumber As Long, Î ApplicationName As String, ÎNumberDone As Integer, ÎNumOfClients As Integer) Als deze functie wordt aangeroepen door één van de Agent applicaties wordt het nummer van de klant die het meest vooraan in de bellijst staat en nog niet is gebeld doorgegeven. De klant wordt vervolgens in de lijst tussen haakjes gezet. De applicatienaam wordt doorgegeven om de Agent in staat te stellen de bij het klantnummer horende informatie uit de juiste ccd-file te halen. Verder wordt nog wat extra informatie aan de agent doorgegeven, zoals het aantal klanten dat is gebeld en het totale aantal klanten in de bellijst.

D)RPC's: GiveAppInfo GiveAppNames GiveClients GiveQuestions TakeAddServ TakeRemServ

(Data Handier) (Data HandIer) (Data Handier) (Data Handier) (Data Handier) (Data Handier)

3.2.3 Agent Deze applicatie zorgt voor de interactie van het CaU Center met de gebruikers (zie Figuur 7).

22

~'

tlnde Instellingen Uelp «YOGI...U.n»

«U.Iog»

H_ U....0 p r o e l _ l... 0ftlv
111111

Welk liidlChrifl yond U 'IOOIai int.e.....? 'ol'" vindl U y... do ..ijzen? ....... U zich op a.. lijdochrill ..bonn....? lIal Welk lijdoc"'~1 tie.. U? (KanlkIo..anl \11....., wilt U uw _de nummer onIvan....?

IJ. Jan... T....oon: 1N7Q.123451B7

Ge wil U betalen?

c..n.-

Via~l'Ijra

:':

,~:i';:';:

,

"

,~:

'" ,

,:~,;!;",:

Figuur 7: Het Agent-window. Omdat de agent zo efficiënt mogelijk met de applicatie moet kunnen werken is veel aandacht besteed aan de ergonomie van bovenstaand Agent-window. Zo is zo veel mogelijk van de bestaande Windows conventies uitgegaan; de menubalk bevindt zich bovenin en informatie over instellingen of toestanden van de applicatie worden onderaan het window weergegeven. Verder kan de agent de nodige telefoon- en database-functies gebruiken met een minimum aantal buttons (rechts onderin het window) en wordt standaard klanteninformatie in een apart gedeelte van het window weergegeven (rechts boven). Voor het invoeren van klanteninformatie of het selecteren van een vraag hoeft de agent uitsluitend gebruik te maken van het toetsenbord. Een combinatie van het toetsenbord met de muis heeft namelijk een negatief effect op de maximale invoersnelheid van de agent A) Functionaliteit: Als de agent aangeeft de volgende klant te willen gaan bellen wordt eerst een klantnummer uit de bellijst gehaald m.b.v. de RPC "GiveNextClient". Deze RPC geeft tevens de applicatie waarmee de agent dient te werken. Meteen daarop wordt, indien die nog niet in het geheugen staat, de bijbehorende vragenstructuur opgehaald (RPC: "GiveQuestions"). Daarna wordt de bij het verkregen klantnummer horende klanteninformatie geladen via de RPC "GiveClientInfo". De agent heeft nu alle informatie die hij nodig heeft op zijn scherm. De Agent applicatie wacht nu tot de agent het teken geeft om de klant (automatisch) te gaan bellen. Dit gaat vervolgens zeer eenvoudig m.b.V. de RPC "MakeCali" waarbij het toestelnummer van de agent en het telefoonnumer van de klant worden opgegeven. Optredende telefoon-events worden aan de agent doorgegeven. Als de agent klaar is met zijn gesprek kan hij het teken geven om de verbinding te verbreken (RPC: "ClearConnection"). Vervolgens kan de agent nog even verder gaan met het wijzigen van de klanteninformatie en vervolgens aangeven de informatie op te slaan (RPC: "TakeClientInfo''). Eventueel kan de agent zonder te bellen een nieuwe klant gaan afhandelen door onmiddellijk om de vogelde klant te vragen. De Agent applicatie staat nu weer klaar voor het behandelen van de volgende klant uit de bellijst.

B) Datastructuren: AppName:

Huidige applicatienaam

23

QuestionO As QuestionType: ClientInfoO As String:

Vragenlijst Klanteninformatie

C) Objectprocedures:

- TakeLineEvents (J..EventDescription As String): De Agentapplicatie reageert op een binnenkomende telefonie-event

D) RPC's:

ClearConnection GiveClientInfo GiveNextClient GiveQuestions MakeCaU TakeClientInfo

(TelServer) (Data Handier) (CaU List) (Data Handler) (TelServer) (Data Handier)

3.2.4 Telephony Server De Telephony Server verzorgt de telefoonfuncties voor de agents en geeft de nodige informatie over optredende telefoonevents. A) Functionaliteit: Op het moment dat de procedure "MakeCali" door een Agent applicatie wordt aangeroepen wordt gekeken of één van de voicelijnen vrij is. Indien dit het geval is wordt de status van de gekozen lijn op "busy" gezet en gaat de lijn "offhook". Hierna wordt eerst het gegeven agenttoestel gebeld en gewacht tot de agent heeft opgenomen. Vervolgens wordt de agent "on hold" gezet en begint de Telephony Server m.b.v. de *30-functie van de Vox 6200 PBX een drieweggesprek met het aangegeven telefoonnumer van de klant, waarbij de agent bij wordt geschakeld zo gauw de klant opneemt

Gedurende de tijd dat een agent een bepaalde voicelijn bezet houdt worden de volgende telefoon-events op het moment dat ze optreden aan de agent doorgegeven: De agent heeft zijn toestel opgenomen en de Tel. Server heeft het nummer van de - Delivered: klant gedraaid. De klant heeft opgenomen. - Established: - ConnectionCleared: Verbinding is verbroken Het opbouwen van de verbinding naar de agent of naar de klant is mislukt. - Failed:

B) Datastructuren: LineStatus(NUMOFCHANNELS) As LineStatusType: Bepaalt per lijn of, en zo ja door wie, een lijn bezet is. C) Objectprocedures:

- ClearConnection (J..AgentComputer As String) - MakeCall (J..AgentComputer As String, J..AgentTelNumber As String, J..ClientTelNumber As String)

24

D)RPC's: GiveLineEvents (Agent)

3.2.5 Typische werking outbound CaU Center Om de samenwerking tussen de verschillende objecten van het outbound CaU Center duidelijK te maken wordt hier een specifiek geval verder uitgewerkt. In het algemeen zal het communicatiepatroon tussen de verschillende applicaties dus niet gelijK zijn aan het patroon dat in deze paragraaf wordt behandeld. Het gekozen voorbeeld maakt echter wel snel duidelijk hoe het Call Center in principe werkt en is zo gekozen dat alle mogelijke RPC's erin voorkomen. Data Handier

Call List

Gi veAppNames

1.

T

I

TakeAddServ

2.

GiveQuestions

4.

GiveClients

5.

GiveNextClient

6.

I

GiveQu stions

7.

GiveCl i ntInfo

8. I

I

MakeCall

!

TakeLineEvents

10.

1

11.

TakeLineEvents

ClearConnectlon

12. 13.

I

GiveAoolnfo

3.

9.

Tel. Server

,

14.1

TakeCli ntInfo

14

(TakeclientDone)

15. '+4_--'T:.::.ak::::e""Rem=se:.=.rv:....-------'.1

Figuur 8: Typische berichtenstroom outbound Call Center Begintoestand: - De Data Handier bevat een lijst van mogelijke outbound-applicaties, die naar reeds bestaande ccd-files verwijzen. - De Call List heeft nog geen outbound applicatie geselecteerd en bevat nog geen bellijst - De Agent bevat nog geen klanteninformatie, wél is het toestelnummer van de agent bekend. - De Tel. Server heeft de beschikking over minimaal één vrije lijn I. De gebruiker van de Call List applicatie wil een applicatienaam gaan selecteren. Om hem een lijstje van mogelijK outbound applicaties te kunnen geven worden al deze applicaties opgehaald uit de Data HandIer. 2. De gebruiker heeft een applicatienaam geselecteerd en Call List geeft dit nu door aan de Data HandIer. Indien hier blijkt dat de gespecificeerde outbound applicatie nog niet in gebruik is wordt de applicatieaanvraag gehonoreerd en de status van de applicatienaam op "in use" gezet. 3. De Call List applicatie haalt de bij de geselecteerde applicatie horende informatie op. Deze informatie is voor de Call List applicatie zélf niet zo belangrijk en wordt alleen ter controle door de gebruiker gebruikt

25

4. De vragenlijst horende bij de geselecteerde applicatie wordt opgehaald om de gebruiker de mogelijkheid te geven een klantenlabel te specificeren en een selectiecriterium voor de te bellen klanten te definieren. 5. De nummers van de door het selectiecriterium geselecteerde klanten horende bij de actieve applicatienaam worden opgehaald uit de Data HandIer en in de CaU List applicatie m.b.v. de door het gebruiker gespecificeerde label gerepresenteerd. 6. Eén van de agents komt nu op het idee om een klant te gaan bellen en geeft dit door aan de Agent applicatie. Deze haalt bij de Call List het nummer van de eerste klant op die moet worden gebeld en krijgt tevens te horen bij welke applicatienaam dit klantnummer hoort. 7. De Agent applicatie heeft nog niet eerder een klant van deze outbound applicatie gebeld en heeft dus nog niet de juiste vragenlijst in zijn achtergrondgeheugen. De vragenlijst wordt daarom eerst uit de Data HandIer opgehaald door de actieve applicatienaam aan te geven. 8. De Agent applicatie haalt nu de bij de vragenlijst horende klanteninformatie van de te bellen klant op. 9. De agent geeft opdracht de klant automatisch te gaan bellen. De Agent applicatie geeft hiervoor opdracht aan de Telephony Server, waarbij hij het toestelnummer van de agent en het telefoonnummer van de te bellen klant doorgeeft. 10. Telefoon-events worden door de Tel. Server doorgegeven aan de Agent applicatie en hier op het scherm zichtbaar gemaakt. 11. Zie 10. 12. De agent geeft via de PC de verbinding te willen verbreken. 13. De agent is klaar met het wijzigen van de klanteninformatie van de gebelde klant en geeft nu opdracht de nieuwe informatie op te slaan in de centrale database. De Agent applicatie geeft de klanteninformatie vervolgens door aan de Data Handier. 14. De Agent applicatie geeft aan de Call List door dat de klant is gebeld en er nieuwe informatie is opgeslagen. De Call List kan de klant nu definitief uit de lijst strepen. 15. De Call List geeft aan met de huidige outbound applicatie te stoppen. In de datahandler wordt de bijbehorende applicatienaam weer vrijgegeven.

26

3.3 Inbound CaU Center De minimale configuratie voor een inbound Call Center bestaat uit de DataHandler, de Inbound Server, één of meerdere Agents en de Telephony Server. Buiten de Inbound Server werd elk van deze applicaties ook al voor het outbound Call Center gebruikt. Het inbound Call Center moet dan ook gezien worden als een uitbreiding van het outbound Call Center.

3.3.1 Data Handier Moet nu ook een lijst van actieve servers bevatten, omdat nu meerdere Call Center configuraties mogelijk zijn. De Agent applicatie moet, evenals de Telephony Server, namelijk weten of hij outbound e%f (meerdere) inbound functies moet ondersteunen. A) Functionaliteit:

Op het moment dat een Agent applicatie wordt opgestart logt deze automatisch in bij de Data BandIer door zijn (unieke) computernaam op te geven. De naam van de computer waarop zich de Data BandIer bevindt is hiervoor als constante waarde vast in elke Agent applicatie geprogrammeerd. Op het moment dat een Agent inlogt wordt de lijst van de op dat moment actieve applicatienamen doorgegeven aan de Agent. De Agenteomputemaam wordt vervolgens in een lijst van actieve agents in de Data HandIer opgeslagen. Deze lijst wordt vervolgens gebruikt om veranderingen in de lijst van actieve applicatienamen aan alle actieve agents door te geven, zodat elke Agent applicatie real-time weet welke applicaties er worden gebruikt Ook de Telephony Server geeft aan de Data Handler door dat hij actief is als hij wordt opgestart zodat ook hij een real-time aangepaste lijst van actieve applicaties heeft. De Telephony Server heeft deze informatie nodig om de inbellende klant via een gesproken menu uit de actieve inbound applicaties te laten kiezen. B) Datastructuren: AgentList() As AgentListType: TelServActive As Integer:

Lijst van actieve agents Is true indien Telephony Server actief.

C) Objectprocedures: - TakeLogIn (J,AgentName As String, J,AgentComputerName As String, ÎApplicationListO As String) Zet gespecificeerde Agent applicatie in lijst van actieve agents en stuur de initi~le applicatielijst op naar de agent - TakeLogOut (J,AgentComputerName As String) Haal de Agentapplicatie die op de aangegeven computer staat uit de actieve lijst. - TakeServActive (J,TelServComputerName As String, Î ApplicationListO As String) De Data BandIer stuurt de Telephony Server de initi~le lijst van actieve inbound applicaties en blijft deze updaten totdat een TakeServInAvtive-commando is gegeven. - TakeServInActive (J,TelServComputerName As String) De Data BandIer weet nu dat de Telephony Server niet meer actief is.

27

C)RPC's: TakeAgentAddServ TakeAgentRemServ TakeTelServAddServ TakeTelServRemServ

(Agent) (Agent) (TelServ) (TelServ)

3.3.2 Inbound Server Deze applicatie bepaald naar welke agent een bepaald inkomend gesprek wordt doorverbonden. A) Functionaliteit: De Inbound Server kan meerdere inbound applicaties ondersteunen. Hiervoor wordt bij het opstarten van deze Server eerst de lijst van actieve inbound applicaties doorgegeven aan de Data HandIer m.b.v. (meerdere) ''TakeAddServ'' RPC's. Agents krijgen nu van de Data Handier te horen welke inbound applicaties er actief zijn en kunnen zich voor bepaalde applicaties aanmelden bij de Inbound Server m.b.v. de RPC "TakeAgentAvailability". Als een bepaalde lijn van de Telephony Server wordt gebeld krijgt de Inbound Server een RPC "AnswerCall" binnen. Als meer dan één inbound applicatie actief is geeft de Telephony Server hierbij tevens aan om welke applicatie het gaat. De Inbound Server reageert vervolgens door alle Agent applicaties die zich voor de gespecificeerde inbound applicatie hebben opgegeven een bericht ''TakeAgentRequested'' te sturen. De eerste Agent applicatie die hierop reageert via een "AgentAccepts" wordt vervolgens aangewezen om de inbellende klant te gaan helpen. Via de RPC "TransferCall" waarbij het nummer van de gekozen agent wordt opgegeven wordt dit aan de Telephony Server doorgegeven.

B) DataStructuren: ApplicationsO As String: Lijst van actieve inbound applicaties. AgentAvailabilityListO As AgentAvailabilityListType: Lijst die per inbound applicatie aangeeft welke agents beschikbaar zijn voor het aannemen van inkomende gesprekken. C) Objectprocedure: - AnswerCail (J..ApplicationName As String, J..VoiceLine As Integer) De Telephony Server geeft door op een bepaalde lijn een klant te hebben die in het kader van de gespecificeerde applicatienaam wil worden geholpen. De Inbound Server komt hierdoor in een toestand waarin hij zo snel mogelijk een geschikte agent gaat zoeken. Dit zou eventueel een nietmenselijke IVR·agent kunnen zijn. - TakeAgentAccepts (J..AgentComputerName As String, J..VoiceLine As Integer, J..AgentTelNumber As String, Î Accepted As Integer) Een bepaalde Agent applicatie geeft aan het inkomende gesprek te willen afhandelen en geeft hiervoor zijn identiteit (unieke computemaam) en zijn toestelnummer door aan de Inbound Server. Deze geeft vervolgens via de output parameter "Accepted" aan de Agent applicatie door of hij ook daadwerkelijk is geselecteerd.

28

- TakeAgentAvailability (J-AgentComputerName, J-AppListO As String) Een Agent applicatie geeft aan de Inbound Server door voor welke applicaties hij in pnnclpe beschikbaar is. Deze informatie wordt in de locale beschikbaarheidslijst van de Inbound Server bewaard.

D)RPC's: GiveAppInfo GiveAppNames TakeAddServ TakeAgentRequested TakeRemServ TransferCall

(Data Handier) (Data Handier) (Data Handier) (Agent) (Data Handier) (TelServer)

3.3.3 Aanpassingen Agent De agent moet zich naast zijn outbound activiteiten ook nog voor inbound applicaties kunnen opgeven. Op het moment dat een klant in het kader van een bepaalde inbound applicatie naar het Call Center belt krijgt elke agent die zich voor deze applicatie had opgegeven dit op zijn scherm te zien en kan hij, als hij het idee heeft dat hij binnen niet al te lange tijd weer vrijkomt, deze klant in principe accepteren. Het Call Center bepaalt vervolgens of de agent ook daadwerkelijk de meest geschikte is uit de lijst van agents die de klant willen aannemen. A) Functionaliteit: Als een nieuwe Agent applicatie wordt opgestart wordt deze eerst ingelogd bij de Data Handler door zijn unieke computemaam op te geven. De Agent applicatie krijgt daarop een initi~le lijst van actieve applicaties terug van de Data Handier, welke steeds automatisch wordt aangepast indien dat nodig is (m.b.v. "TakeAddServ" of "TakeRemServ"). De agent kan in het "Instellingen"-menu op zijn windowopgeven voor welke inbound applicaties hij beschikbaar is. Deze informatie wordt vervolgens via de RPC "TakeAgentAvailability" doorgegeven aan de Inbound Server. Op het moment dat er een bericht "TakeAgentRequested" binnenkomt van de Inbound Server om aan te

geven dat er een inbellende klant is gedetecteerd krijgt de agent een klein windowtje op zijn scherm waarop hij aan kan geven of hij de klant al dan niet kan aannemen. Indien de agent positief reageert wordt door de Agent applicatie het bericht "TakeAgentAccepts" naar de Inbound Server gestuurd. Hierbij wordt het huidige toestelnummer (kan door agent worden veranderd) en de aan te nemen lijn meegezonden. Als de agent na een bepaalde tijd nog niet heeft gereageerd verdwijnt dit window gewoon en neemt de Agent applicatie aan dat de agent het verzoek niet accepteert. Indien het "TakeAgentAccepts"-bericht daadwerkelijk door de Inbound Server wordt geaccepteerd dan wordt snel de klanteninformatie m.b.v. het door de inbellende klant opgegeven klantnummer uit de database gehaald via de RPC "GiveClientInfo".

29

Op dit moment is het mogelijk dat de agent toevallig niets te doen heeft. De opgehaalde klanteninformatie wordt dan op het scherm weergegeven en de klant wordt onmiddellijk naar de agent doorgeschakeld. Het is echter zeer waarschijnlijk dat de agent op het moment dat de klant belt nog bezig is met (de eindfase van) een gesprek met een andere klant. De klanteninformatie wordt dan in het achtergrondgeheugen van de Agent applicatie opgeslagen en de klant wordt dan pas doorgeschakeld als de agent de hoorn heeft neergelegd.

B) Datastructuren: OutApp As OutAppType: InAppO As InAppType:

Variabele die aangeeft of de outbound applicatie van het Call Center actief is en, zo ja, welke outbound applicatienaam hierbij hoort. Lijst van actieve inbound applicaties. Per applicatie is bijgehouden of de agent zich ervoor heeft opgegeven.

C) Objectprocedures:

- TakeAgentReguested (J..AgentComputerName As String, J..VoiceLine As Integer, J..ApplicatieNaam As String) De Inbound Server heeft een agent nodig om een klant die in het kader van de gespecificeerde applicatie op de aangegeven lijn naar het CaU Center belt te behandelen. De Agent applicatie komt hierdoor in een toestand waarin een verzoek-window op het scherm zichtbaar wordt (waarmee de agent aangeeft of hij de klant accepteerd) die na enkele seconden vanzelf verdwijnt als er geen reactie van de agent komt (de agent is bijvoorbeeld niet aanwezig). - TakeAgentAddServ (J..AgentComputerName As String, J..ApplicationName As String, J..AppType As Integer) De Data Handier geeft aan dat er een nieuwe in- of outbound applicatie aan de interne lijst van actieve applicaties moet worden toegevoegd. - TakeAgentRemServ (J..AgentComputerName As String, J..ApplicationName As String) De Data Handier geeft aan dat een bepaalde (unieke) in- of outbound applicatie niet meer actief is en dus uit de locale lijst van applicaties moet worden verwijderd. D) RPC's:

TakeAgentAccepts TakeAgentAvailability TakeLogIn TakeLogout

(Inbound Server) (lnbound Server) (Data HandIer) (Data Handier)

3.3.4 Uitbreidingen Telephony Server

De telefoonserver moet ervoor zorgen dat inbeUende klanten een bepaalde applicatienaam kunnen kiezen en hun klantnummer kunnen geven. Vervolgens wordt de klant naar een door de Inbound Server gespecificeerde (eventueel niet-menselijke) agent doorgeschakeld. A) Functionaliteit: Op het moment dat de Telephony Server wordt opgestart krijgt hij een lijst van actieve inbound applicaties van de Data Handier. Deze list wordt net als bij de Agent applicatie al het geval was gewijzigd als dat nodig is.

30

Klanten kunnen het CaU Center bellen via een centraal nummer (in dit geval het nummer 070-3329978). Dit nummer is een in de PBX geprogrammeerd groepsnummer dat automatisch wordt doorgeschakeld naar de eerste vrije lijn van de Telephony Server. Deze zorgt ervoor dat deze lijn "otlhook" gaat en zorgt er vervolgens voor dat de lijn niet meer voor outbound applicaties kan worden gebruikt De Telephony Server stuurt vervolgens een ingesproken groet de lijn op en vraagt daarna via een gesproken menu waar de klant voor belt. Via dit menu kiest de klant één van de actieve inbound applicatienamen m.b.v. de druktoetsen. Daarna wordt de klant gevraagd zijn klantnummer in te toetsen. Het ingetoetste klantnummer wordt door de Telephony Server herhaald en de kant krijgt nog de mogelijkheid om het nummer te wijzigen. Als de klant aangeeft dat het nummer goed is overgekomen vraagt de Telephony Server of de klant even geduld wil hebben en wordt een bericht "AnswerCall" naar de Inbound Server gestuurd. Op een gegeven moment heeft de Inbound Server een geschikte agent gevonden en krijgt de Telephony

Server het bericht "TransferCall" waarbij het toestelnummer van de agent wordt meegezonden. De Telephony Server probeert vervolgens de klant via de *30-functie van de PBX door te schakelen naar dit toestelnummer. Als de agent op dat moment de hoorn op de haak heeft lukt dit meteen, maar als het toestel van de agent bezet blijkt te zijn wacht de Telephony Server tot de agent neerlegt voordat hij de verbinding doorschakelt. B) Datastructuren:

InbApp() As InbAppType:

Lijst van actieve inbound applicaties waaruit een klant kan kiezen.

C) Objectprocedures:

- TransferCaU (..l.VoiceLine As Integer, ..l.AgentTelNumber As String) De Telephony Server komt in een toestand waarin hij probeert de gespecificeerde lijn naar het gespecificeerde toestelnummer door te schakelen. - TakeTelServAddServ (..l.TeIServComputerName As String, ..l.ApplicationName As String) Een extra inbound applicatie moet aan de lijst van actieve applicaties worden toegevoegd. - TakeTelServRemServ (..l.TeIServComputerName As String, ..l.ApplicationName As String) Een bepaalde (unieke) inbound applicatie moet aan uit de lijst actieve applicaties worden geschrapt D)RPC's: AnswerCall TakeTServActive TakeTServInActive

(Inbound Server) (Data Handier) (Data Handier)

3.3.5 Typische werking inbound CaU Center Om ook de werking van het inbound Call Center als geheel te verduidelijken wordt weer een representatief voorbeeld verder uitgewerkt

31

Data Handler

Agent

Inbound Server

Tel. Server

I

I TakeTServActive

1.

Take ogIn

2.

GiveAPpNames 3.

4. 5.

TakeAddServ

GiveApplnfo TakeAae

AddServ

6.

TakeTelServAddServ

7.

TakeAqentAvailability

8.

9.

GiveQuëstions Answe Cal!

10.

11.

Ta keAaentAcceDt s

12. 13.

Transf rcal! TakeLineEvents

15.

17.

18.

,.,."L.."

ClearConnection

TakeAaentAvailabilitv

Take oaOut

20. TakeRemServ

TakeTelServRem5erv

22. 23.

,

TateLineEvents

19.

21.

I

GiveCli ImtInfo

14.

16.

!

TakeAaentReauested

I

TakeTServlnActive

Figuur 9: Typische berichtenstroom inbound Call Center Begintoestand: - De Data Handier bevat al een lijst van mogelijke inbound applicaties, die naar reeds bestaande ccd-files verwijzen 1. 2.

3.

4. 5. 6. 7. 8. 9. 10.

De Data HandIer krijgt te horen dat de Telephony Server actief is. Er wordt een initi~le lijst van actieve inbound applicaties naar de Tel. Server gestuurt. Er wordt een nieuwe Agent aan de lijst van actieve Agents toegevoeg. De Agent krijgt een lijst van actieve in- en outbound applicaties. De gebruiker van de Inbound Server wil een (extra) inbound applicatie selecteren. De Inbound Server haalt hiervoor alle mogelijke inbound applicatienamen op uit de Data HandIer zodat de gebruiker kan kiezen. Er is een bepaalde inbound applicatienaam geselecteerd. De keuze wordt geaccepteerd en toegevoegd aan de lijst van actieve applicaties. Zie outbound. De Agent krijgt te horen dat er een extra actieve applicatie is. Hetzelfde geldt voor de Telephony Server. De agent heeft zich opgegeven voor de actieve inbound applicatie en de Agent applicatie geeft dit nu door aan de Inbound Server. De Agent applicatie zet de vragenlijst die bij de geselecteerde actieve inbound applicatie hoort alvast in zijn achtergrondgeheugen, zodat later sneller van applicatie kan worden gewisseld. De Tel. Server heeft een inbellende klant gedetecteerd en geeft dit samen met het klantnummer en de gewenste inbound applicatie door aan de Inbound Server.

32

11. De Inbound Server vraagt aan alle voor de gewenste inbound applicatie geschikte Agents of ze de klant in principe kunnen behandelen. 12. Een Agent geeft aan dat hij de klant in principe aanneemt en de Inbound Server bepaalt dat de Agent ook daadwerkelijk de klant krijgt 13. De Agent applicatie haalt de bij de klaar staande klant horende klanteninfonnatie op uit de Data Handier... 14....en tegelijkertijd geeft de Inbound Server door dat de klant moet worden doorgeschakeld naar de geselecteerde agent. 15. Zie outbound. 16. Zie outbound. 17. Zie outbound. 18. Zie outbound. 19. De Agent applicatie wordt gestopt en er wordt aan de Inbound Server doorgegeven dat de Agent niet meer beschikbaar is voor alle inbound applicaties. 20. Ook de Data HandIer krijgt opdracht om de Agent uit de lijst van actieve Agents te schrappen. 21. De inbound applicatie op de Inbound Server wordt nu ook gestopt. De Data HandIer verwijdert hem uit de lijst van actieve applicaties. 22. De Data HandIer wijzigt ook de lijst van de Telephony Server. 23. Als laatste wordt ook de Telephony Server gestopt. De Data HandIer weet nu dat er geen updates van de lijst van actieve inbound applicaties naar deze server moeten worden gestuurd.

3.3.6 Interactive Voice Response-Agents Als uitbreiding op het inbound Call Center is gedacht aan het toevoegen van zogenaamde IVR-Agents. Deze worden verzorgd door een speciale server en kunnen via interactive voice response de klant toch verder helpen als alle agents bezet zijn. Als op een gegeven moment een geschikte agent vrij komt kan de verbinding naar deze agent worden doorverbonden en wordt alle door de IVR-Agent verzamelde infonnatie doorgegeven. Eventueel kan de IVR-Agent de klant ook helemaal afhandelen en de verkregen infonnatie opslaan. Vanwege de werking van de programmeertaal VBVoice moeten de IVR-Agents als extra taak van de Telephony Server gerealiseerd worden. Voor het realiseren van IVR kan gebruik worden gemaakt van speciale ccd-files bestaande uit selectievragen of infonnatievragen waarop m.b.v. een rij cijfers kan worden geantwoord. De tekst bij deze vragen moet vervolgens verwijzen naar een gesproken zin in een vap-file (Announce!) en de klant krijgt de mogelijkheid om via de druktoetsen van zijn telefoon antwoord te geven op de vragen.

33

3.4 Vragenstructuur Bij veel CaU Centers gebruik gemaakt van een vooraf bepaalde verzameling standaardvmgen om het kontakt met de klant zo soepel en efficient mogelijk te laten verlopen. Ook bij de gerealiseerde Call Center demo kan de agent gebruik maken van een aantal door de applicatie geleverde standaardvragen. Een bijkomend voordeel is hier dat de vragen tevens een bepaaalde structuur hebben (zie Figuur 10) waarbij alleen die vragen op het scherm komen die op een bepaald moment voor de agent relevant zijn.

- se:ectbn queltim

c=::> -

lIDm atbn quelÖln

Wollenlllgel);cp

hle""'b1ow

2l:lt>-

baal:.

Figuur 10: Vragenstructuur Elke vraag heeft betrekking op één bepaald veld uit de klanteninformatie van een bepaalde klant. Dit veld wordt gespecificeerd door het unieke nummer van een vraag. De vmgenstructuur is opgebouwd uit twee soorten vragen, namelijk informatievmgen en selectievmgen (Zie Figuur 11). De informatievragen hebben hoogstens één volgende vraag terwijl de selectievmgen 2 tot 10 volgende vragen hebben. Verder verwijst een informatievraag naar een veld bestaande uit een willekeurige string (de informatievraag "Naam" kan bijvoorbeeld naar de string "Jansen" wijzen) en een selectievraag naar een veld waarin een getal van 0 tlm 9 staat (dit getal geeft aan welke keuze door de agent is gemaakt).

Figuur 11: De twee vraagtypen.

34

Een selectievraag heeft dus altijd een bepaald aantal mogelijke opties (bijvoorbeeld "Ja" en "Nee" of "Optie I", "Optie 2" en "Optie 3"). De optie die de agent kiest wordt als klanteninformatie opgeslagen en tevens gebruikt om te bepalen welke vragen er vervolgens op het scherm zichtbaar moeten worden. Zoals al eerder vermeld gebeurt de verwijzing van een vraag naar een veld uit de klanteninformatie van een bepaalde klant m.b.V. een uniek vraagnummer. Dit vraagnummer is tevens de plaats van de vraag in de vragenlijst. Om ervoor te zorgen dat de vragenlijst geen gaten vertoont is een gesloten nummering van de vragen nodig. Verder moet gespecificeerd worden welke vraag de eerste vraag (nummer I) is. In de demonstratiesoftware is dit gerealiseerd door iedere keer als de vragenlijst is veranderd (bijvoorbeeld na toevoegen of verwijderen van een vraag) de vragen opnieuw te nummeren m.b.v. een soort depth-frrstsearch algoritme. N.B.: De termen informatievraag en selectievraag kunnen voor verwarring zorgen. Ze worden in dit rapport namelijk alleen gebruikt om de hiervoor beschreven datastructuren te specificeren. De bijbehorende vraagtekst hoeft in praktijk niet daadwerkelijk in de vragende vorn te staan. Teksten zoals "Geef uw adres" of "Telefoonnummer:" kunnen ook voorkomen.

35

3.5 Opslag van klanteninformatie Zoals al eerder is opgemerkt zullen de meeste bedrijven die een Call Center gaan gebruiken al over een database-server beschikken. In dat geval zal de Call Center gebruik moeten gaan maken van de reeds aanwezige informatie. De Data Handier moet dan zorgen voor de koppeling van het Call Center met de database. Voor de demonstratie is echter nog gekozen voor dataopslag door de Data Handier zélf. Dit heeft als voordeel dat de opslag van klanteninformatie op zo'n manier kan worden gedaan dat de agent het zo snel mogelijk beschikbaar heeft. Visual Basic levert namelijk niet de meest snelle programma's op en het zou erg slordig zijn als een agent eerst een geruime tijd moet wachten voordat hij de informatie van een inbellende klant op zijn scherm heeft. Er is gekozen voor een speciaal Call Center Demo fIleformaat (CCD-formaat). Deze fIles bevatten steeds één vragenlijst en de antwoorden op deze vragen van een x-aantal klanten. De CCD-files zouden in de toekomst kunnen dienen als een soort buffers voor de koppeling van de Data Handier met de aanwezige database-server(s) of voor de opslag van statistische gegevens van gebelde klanten. Zie onderstaande figuur voor de opbouw van CCD-fIles.

t formaat-herkenning

13

15

t

t

tersiJ

19

21

t t I I I I aantal klanten

tantat vragen

2l+(4*klantnr)

t I I I I I I I I I

positie klant 1

I

positie klant 2

I

positie klant 3

25+ (4 *aant. klanten)

- positie klant 1 positie klant 1

t I I I I I I

I I I I I I

•

(Klant 1)

+HOLE - positie klant 2 positie klant 2

t I I I I I I

I I I I I I

•

(Klant 2)

+HOLE - positie klant 3 pos! tie klant 3

t

D -

EOF

Figuur 12: Opslag van vragenstructuur en klanteninformatie. Bij het ontwerp van bovenstaand fIleformaat is uitgegaan van de volgende ideeën: 1. Een CCD-fIle moet zo snel mogelijk toegankelijk zijn voor een agent. De agent heeft een inbellende klant anders al aan de lijn voordat hij de informatie op zijn scherm heeft. 2. De tijd die nodig is voor het opslaan van klanteninformatie lijkt minder kritisch omdat de agent dan de klant niet meer aan de lijn heeft, maar in praktijk kan een trage opslag er weer voor zorgen de aanvraag voor klanteninformatie door een andere agent wordt opgehouden. 3. Een CCD-fIle moet genoeg klanten kunnen bevatten. Om enig gevoel te krijgen voor het aantal klanten dat een file zou moeten kunnen bevatten is uitgegaan van een groep van maximaal 100 agents

36

die gedurende minimaal een halve dag met één CCD-file kunnen doorwerken. Het aantal klanten ligt dan maximaal rond de 8000. Hierbij is uitgegaan van een gemiddelde gespreklengte met de klant van 5 minuten (sommige klanten nemen niet eens op). Binnen de CCD-me zijn 3 blokken te onderscheiden namelijk: fileinformatie, vragenstructuur en klanteninformatie. In het fileinformatie-blok (de eerste rij in Figuur 12) wordt alle bestuingsinformatie voor de fileopslag bijgehouden, wals formaat-herkenning, het versienummer van de me, het aantal klanten, het aantal vragen en de positie van elk klantveld in de me. Het vragenstructuur-blok (tweede rij in Figuur 12) bevat alle informatie over de vragenstructuur (zie vorige paragraaf). Het klanteninformatieblok (laatste twee rijen in Figuur 12) ten slotte bevat alle klanteninformatie. Het klanteninformatie-blok is w ingericht dat klanteninformatie w snel mogelijk geladen en opgeslagen kan worden. Het laden kan snel omdat m.b.v. het klantnummer in het meinformatie-blok onmiddelijk de positie van de gewenste klanteninformatie kan worden gevonden. Voor w snel mogelijk opslaan is aan elke klantenveld een stukje lege ruimte toegevoegd ter grootte van de constante waarde HOLE. Een gewijzigd klanteninformatieveld dat niet groter is geworden dan de het oude veld plus de lege ruimte achter het oude veld kan nu worden opgeslagen zonder alle velden verder in de CCD-file eerst te moeten opschuiven. Een nadeel van het roevoegen van lege ruimte is natuurlijk dat de totale file iets groter wordt. Er dient dan ook een afweging te worden gemaakt tussen de grootte van de me en de snelheid waarmee klanteninformatie kan worden opgeslagen. Informatieblok 1 laat wat concrete gegevens over het CCD-me formaat zien. Voor de representatie van deze informatie wordt gebruik gemaakt van een hulpfunctie Inh(x, y) die een stukje CCD-me van y bytes en beginnend op positie x afbeeldt op een beschrijving van zijn inhoud. - Fileinformatie-blok: Inh(l, 12) = Bepaalde (ASCII) code waarmee het formaat van de file kan worden herkend Inh(13, 2) = Integerwaarde voor het versienummer van de CCD-file Inh(15, 4) = Longwaarde die aangeeft hoeveel klanten er in de file zijn opgeslagen Inh(19, 2) = Integerwaarde die het aantal vragen en dus het aantal informatievelden per klant aangeeft Inh(21, 4) = Longwaarde die de beginpositie aangeeft van het eerste klantveld. Dit is de eerste byte na het vragenstructuur-blok Inh(17+4*X, 4) = Beginpositie van klant X (long) Inh(21+4*Inh(15,4» = Positie laatste byte van de CCD-file - Vragenstructuur-blok: Inh(25+4*Inh(13, 2), 2) = Integerwaarde voor de lengte van de vraagtekst bij de eerste vraag. Inh(27+4*Inh(13,12), Inh(25+4*Inh(13, 2), 2» = Stringwaarde voor de eerste vraagtekst. - Klanteninformatie-blok: Inh (Inh (17+4*X, 4), 2) DEF:

= Lengte

eerste informatieveld van klant X

De functie Inh(x, y) geeft een beschrijvingvan de inhoud van het gedeelte van de CCD-file beginnend vanaf byte x en met een lengte van y bytes.

Informatieblok 1: CCD-fileformaat Voor het manipuleren van een CCD-file zijn de volgende procedures voor de programmeur beschikbaar: - ExportClientInfo (Export As FilePair) - FileExists (CCDFile As String) As Integer - FileVersion (CCDFile As String) As Integer - FormatCheck (FileName As String) As Integer - ImportClientInfo (Import As FilePair, ExtraClients As Long, FieldToInfoO As Integer) - LoadClientInfo (CCDFile As String, ClientInfoO As String, ClientNr As Long) - LoadQuestions (CCDFile As String, TempQuestionO As QuestionType

37

- MoveClients (CCDFile As String, ClientNr As Long, NumOfPos As Long) - NumOfClients (CCDFile As String) As Long - NumOfQuestions (CCDFile As String) As Integer - SaveClientInfo (CCDFile As String, ClientInfoO As String, ClientNr As Long) - SaveQuestions (CCDFile As String, TempQuestionO As QuestionType, Version As Integer, NumOfClients As Long)

38

3.6 Communicatie tussen de parallel lopende applicaties Deze paragraaf gaat dieper in op de remote procedure caUs voor de communicatie tussen de verschillende applicaties van de CaU Center Demo. Tijdens de realisatie van de software bleek dit namelijk veel uitzoekwerk met zich mee te brengen. Deze tekst is dan ook voornamelijk bedoeld voor afstudeerders/stagairs die zich in de toekomst verder met de demo gaan bezig houden. Het besturingsprogramma Windows levert twee standaards voor communicatie tussen applicaties, namelijk Dynamic Data Exchange (DDE) en Object Linking and Embedding (OLE) [Hae '93]. Uiteindelijk is gekozen voor het DDE-protocol voor de realisatie van de in paragraaf 4.1 geïntroduceerde remote procedure calls. OLE wordt namelijk (nog) niet volledig ondersteund door het gebruikte Visual Basic (versie 3.0). Het is in VB wel mogelijk om een OLE verbinding naar een niet-VB applicatie te maken, maar nog niet naar een andere VB-applicatie. Verder blijkt OLE niets anders te zijn dan een extra laag op het al wat oudere DDE [Mic '93] en zijn alle functies van OLE dus in principe ook op een lager niveau m.b.v. DDE te realiseren. DDE wordt volledig ondersteund door Visual Basic, voor Network DDE (Windows for Workgroups) zijn echter nog een aantal API functie-aanroepen nodig. Zie Bijlage B voor de realisatie van een NDDEverbinding in Visual Basic. Alle communicatie tussen de verschillende applicaties in het software model uit de vorige paragraaf geschiedt m.b.v. remote procedure calis. Hierbij neemt de applicatie die de procedure aanroep doet (de DDE-destination) het initiatief voor een verbinding naar de applicatie die de aangeroepen procedure bevat (de DDE-source). Vervolgens wordt d.m.v. een willekeurig aantal in- en ouput parameters informatie heen en weer wordt gezonden tusen de twee applicaties. Uit efficientie overwegingen en om de programmatuur zo overzichtelijk mogelijk te houden is gekozen voor een gelaagde opbouw van het RPC-mechanisme (zie Figuur IFiguur 13). Hierbij roept een remote procedure call in applicatie 1 eerst een procedure Procedure' in de applicatie zélf aan. Deze procedure geeft vervolgens de naam van de procedure en de input-parameters als een rij strings door aan een aantal uniforme communicatie-procedures. Deze procedures leggen vervolgens een DDE-verbinding naar de applicatie waarin de remote procedure zich bevindt, in dit geval applicatie 2. In deze applicatie wordt de rij strings na ontvangst weer vertaald naar een procedurenaam en de bijbehorende input-parameters, waarna de desbetreffende remote procedure wordt aangeroepen. Na uitvoering van de procedure worden de output-parameters als een nieuwe rij strings via de DDE-verbinding teruggestuurd naar applicatie 1. Na vertaling eindigt Procedure' en is de RPC uitgevoerd.

39

RPC

\

,, j1f ~ RPC

,:

,

I

" procle~re.

:

:

:

~

~

pro1ce:ure

.

DDcomm'lpr~edures I I I

I I

~

I vertaling, I : I :

~

.... ~~~~.~~.~~ ~.~~~.~~~ +.. ~~-------;~~--------+-t--.. ~ .~ strings

Applicat ie 1

.

vertalin~

t

:

I I

: .

Dscomml·pr~cedures

: : :

. ~

~

t

~~~~~.~~~.~~

:

Applicatie 2

Figuur 13: RPC m.b.v. DDE-communicatie. De communicatieprocedures ondersteunen twee communicatietypen, in dit verslag verder aangeduid als non-colliding RPC's en colliding RPC's. Over non-colliding RPC's wordt gesproken als een bepaalde DDE-source binnnen een applicatie altijd door hoogstens één DDE-destination van een andere applicatie tegelijk kan worden aangeroepen in alle andere gevallen is er sprake van colliding RPC's. Het nadeel van colliding RPC's is het feit dat er meer overhead, en dus tijd, nodig is om tegen te gaan dat meerdere destinations tegelijk een verbinding naar dezelfde source kunnen openen. In de gerealiseerde software bleek dit echter onvermijdelijk, omdat gekozen is voor slechts één DDE-source per applicatie die door alle remote procedures wordt gebruikt

A) NonoC ollinq RPC

BICoJltjhÇJ RPC

Figuur 14: De verschillende RPC typen.

Door ervoor te zorgen dat hoogstens één destination een verbinding naar een bepaalde source kan openen wordt vermeden dat dezelfde procedure in de DDE-source meerdere malen parallel kan lopen. Deze "serialization" vermijdt data-inconsistentie in de DDE-source. In Figuur 15 is schematisch weergegeven hoe de communicatie na een remote procedure call in de tijd verloopt. De linkerhelft van het plaatje laat zien wat gebeurt in de applicatie waarin de RPC wordt gestart en in de rechterhelft wordt aangegeven hoe de aangeroepen applicatie hierop reageert. Hierbij geven enkele pijlen aan dat dat de desbetreffende acties na elkaar gebeuren en geven dubbele pijlen aan dat bepaalde acties parallel worden uitgevoerd.

40

Remote procedure call

+ + +

Vertaling

Wacht tot kanaal vri j

Leq verblndlnqiaar Token-ltem

~

Vraao taken . - - - - - - - - - - - - : - -..- -

~~~~+, w_"_.

-

Verzend string-rij .---~--------....- -.....-

.

Behandel token-aanvraao

1

..- . -..--... Ontvano string-ri j

+

Vertalino

+ +

Remete Procedure

j

vertrnq

Ontvang strino-,[ij .-------------..:.·--······----····... Verzend strino-rij

+

~

Ready-sionaal-------------------·......-------···- ....-

+

:

+

....--.-... Geef taken vrij

Verbreek verbindinoen

DDE-Deslination

DDE-Source

Figuur 15: Functioneel schema RPC-communicatie. In paragraaf 4.1 wordt uitgelegd hoe het een en ander in Visual Basic is geYmplementeerd.

41

4. Implementatie Dit hoodstuk is vooral bedoeld voor diegene die met de gerealiseerde CaU Center software verder zal gaan. Het behandeld een aantal problemen die tijdens de implementatie van het ontwerp aan het licht zijn gekomen. Verder wordt de filestructuur van de CaU Center software uitgelegd.

4.1 Remote Procedure eaUs Om de realisatie van een RPC duidelijK te maken wordt uitgegaan van een eenvoudig voorbeeld. In deze paragraaf wordt hiervoor de realisatie van de RPC "GiveNextClient" (zie paragraaf 3.2.2) die door een Agent in de Call List kan worden aangeroepen verder uitgewerkt. De procedure zélf wordt hierbij buiten beschouwing gelaten. Er wordt aangenomen dat deze al in de can List is gerealiseerd. Aan Agent-zijde wordt de communicatielaag gebruikt via de procedure "RPC". Deze procedure is als volgt gedeclareerd: - RPC (ProcedureName As String, TokenPassing As Integer, InO As String, ObjectName As String, SourceComputer As String). Deze procedure verzendt de inputparamaters van de procedure ProcedureName via de stringrij InO over naar de applicatie ObjectName die zich bevindt op de computer SoureeComputer in het LAN. De outputparameters van de procedure bevinden zich na uitvoer van de procedure ''RPC'' in de stringrij OutO. Door de parameter "TokenPassing" op true te zetten wordt aangegeven dat gebruik moet worden gemaakt van een Colliding RPC. De vertaling van de RPC "GiveNextClient" naar de communicatieprocedure wordt gerealiseerd door een procedure met dezelfde naam (= Procedure' ). In Informatieblok 2 is te zien hoe de vertaling er voor "GiveNextClient" uitziet. Sub GiveNextClient (ClientNumber Aa Long, ApplicationName Aa String, NumberDone Aa Integer, NumOfClienta Aa Integer) Dim TempIn() Aa String ReDim TempIn(l) Call RPC("GiveNextClient", True, TempIn(), "Cliat", CLISTCOMPUTER) ApplicationName = Out(l) clientNumber = Val(Out(2» NumberDone = Val(Out(3» NumOfclienta = Val(Out(4» End Sub

Informatieblok 2: Vertaalslag binnen destination-applicatie Om de communicatie goed te laten verlopen moet ervoor gezorgd worden dat de stringrij voor de inputparamters en de stringrij voor de output-parameters altijd bestaat uit minstens één string. Aangezien "GiveNextClient" alleen output-parameters heeft wordt de stringrij voor de input-parameters hier gedefmieerd als een stringrij bestaande uit één lege string. Bij de Call List applicatie zorgt de "RPC"-procedure voor een aanroep van de procedure "RPCHandler". Deze procedure roept afhankelijk van de waarde van ProcedureName in "RPC" een bepaalde procedure aan. Deze procedure levert afhankelijk van de overgezonden input-parameters bepaalde output-parameters die naar de aanroepende applicatie worden teruggezonden. In Informatieblok 3 is te zien hoe in het geval van de RPC "GiveNextClient" de bijbehorende procedure in Call List wordt aangeroepen en hoe de vertaling van parameters naar stringrijen er in dit geval uitziet.

42

Sub Dim Dim Dim Dim

RPCHandler (ByVal ProcedureName As String, In() As String, Out() As String) ApplicationName As String C1ientNumber As Long NumberDone As Integer NumOfClients As Integer ReDim Out(O) Select Case ProcedureName Case "GiveNextClient" Call GiveNextClient(ClientNumber, ApplicationName, NumberDone, NumOfClients) ReDim Out(4) Out (1) = ApplicationName Out (2) Str$(ClientNumber) Out(3) = Str$(NumberDone) Out(4) Str$(NumOfClients) End Select If UBound(Out)

o Then

ReDim Out (1)

End Sub

Informatieblok 3: Vertaalslag binnen source-applicatie Informatieblok 4 laat ten slotte zien hoe de daadwerkelijk communicatie over de DOE-link er uit ziet nadat een Agent-applicatie op de computer "CC-AGENT!" de RPC "GiveNextClient" uitvoert. 1. Token: 2. Token: 3. Info: 4. Info: 5. Info: 6. Info: 7. Info: 8. Info: 9. Info: 10.Info: 11.Info: 12. Info: 13.Info: 14.Info: 15.Info: 16.Info: 17.Info: 18.Token:

CC-AGENT1 ACCCC-AGENTI PGiveNextClient Z SND Xabonnementen ACK NEXT Y 56 ACK NEXT X 33 ACK NEXT .Z 100 RDY FREE

(A) (DH) (A) (A) (DH) (DH) (A) (DH) (DH) (A) (DH) (DH) (A) (DH) (DH) (A) (DH) (DH)

Informatieblok 4: Voorbeeld van communicatie voor de RPC "GiveNextClient" De aanroep GiveNextClient (ClientNumber As Long, ApplicationName As String, NumberDone As Integer, NumOfClients As Integer) geeft in dit voorbeeld het volgende resultaat: - ApplicationName ="Abonnementen" - ClientNumber 56 - NumberDone 33 - NumOfClients 100

= = =

Om een idee te geven van de werking van het gebruikte communicatieprotocol worden enkele punten uit het voorbeeld in Informatieblok 4 wat hier verder uitgewerkt: 1. De Agent-applicatie op "CC-AGENT!" ziet dat de DOE-link vrij is en vraagt toestemming om een verbinding naar de Call List te mogen opzetten door zijn (unieke) computernaam te verzenden. 2. Er is geen collission opgetreden met RPC's van andere applicaties en de CaU List geeft aan dat hij de Agent accepteerd door een prefix "ACC" voor de computernaam te zetten. 3. De Agent-applicatie verzendt de procedurenaam van de RPC. De unieke prefix "P" zorgt voor herkenning door de CaU List 4. De Agent verzendt de eerste string van de inputparameter-stringrij. Omdat deze in dit geval slechts bestaat uit één lege string wordt d.m.v. de prefix "Z" aangegeven dat dit ook meteen de laatste string is.

43

5. Om deadlock tegen te gaan wordt nu eerst het bericht "SND" op het kanaal gezet en wordt de DDElink vervolgens door de CaB List vrijgegeven. Dit "SND"·bericht zorgt er daarna voor dat de procedure "GiveNextClient" in de CaU List wordt aangeroepen zodat de outputparameter-stringrij kan worden bepaald 6. De eerste string van de outputparameter-stringrij wordt teruggezonden. De strings van deze stringrij worden voorafgegaan door een alternerende prefix ("X" of "Y"). Op deze manier wordt ervoor gezorgd dat de Agent de strings slechts één keer leest. 7. De Agent geeft een acknowledge-signaal om aan te geven dat de volgende string kan worden verzonden. 8. De DOE-link wordt om deadlock tegen te gaan weer eerst door de CaB List vrijgegeven. Het "NEXT"· bericht zorgt ervoor dat daarna de volgende string wordt verzonden. 15. De "Z"-prefix geeft aan dat dit de laatste string van de outputstringrij is. 16. De Agent geeft aan dat hij alle parameters heeft ontvangen die hij nodig had. 18. De Call List kan nu weer nieuwe RPC's gaan afhandelen.

44

4.2 Telephony Server in VBVoice VBVoice is bedoeld voor een zo snel mogelijke implementatie van CAT-applicaties. Voor het programmeren in VBVoice is daarvoor uitgegaan van een graftsche user-interface. Hierbij kan m.b.v. een aantal bouwstenen, genaamd Telephony Controls, een applicatie worden gerealiseerd.

4.2.1 Outbound Call Center In Figuur 16 is het programma voor een outbound Telephony Server weergegeven. Het programma begint hierbij in een Phone-Contral (er wordt een verbinding op een bepaalde lijn opgebouwd) en eindigt in een OnHook-Control (verbreken van de verbinding).

Figuur 16: Flow of control voor outbound Telephony Server De realisatie van de Telephony Server in VBVoice leverde veel onverwachte problemen op. 'hl bleken niet alle controls probleemloos meerdere lijnen te kunnen afhandelen. Een Phone-Control breekt bijvoorbeeld een bestaande verbinding af op het moment dat je een nieuwe verbinding met dezelfde contral wilt opzetten. In bovenstaand programma is dit opgelost door elke voicelijn een aparte control te geven. Dit is echter absoluut geen mooie oplossing; het programma past zich nu niet meer automatisch aan op het aantal lijnen en bij een groot aantal lijnen gaat het al helemaal fout. Een tweede probleem was het manipuleren van de programmaloop van het VBVoice-programma vanuit VisuaI Basic. Op het moment dat een uitgaande verbinding is opgezet moet het programma namelijk wachten op een bericht van de desbetreffende Agent voordat hij de verbinding weer mag afbreken. Dit is gerealiseerd door in de OnHook-Control simpelweg een wachtlus in te bouwen. Om onbekende redenen gaat ook dit fout op het moment dat meerdere lijnen van de control gebruik gaan maken. Als gevolg hiervan is ook hier gekozen voor een aparte control voor elke lijn, met alle eerder genoemde nadelen van dien.

45

4.2.2 Inbound CaU Center Figuur 17 laat het gedeelte van de Telephony Server zien dat de binnenkomende gesprekken afhandelt.

Figuur 17: Flow of control inbound Telephony Server De opbouw van dit programma spreekt eigenlijk voor zich. De vier timers rechtsonder in het window zorgen er voor dat de verbinding na een bepaalde tijd wordt verbroken als de klant niet door de Inbound Server naar een agent wordt doorverbonden.

46

4.3 eaU center filestructuur In deze praragraaf worden alle ftles die voor het Call Center Demo nodig zijn opgenoemd. De files zijn geordend volgens de verschillende objecten van het Call Center. Agent: Directory: c:'<:c\agent Source-files: ddcom.bas, dscom.bas, main.bas, rpc.bas, agent.frm, dd.frm, dsJrm, agent.mak exe-file: agent.exe Call List: Directory: c:X:c'<:list Source-files: ddcom.bas, dscom.bas, main.bas, rpc.bas, chapp.frm, clistJrm, dd.frm, ds.frm, msgJrm, clistJrx, msgJrx, clisLmak clisLexe Exe-ftle: Data Handler: Directory: c:'<:c\dhandler Source-files: ddcom.bas, dscom.bas, ediLbas, fileproc.bas, main.bas, rpc.bas, addappJrm, addapp2Jrm, change.frm, chappJrm, chapp2.frm, chdirJrm, dhandler.frm, ddJrm, dsJrm, import.frm, import2.frm, import3Jrm, insert.frm, moveJrm, qeditor.frm, qframeJrm, remapp.frm, dhandlerJrx, dhandler.mak Exe-ftle: dhandler.exe Klanteninfo: kanten.txt, abon.ccd Inbound Server: Directory: c:'<:c\inbserv Source-files: ddcom.bas, dscom.bas, main.bas, rpc.bas, addappJrm, dd.frm, dsJrm, inbserv.frm, remappJrm, inbserv.mak Exe-ftle: inbserv.exe Telephony Server: Directory: c:'<:c\telserv Source-files: ddcom.bas, dlgc_dll.bas, dscom.bas, main.bas, rpc.bas, telprocs.bas, vbvoice.bas, dd.frm, ds.frm, inbound.frm, outbound.frm, telservJrm, telserv.mak Exe-ftle: telserv.exe Overig: Initialisatie-file: ccdemo.ini (Windows-directory) Communicatie:

ddcom.bas (communicatieprocedures bij NDDE-destination) dscom.bas, (communicatieprocedures bij NDDE-source) rpc.bas (RPC-procedures source) dd.frm (communicatiewindow NDDE-destination) dsJrm (communicatiewindow NDDE-source)

47

5. Resultaten In dit hoofdstuk wordt bekeken welk gedeelte van de CaU Center demonstratie gereed is en wat eventueel aan de gerealiseerde software zou kunnen worden toegevoegd. Verder worden de twee belangrijkste bottlenecks in de huidige CaU Center demonstratie behandeld, namelijk de snelheid van de RPC's en het gebruik van analoge signalering door de Telephony Server. Beiden zijn de oorzaak van relatief grote vertragingen in de Call Center demonstratie en zijn voor verbetering vatbaar.

5.1 Gerealiseerde software Met behulp van de gerealiseerde software kan op eenvoudige wijze een demonstratie van een outbound en inbound LAN Call Center worden gegeven. Hierbij kan tevens de werking van het client-server principe worden aangetoond. De demonstratie maakt aannemelijk dat LAN Call Centers, na enkele verbeteringen, een interessante optie zijn voor de realisatie van een custom-made Call Center. Het Call Center kan nog op een aantal manieren worden uitgebreid. Zo moeten bijvoorbeeld de IVRAgents voor het afhandelen van klanten als alle agents bezet zijn nog worden gerealiseerd en worden nog niet alle gebruikersfouten door de software opgevangen. Als een bepaalde Agent-applicatie bijvoorbeeld wordt gestopt zonder dat hij de kans heeft om zich af te melden bij de verschillende Call Center servers ontstaan op het moment nog een DOE-errors omdat hierdoor verbindingen naar niet bestaande source applicaties kunnen worden gelegd. Verder moet de weergave van (actuele) management informatie nog verder worden uitgewerkt. Gedacht is aan een aparte applicatie "Statistics" die via RPC-berichten of door het lezen van ccd-fIles vanaf een willekeurige computer in het LAN informatie over de voortgang van het Call Center kan verzamelen.

5.2 Bottleneck 1: Communicatiesnelheid De realisatie van het RPC-mechanisme in het Call Center m.b.v. DOE in Visual Basic blijkt een sterk vertragende factor te zijn. Veel RPC's zijn secondenlang bezig voordat ze zijn uitgevoerd. Vooral als meerdere RPC's tegelijk worden uitgevoerd kan de vertraging erg groot worden. Omdat we hier slechts te maken hebben met een demonstratie met een beperkt aantal agents is deze traagheid op het moment niet echt een probleem. Op het moment dat het LAN meer met RPC's gaat worden belast, of het aantal agents wordt uitgebreid, moet de communicatiesnelheid echter eerst worden verhoogd. De grootste reden van de vertragingen is het feit dat het communicatieprotocol op het moment gewoon in Visual Basic is geïmplementeerd. In de toekomst zou het beter zijn als de communicatie m.b.V. een meer efficiente programmeertaal, zoals C++, zou worden gemaakt. Eventueel zou kunnen worden uitgezocht of er al Visual Basic controls bestaan die de nodige functionaliteit kunnen leveren.

5.3 Bottleneck 2: Analoge signalering Een tweede vertragende factor in het Call Center is het feit dat de Telephony Server gebruik moet maken van analoge signalering. Een bekend probleem is hierbij dat het moeilijk is om te detecteren wanneer aan de andere kant van de lijn de hoorn van de haak wordt genomen.

48

De gerealiseerde Telephony Server detecteert het opnemen van de hoorn door te bepalen of het signaal

dat aangeeft dat de telefoon aan de andere kant overgaat is opgehouden. Dit wordt gedaan door iedere keer als het signaal wordt gedetecteerd een teller te starten. Als het signaal na een bepaalde tijd niet meer terugkomt wordt aangenomen dat de hoorn is opgenomen. Het is duidelijk dat m.b.V. deze methode niet direct op het opnemen van de hoorn kan worden gereageerd. Door gebruik te maken van ISDN.lijnen kunnen dit soort problemen in de toekomst worden opgelost, want bij ISDN worden deze events expliciet (via het D-kanaal) aan de server doorgegeven. Verder is nog verdere optimalisatie mogelijk van de geluidherkennings soft- en hardware op de telefoonkaart

49

6.

Conclusies

Er is aangetoond dat m.b.v. moderne middelen eenvoudig en snel een volledig aan de wensen van de klant aangepast CaU Center kan worden gerealiseerd. Hiervoor is een specifiek outbound en inbound LAN CaU Center geïmplementeerd. Verder is een platform gerealiseerd waarop verder kan worden gebouwd.

Door gebruik te maken van een modulaire opbouw is de gerealiseerde software zo flexibel mogelijk gehouden en worden meerdere configuraties ondersteund. Zo is het mogelijk om maximaal één outbound en acht inbound applicaties prallel te laten lopen. Verder kan de software eenvoudiger worden uitgebreid door het toevoegen van applicaties of extra modules aan bestaande applicaties. Met behulp van een hoog niveau programmeertaal als VisuaI Basic was het mogelijk binnen drie maanden een redelijk werkend CaU Center te realiseren. De snelheid van de Call Center blijkt echter nog door een tweetal bottlenecks te worden beperkt: De communicatiesnelheid van het RPC-mechanisme in het Call Center en het gebruik van analoge signalering voor de realisatie van de telefonie-functies. De eerste bottleneck kan worden opgelost door het protocol voor communicatie tussen de parallel lopende applicaties, dat nu in VisuaI Basic is geprogrammeerd, effici~nter te implementeren. Hiervoor kan gebruik worden gemaakt van een lager niveau programmeertaal of door gebruik te maken van eventueel al bestaande VB-controls voor RPC-communicatie. De tweede bottleneck wordt vooral veroorzaakt door het feit dat het m.b.V. analoge signalering moeilijk is om te detecteren wanneer aan de andere kant van een telefoonlijn de hoorn wordt opgenomen. Dit probleem kan worden opgelost door gebruik te maken van ISDN-lijnen of d.m.v. meer geavanceerde CSTA-koppeling met de PBX,

50

7.

Opmerkingen en aanbevelingen

Door gebruik te maken van ISDN-lijnen naar de telephony server wordt er op de eerste plaats voor gerzorgd dat de signalering wordt verbeterd (zie paragraaf 5.3). Op de tweede plaats maakt ISDN echter ook thuiswerk door de agents mogelijk. De RPC's die nu over het ethemet lopen voor de communicatie van het Agent programma met de rest van het Call Center kunnen via een ISDN-kanaal worden verstuurd. De ethemet-verbinding kan eenvoudig worden vertaald naar een ISDN-verbinding. De programmeertaal "Visual Basic" is, na toevoeging van speciale "Call Center Controls", goed bruikbaar voor snelle realisatie van een Call Center Solution. De extra controls zorgen hierbij voor de interface van Visual Basic met een lager niveau taal (zoals C++) waarin tijdkritische zaken zaols RPC's efficienter geprogrammeerd kunnen worden. Voor het bestuderen van Visual Basic wordt aangeraden om eerst de structuur van de taal uit te zoeken en vervolgens gebruik te maken van de programmer's guide en de helpfiles. Door nu een aantal kleine programmaatjes te schrijven wordt het snelst duidelijk hoe je met Visual Basic kunt programmeren. De opbouw van de Telephony Server is bepaald door de (beperkingen van) de programmeeromgeving VBVoice. In de nabije toekomst zal gebruik worden gemaakt van de NoveU / AT&T Telephony Server. Deze server handelt de telefoonfuncties beter af dan de huidige combinatie van Dialogic-kaart met VBVoice. De Telephony Server software in het Call Center zal door gebruik van de NoveU Server worden verdeeld in een onderdeel dat zorgt voor de interface met de server en een gedeelte dat bestaat uit de voor het Call Center nodige extensies zoals bijvoorbeeld IVR.

51

Literatuuropgave Hae '93:

Filip D'Haenens, "Visual basic for windows 3.0, professional edition", PCM november 1993, blz. 131 - 134.

Mic '93:

Microsoft Corporation, Microsoft Development Library, "Dynamic Data Exchange Management Library", 1993 (Op CD-ROM)

Schr '94A:

Ir. M.W. van der Schrier e.a., "Internationale ontwikkelingen met betrekking tot CallCenters", juli 1994, rapport P'IT Research, RA-94-683.

Schr '94B:

Portfolio Call Centers

Man '92:

Ir. G. Maneschijn e.a. "Computer Aided Telecommunications (CAT) in een bedrijfsomgeving", september '92, rapport P'IT Research, TI-RA-92-1335

52

Lijst van gebruikte afkortingen ACD IVR

NSC PBX

LAN AMX EXP

RPC ccd-file ISDN DDE

Automatic CaU Distributor Interactive Voice Response Network and Service Control Private Branch Exchange Local Area Network Analog Multiplexer Geêxporteerd fileformaat Remote Procedure Call Call Center Demo fIle Integrated Services Digital Network Dynamie Data Exchange

53

Bijlage A: Gebruiksaanwijzing CaU Center software In deze tekst wordt uitgelegd hoe m.b.v. de opstelling "LAN Call Center" eenvoudig een demonstratie kan worden gegeven van een outbound e%f inbound CaU Center. Vervolgens wordt het CaU Center vanuit 3 gezichtspunten wat verder bekeken, namelijk vanuit de manager, de agent en de klant. Voor een inleiding m.b.t het begrip CaU Centers en het doel van deze proefopstelling wordt verwezen naar hoofdstuk I van dit rapport.

CaU Center configuratie Voor een juiste werking van de CaU Center software is de volgende configuratie noodzakelijk: • Een PC-netwerk bestaande uit systemen met het besturingsprogramma Windows For Workgroups. • Eén PC binnen bovenstaand netwerk die m.b.v. de D-41E insteekkaart van Dialogic dienst kan doen als telefoonserver. • Het programma "telserv.exe" op de telefoonserver-PC. • Het programma "dhandler.exe" op één van de systemen binnen het netwerk • Het programma "agent.exe" op elke agent-PC binnen het netwerk • Voor naar buiten bellen: Het programma "clist.exe" (CaU List) op één van de systemen binnen het netwerk. • Voor naar binnen bellen: Het programma "inbserv.exe" (Inbound Server) op één van de systemen binnen het netwerk.

Opstarten van een CaU Center demonstratie Het opstarten van het CaU Center geschiedt normaal gesproken door elk van de eerder genoemde YBapplicaties afzonderlijk op te starten. Als enige eis wordt hier gesteld dat de applicatie "DataHandler" als eerste wordt opgestart.

DaiaHandier

e

CaIIlist

B:H'

.~

InIlow1d Server

Call Center SlartUp

:=

m

~

'WWI

~ Agent

Figuur 18: De Call Center program group. Indien alle YB-applicaties zich op de telefoonserver-PC bevinden kan voor een snelle start ook gebruik worden gemaakt van het programma "CalI Center StartUp" (zie Figuur 18). Hierbij wordt eerst gevraagd welke CaU Center configuratie (outbound e%f inbound) gewenst is en vervolgens wordt er automatisch voor gezorgd dat de voor deze configuratie nodige applicaties op de juiste manier worden opgestart.

54

Voorbeeld demonstratie van een in· en outbound CaU Center Om de demonstratie zo vlot mogelijk te laten verlopen is er voor gezorgd dat alle instellingen die normaal gesproken door de manager van het Call Center worden gedaan niet steeds opnieuw hoeven te worden uitgevoerd. Al deze instellingen worden namelijk bewaard in een speciale initialisatie-file genaamd ccdemo.ini. Let er echter bij het geven van een demonstratie altijd op dat alles goed is ingesteld (zie "contrOle-punten'').

Case 1: de proefabonnementen (outbound) ContrOle-punten: - De actieve applicatienaam in Call List staat op "Abonnementen" - De Call List bevat een aantal nog niet gebelde klanten - Het toestelnummer van elke Agent is goed ingesteld Een bedrijf heeft een reeks proefnummers van zijn tijdschriften verzonden naar potentiele abonnees. Nu gaat het aan de hand van het aangelegde bestand de personen opbellen die een proefnummer hebben ontvangen. Deze personen wordt gevraagd of zij een beslissing hebben genomen: - willen zij een abonnement nemen? - willen zij nog een proefnummer voordat zij beslissen? - enzovoorts. De verzameling klanten die gebeld moet worden worden bepaald door een bellijst in de applicatie "Call List" (zie Figuur 19). De klanten in deze lijst worden gespecificeerd door de actieve applicatienaam en het opgegeven selectiecriterium (ClientSelection). De lijst wordt geïnitialiseerd m.b.v. de "Get Clients"button.

~t

~etUp

tlelp

Slobl

Clientlabel:

L:.:IN~aam:==-"

Steen van def Fichou

-----'111

Slob ClientSelec1ion: - - - - - ,

Deelen VosJensans

TaIh

L-I\tI_III>IIPfa----'-_ats:_"

--'111

@. 0> 0< Value:

L::lde:.:.:n..:.,:HaaR.:=.

N......... ol eh....: CIienI. done:

I!=::::J L:::J

-----'11I

:::""

-~ I~W~ I ~,"' .

Figuur 19: Instellingen Call List Elke agent kan nu een klant uit de lijst opvragen door de button "Volgende Klant" aan te klikken. De opgehaalde klant wordt vervolgens in de bellijst tussen haakjes gezet. De actieve applicatienaam wordt nu bovenin het agent-window zichtbaar. Vervolgens wordt de bij de applicatie behorende vragenstructuur en de klanteninformatie bij de te bellen klant opgehaald. Het agent-window ziet er nu ongeveer uit zoals in Figuur 20. De agent staat nu klaar om de klant te gaan bellen.

55

m finde

I!$IÇf

Abonnementen

Instellingen lielp

<) «Uitleg» Heeft U onze Ploefebonnementen ontvangen? (.la) Welk lijdachrift vond U yoolal interenant? Wat yinlft U yan de prijzen? Wilt U zich op een tiidschrift abonnelen? (.la) Welk tiicbchrift kiest U? (Kantklossen) W~~neel wilt U uw eerde num_ onty '.-_ _

lil

----laatde Ylaag---

KlantNummer:

1.1111

IJ- Jamen Teleloon:

1B-070.1234561 WoonpIaaIs:

lden Haag Opaaerkingen:

Figuur 20: Het agent window Indien het toestelnummer van de agent (in te stellen via het menu-item "Instellingen") is ingesteld op het toestel dat bij die PC hoort dan kan de klant gebeld worden door simpelweg de button "Bel Klant" aan te klikken. De Telephony Server belt nu eerst het agent-toestel (let er op dat de hoorn op de haak ligt). Nadat de agent heeft opgenomen wordt de klant gebeld. Alle telefoon-events die optreden vanaf het moment dat de verbinding wordt opgezet tot en met het moment waarop de agent de verbinding verbreekt worden weergegeven in de statusbar van het agent-window. Het opzetten van een verbinding met de klant gaat op het moment nog erg langzaam omdat van analoge signalering gebruik wordt gemaakt. In de nabije toekomst zal hier nog verbetering in komen (eventueel door gebruik te maken van ISDN-verbindingen). Als de agent de klant uiteindelijk aan de lijn heeft maakt hij gebruik van de op het agent-window zichtbare vragenlijst om de gewenste klanteninformatie te krijgen. Hierbij selecteerd de agent in het vragen-veld linksboven in het windoween bepaalde vraag. Indien er al informatie bij deze vraag in het Call Center bestand aanwezig was komt dit automatisch in het antwoord-veld linksonder in het window te voorschijn. De kIanteninformatie kan nu door de agent worden aangepast. De vragenlijst kan twee soorten vragen bevatten, namelijk informatievragen en selectievragen. Als de agent een informatievraag heeft geactiveerd kan een willekeurig antwoord in het antwoord-veld worden ingetypt. Bij een selectievraag kan de agent echter alleen kiezen uit een aantal mogelijke opties (zie Figuur 20). Door te dubbel-klikken op een bepaalde optie kunnen een aantal nieuwe vragen zichtbaar worden. Op deze manier wordt de lijst van aan de klant te stellen vragen dynamisch aangepast aan de antwoorden van de klant. Als alle relevante klanteninformatie door de agent is ingevoerd kan de agent de nieuwe informatie laten opslaan in het Call Center bestand door de "Opslaan"-button aan te klikken en de verbinding met de klant te verbreken d.m.v. het "Leg Neer"-button. De agent kan nu op dezelfde wijze een nieuwe klant gaan behandelen.

56

De groep van agents werkt op deze wijze het bestand af. De resultaat-file wordt (evt. electronisch) aan de opdrachtgever van het Call Center overgedragen. Een vergelijkbaar scenario is mogelijk met bijvoorbeeld: - voorwerpen die pas aangeschaft zijn. - voorwerpen waarvan de leentermijn dreigt te verstrijken. - contracten die (binnenkort) verlengd moeten worden.

Case 2: het gasbedrijf (inbound) Controle-punten: - In de Inbound Server zijn de applicaties "Technische Vragen", "Commerci~le Vragen" en "Algemene Informatie" actief - Het toestelnummer van elke Agent is goed ingesteld We hebben hier te maken met de storingsdienst van een gasbedrijf.: Een verzameling klanten laat hun gastoestellen door het gasbedrijf onderhouden. Het bedrijf heeft één toegangsnummer voor alle storingsmeldingen. De klanten worden daar te woord gestaan door het Call Center. Het inbound Call Center is volledig gebaseerd op het outbound Call Center. Elke agent kan aangeven dat hij naast zijn outbound activiteiten ook nog beschikbaar is voor bepaalde inbound applicaties. -

Bescnikballrfu:ill

'

Geef uw beschikb-"lIid op: .~~!.'2~!!'.!?!!!!'_._!!!;.~

ea.m.rc~.1. :lt

.

.

_

Yragaa

U . . . . IUI Iafo:nYkt.::la

Figuur 21: Instellen beschikbaarheid voor inbound applicaties Onder het menu-item "Instellingen" van het agent-window is hiervoor de beschikbaarheid van de agent in te stellen (zie Figuur 21). In bovenstaand "beschikbaarheids"-window worden real-time alle actieve inbound applicaties op het LAN weergegeven. Een agent kan zich voor een bepaalde applicatie opgeven door op de bijbehorende applicatienaam te klikken (er komt een kruisje voor de naam). Door op de "OK"button te klikken worden de (aangepaste) instellingen over het netwerk naar de Inbound Server gestuurd (zie Figuur 22).

~ Exit

Inbound Servcr SetUp Options Help

List ol available agentl:

Figuur 22: Inbound Server

57

§lC[

Voor de demonstratie kan de Inbound Server (het programma dat een inbellende klant naar een bepaalde agent routeert) laten zien welke agents zich voor bepaalde inbound applicaties hebben opgegeven. Let op: de beschikbaarheid van elke agent wordt niet automatisch door het Call Center ingesteld en dient dus na het opstarten van een agent-programma steeds opnieuw te worden aangegeven. Als nu een klant op het centrale storingsnummer inbelt, wordt eerst middels een gesproken menu gevraagd waarvoor de klant belt. De klant moet hiervoor m.b.v. de druktoetsen van zijn telefoon kiezen uit de op dat moment actieve inbound applicaties. Daarna wordt, omdat er voor de demonstratie van uit wordt gegaan dat de klant al een onderhoudscontract heeft, het klantnummer gevraagd. De Inbound Server vraagt nu aan alle agents die zich voor het door de klant gekozen item beschikbaar hebben gesteld of zij de klant willen behandelen. Indien een klant bijvoorbeeld ''Technische Vragen" kiest en als klantnummer "1313" opgeeft zal een geschikte agent via een klein windowtje rechtsonder op zijn scherm, zoals in Figuur 23 te zien is, gevraagd worden om de klant te accepteren. Als de agent nu de "Negeer"-button aanklikt of een tiental seconden niet reageert verdwijnt dit window weer. Geeft de agent echter aan de klant te accepteren dan wordt dit doorgegeven aan de Inbound Server. Deze wijst de klant nu toe aan de agent die als eerste heeft aangegeven de klant te willen accepteren. No A llcallon LOllded I;.lnde

Instellingen

tlelp InfottelD 0:

InfotlelD 1:

InfottelD 3:

, Figuur 23: Klant 1313 heeft technische vragen

Als de agent op dit moment geen andere klant aan het behandelen is wordt de klant onmiddellijk doorverbonden naar het agent-toestel. Tegelijkertijd wordt automatisch de juiste vragenlijst en klanteninformatie uit het Call Center bestand gehaald en op het agent-window getoond. In de meeste gevallen zal de agent op het moment dat hij de klant krijgt toegewezen nog bezig zijn met een andere klant (bijvoorbeeld een klant uit case 1). De klanteninformatie komt dan pas op het scherm nadat de agent de informatie van de klant waarmee hij bezig was heeft opgeslagen. De klant wordt vervolgens onmiddellijk nadat de agent de hoorn heeft neergelegd doorverbonden.

58

Nu de agent de klant aan de lijn heeft bepaalt hij w goed mogelijk wat de aard van de storing is. Hierbij kan de applicatie behulpzaam zijn, aangezien bekend is welke toestellen de klant in huis heeft. Per toestel kan een aantal vragen worden gesteld (en algemeen over de aansluiting). Op basis van deze informatie krijgt achteraf een reperateur de opdracht bij de klant langs te gaan.

59

Het outbound CaU Center Met het outbound CaU Center wordt het gedeelte van de software bedoeld dat ervoor zorgt dat een groep agents zo efficit!nt mogelijk een bepaalde groep klanten kan bellen. Een outbound CaU Center kan behulpzaam zijn bij het beheer van relaties, het inzamelen van geld voor goede doelen, marktonderzoeken of bij telefonische verkoop (telemarketing).

De manager De manager van het CaU Center bepaalt welke klanten er gebeld worden. Aan de hand van het Data Handler-venster kan de manager zien wat de voortgang is van het CaU Center: hoeveel klanten zijn er gebeld. Verder maakt hij het vragenscenario dat de agents gebruiken tijdens hun gesprek met de klant. In de CaU Center demonstratie software wordt hiervoor gebruik gemaakt van speciale ccd-files. Een ccd-file bestaat uit een bepaalde vragenstructuur aangevuld met een willekeurig aantal klanten. Het aanmaken en wijzigen van deze ccd-files wordt nu verder behandeld.

Aanmaken van een nieuwe ccd-file: Elke ccd-file wordt gekarakteriseerd door een bepaalde vragenstructuur. Voor het aanmaken van een ccdfile dient dan ook eerst een vragenstructuur te worden samengesteld. Het samenstellen van een voor een bepaalde outbound applicatie toepasselijke vragenstructuur geschiedt met behulp van de Question Editor. Deze editor wordt opgestart door in het status-window van de Data HandIer (zie Figuur 27) onder het menu-item "File" de optie "Edit CustomerFile" te kiezen. Nadat de Question Editor is opgestart wordt een initit!le vragenlijst bestaande uit een zestal informatievragen zichtbaar (zie paragraaf 3.4 van dit rapport voor de termen "informatievraag" en "selectievraag"). Verder geeft de tekst "NONAME.CCD" boven in het windowaan dat er nog geen ccdfile geopend of gesaved is. Als voorbeeld wordt nu de vragenstructuur van case 1, de proefabonnementen, genomen (zie hiervoor Figuur 24). Alle vragen die niet gevolgd worden door een pijl (-» zijn informatievragen. Deze vragen hebben maximaal één volgende vraag. Als een informatievraag, zoals bijvoorbeeld vraag 18, een laatste vraag is dan wordt dit in de Question Editor weergegeven m.b.v. een rij streepjes onder de vraag Indien een vraag echter gevolgd wordt door een andere vraag of gevolgd wordt door een verwijzing naar een vraag (zie vraag 16) dan is deze vraag de volgende vraag.

60

:,',: :;1: ~~

Elle fdit ïlew tlelp

2: K1antN-.: 3: Naa..: 4: TeIeIoon: 5: \\Ioonplaah: 6: Opmerkingen:

7: «Voordelen» 8: «Uitleg) 9: Heefl U ...ze proefabonnementen ontvengen?-) -) Ans(9)- Ja

1D: \\IOlIk tijdsçlvifl v...d U vooral inl.r••aant? 11: 'Wal v.... U van de prijzen? 12: W''' U zich op een lijdachrifl abonneren?-)

File1nfo--------,

Veraion:

~

Number ol cuao_r.

~16====::::

NUllbe, ol queationa:

122

-) Ana(9)- Nee 19: Will U z. almag ontvangen? 20: Benl U verhuist? .)

-) AnaI2O)- Ja 21: Nieuwe ""'••: -) Ana(2D)- Nee

22: «Controleer klento,"""vena»

Figuur 24: De Question Editor

De eerste zes infonnatievragen hebben een iets andere betekenis dan alle anderen. Vraag 1 wordt bijvoorbeeld niet zichtbaar op het agent-window en kan worden gebruikt als besturingsinfonnatie voor het CaU Center. Door een kleine aanpassing in het Agent-programma kan er bijvoorbeeld voor worden gezorgd dat automatisch wordt opgeslagen of, en zo ja, wanneer een bepaalde klant is gebeld. Op deze manier wordt het mogelijk om klanten die niet bereikbaar waren of op een ander tijdstip teruggebeld wilden worden later door het CaU Center opnieuw te laten behandelen. Vraag 2 t/m 6 komen uiteindelijk op het agent-window in een apart kader te staan. Ze worden gebruikt om vaste infonnatie over de klant weer te geven. Voor een goede werking van het gerealiseerde Agentprogramma dienen deze vragen infonnatievragen te zijn en moet vraag 4 altijd het telefoonnummer van de klant bevatten.

De selectievragen worden weergegeven door een pijl achter de vraag. Verder worden de volgende vragen per optie weergegeven door de commentaar-regels "-> Ans(Vraagnummer) = Label". Selectievragen beeindigen een rij van opeenvolgende infonnatievragen en worden daarom gevolgd door een rij streepjes. Met behulp van de edit-functies onder het menu-item "Edit" is het mogelijk vragen toe te voegen, te verwijderen, te verplaatsen of te veranderen. In Figuur 25 is het invoer-window van de functie "Change Question" te zien. Hierin komen alle parameters voor waarmee een vraag kan worden gespecificeerd.

61

Cnange Oueslion

th_ge Qunlion:~J Ouellion Tal:

flïï~elt~lijd~-~lc~lu~ifl~ki~·e"=U~1~=~

o In/cO......... o Donald Duclt o KanlkIooaen o EIetIUIlI

OM_Jlilieu

o Kijk

@> SeleclionOueotion

o Andero.•. o o o o ~

Label: r=ID-ona/d-:-:":D=-uc-:"k-------,1 ~

Nell Queotion:

114: W........e. wilt U uw eerde Im

Figuur 25: De edit-functie "Change Question" Het wordt aangeraden om selectievragen eerste als informatievraag in te voeren. Selectievragen hebben namelijk een grote invloed op de structuur van de vragenlijst en kunnen daardoor de nummering van de vragen ingrijpend veranderen. Hierdoor wordt het geheel snel onoverzichtelijk. Op het moment dat alle volgende vragen van de selectievraag zijn ingevoerd kan de informatievraag zonder problemen worden omgezet in de gewenste selectievraag m.b.v. de Change-functie. Een rij dubbele streepjes ("========") in de vragenlijst geeft aan dat alle vragen die hierna komen op geen enkele manier vanuit vraag 1 bereikt kunnen worden (dead branch). Deze vragen zullen dus nooit op het agent-window zichtbaar worden. Het voorkomen van dit soort vragen geeft meestal aan dat er tijdens het invoeren van de vragen een fout is gemaakt. Een ccd-fIle wordt vervolgens aangemaakt door de gerealiseerde vragenstructuur op te slaan m.b.v. de functie "Save As...". Dit resulteert in een fIle ''filenaam.ccd'' waarvan het versienummer gelijk is aan 1 en waarin zich nog geen klanten bevinden. Voor de abonnementen-case is de vragenstructuur opgeslagen als "abon.ccd".

Wijzigen van een ccd-file: Open een ccd-fIle m.b.V. de "Open"-functie onder het menu-item "File" van de Question Editor. De vragenstructuur van de ccd-fIle wordt nu zichtbaar. Wijzigen van de vragenstructuur gaat weer met de eerder geïntroduceerde edit-functies. M.b.v. de functie "Save" wordt de gewijzigde ccd-fIle weer opgeslagen en is het versienummer van de file met 1 verhoogd. Alle in de ccd-fIle aanwezige klanteninformatie gaat hierbij verloren.

Importeren van klanten in een ccd-file: Voor het toevoegen van klanten aan een ccd-fIle kan m.b.v. de functie "Import" onder het menu-item ''File'' van de Question Editor klanteninformatie uit een tekstfile worden omgezet naar het ccd-formaat. De tekstfIle met klanteninformatie moet hiervoor aan de volgende eisen voldoen: - De klanteninformatie van elke klant bestaat uit een gelijk aantal opeenvolgende regels - Elke regel van de file bevat hoogstens één informatieveld - De klanteninformatie van de eerste klant in de fIle is representatief voor alle klanten. Als voorbeeld wordt hier weer even uitgegaan van de case met de proefabonnementen. Nadat de importfunctie is gestart wordt eerst gevraagd naar welke ccd-fIle de klanteninformatie moet worden

62

overgebracht. We kiezen nu de ftle "abon.ccd". Vervolgens wordt gevraagd vanuit welke tekstftle de klanteninformatie moet worden geïmporteerd. Als de tekstfile nog niet eerder in het Call Center is gebruikt, of een van de ccd-ftle afwijkende structuur heeft, dan moet handmatig worden aangegeven bij welke vraag elk informatieveld hoort (zie Figuur 26). Hierbij wordt gebruik gemaakt van de eis dat de klanteninformatie van klant 1 in de tekstfile representatief is voor alle klanten.

CualomerFHlIds: I

IIDeze file ia een lijd Ilvan kIanleninlollnatie Ilzoala deze in het can lIcenter kan worden llgeimporleerd. klanll: 11313 Slob E.win 04132·61663

Firsl Cuslome.Field:

I!::::::J

Fields per cud. .er:

~

Number of customerr.

CJ

Co_cl field wilh... L...-

ZonMWeide 5

Im

--'

54D4KK Uden Nederland

Klanl 2: 11111

Figuur 26: Het importeren van klanten In Figuur 26 is de beginsituatie te zien waarbij nog geen informatievelden zijn gedefinieerd. In de "CustomerFields"-lijst is nu het begin van de tekstfile te zien. Om de klanteninformatie nu op de juiste manier aan de vragenstructuur in de abon.ccd-ftle te koppelen moet eerst de beginregel van klant 1 worden aangegeven. In het voorbeeld is dat de regel met de tekst "klant 1:". Door deze regel m.b.v. de muis te selecteren en de "First Field"-button aan te klikken wordt dit aan de software doorgegeven. Alleen het gedeelte van de ftle beginnend vanaf deze regel is nu in de "CustomerFields"-lijst zichtbaar. Vervolgens moet worden aangegeven welke regel de laatste regel is die nog niet bij klant 2 hoort. In het voorbeeld is dit de lege regel voor de regel met de tekst "klant 2:". Selecteer deze regel weer met de muis en klik op de "Last Field"-button. In de "CustomerFields"-lijst moeten nu alle informatieregels behorende bij klant 1 staan. Als dit niet het geval is kan m.b.v. de "All Fields"-button het informatiegebied voor klant 1 opnieuw worden gedefinieerd. Nu kan elke informatieregel van klant 1 worden gekoppeld aan een vraag uit de vragenstructuur uit abon.ccd. Selecteer hiervoor een bepaalde regel en kies hierbij uit de combobox met het label "Connect field with..." de bijbehorende vraag. M.b.v. de "C# +1"- en "C# -I"-buttons kan vervolgens het klantenbestand worden nagelopen om te zien of de informatievelden van alle andere klanten nu ook goed zijn gedefinieerd. Door op de "OK"-button te klikken wordt uiteindelijk de gedefinieerde klanteninformatie aan de ccd-ftle toegevoegd. Klanteninformatie die zich al in de ftle bevond blijft hierbij behouden.

63

Exporteren van klanteninfonnatie uit een ccd-file: De ccd-files hebben een speciaal op het Call Center afgestemd fonnaat en zijn daarom niet voor andere programma's leesbaar. M.b.v. de functie "Export" is het echter mogelijk om de klanteninfonnatie in een ccd-file als een tekstfile op te slaan. Dit resulteert in files met de extentie ".exp". Export-files kunnen eenvoudig in de ccd-fIle geïmporteerd worden. Hiervoor hoeven de infonnatievelden per klant niet meer opnieuw gedefinieerd. Een voorwaarde is echter dat de vragenstructuur in de tussentijd niet is veranderd. Deze voorwaarde wordt door de software gecontroleerd aan de hand van het versienummer van de ccd-file. Als de vragenstructuur van de ccd-fIle niet wordt veranderd is het dus mogelijk om snel klanten te exporteren en importeren. Het Call Center kan bijvoorbeeld op een bepaalde dag alle klanten uit Amsterdam behandelen en de dag erna snel weer omschakelen naar de klanten uit den Haag.

Definitie van een outbound applicatie: In het Call Center kan een bepaalde ccd-file pas gebruikt worden als er naar verwezen wordt via een unieke aplicatienaam. Het definieren van een applicatienaam gebeurt m.b.v. de functies "Add Application", "Remove Application" en "Change Application" onder het menu-item "Setup" in het statuswindow van de Data handier. ~

[ile

Setup

[M.

OMa HàJldl<~1 .Qptions Help

~rrn

Acliv" Agent.:

I AppIicationo:

____..__.........__.._..._._ _ _ _

"l!J!U;..AI!.!l~

AppL2: OuiZ AppL3: Technische V,_ Appl.4: Co_",ci,,'" V,ag"n Appl.5: Algem"n" Inlormali"

,

. ..

••'.

.'

'::; ...~~~~:::~:mr.i::;:~§':::f$~~:

Figuur 27: Het status-window van de Data HandIer De lijst van gedefmieerde applicatienamen wordt opgeslagen in de ccdemo.ini fIle en blijft dus beschikbaar voor het Call Center. Voor de demonstratie wordt de lijst van applicatienamen in het statuswindow van de Data HandIer weergegeven. Door onder het menu-item "Options" de optie "Show Applicationinfo" te kiezen kan in deze lijst ook extra infonnatie over elke applicatie worden weergegeven. Deze infonnatie bestaat uit: het applicatietype (inbound of outbound), de ccd-file waarnaar wordt verwezen en de status van de applicatie (geeft aan of de applicatie op dat moment door een bepaalde server wordt gebruikt).

Samenstellen van de bellijst: Het samenstellen van een bellijst gebeurt m.b.v. het programma "CalI List" (zie Figuur 19). Hierin wordt eerst een bepaalde outbound applicatie uit de lijst van applicatienamen in de Data Handier gekozen. Gebruik hiervoor de functies onder het menu-item "Setup". De actieve applicatienaam wordt nu in de statusbar zichtbaar. Vervolgens kan door defenitie van een selectiecriterium een bepaald gedeelte van het klantenbestand in de ccd-file van de actieve applicatie worden geselecteerd. Hiervoor wordt in het kader met als label "ClientSelection" eerst een bepaald infonnatieveld gekozen waarop de uiteindelijke doelgroep zal worden

64

geselecteerd. In het voorbeeld van de proefabonnementen is hiervoor het veld dat de woonplaats van elke klant bevat gekozen. Daarna wordt aangegeven met welke waarde de inhoud van dit veld moet worden vergeleken om te bepalen of een klant in de bellijst komt. In het voorbeeld is aangegeven dat de inhoud van het woonplaatsveld gelijk moet zijn aan de waarde "den Haag". Indien geen selectiecriterium wordt opgegeven komen alle klanten van de ccd-file in de bellijst. M.b.v. de "Get Clients"-button worden alle geselecteerde klanten uit de ccd-file gehaald. Let op: voor weergave van de geselecteerde klanten in het window van de Call List applicatie dient te zijn aangegeven door welk informatieveld elke klant wordt gerepresenteerd. In het voorbeeld is hiervoor opgegeven dat het klantIabel gelijk is aan het informatieveld dat de klantnaarn bevat.

De agent De agent ziet aan het al dan niet actief zijn van de "Volgende Klant"-button of de outbound server (=Call List) actief is. Vervolgens kan de agent zelf bepalen of hij daadwerkelijk een klant uit de bellijst gaat bellen. Steeds als een agent een nieuwe klant uit de bellijst opvraagt krijgt hij via de statusbar actuele informatie over de voortgang van het outbound Call Center. Hiervoor wordt aangegeven hoeveel klanten er al gebeld zijn en hoeveel klanten er in totaal gebeld moeten woden. Dit is een vorm van positieve terugkoppeling.

De klant

De klant heeft weinig met het outbound Call Center te maken en merkt waarschijnlijk niets van de computerondersteuning van de agent.

65

Het inbound CaU Center Hier is het de bedoeling dat binnenkomende gesprekken met een bepaalde reden (bijvoorbeeld technische vragen) worden afgehandeld door een groep agents die hiervoor geschikt is. Een inbound CaB Center kan handig zijn voor help desks, het verwerken van reacties op grote campagnes (bijvoorbeeld televisiereclame), het afhandelen van bestellingen, etc.

De manager De manager bepaalt in dit geval welke klanten van de diensten van het Call Center gebruik mogen maken. Verder maakt hij net als bij het outbound Call Center een vragenscenario ter ondersteuning van de agent. Veel management-functies van het inbound Call Center zijn gelijk aan die van het outbound Call Center. Hier zullen daarom alleen de afwijkingen t.o.v. het outbound Call Center worden behandeld.

Aanmaken van een ccd-file: Gaat op precies dezelfde manier als in het outbound geval. Er wordt alleen als extra eis gegeven dat het tweede infonnatieveld altijd het klantnummer bevat. Dit klantnummer mag uit een willekeurig aantal cijfers bestaan, maar moet uniek zijn per ccd-file.

Definitie van een inbound applicatie: De defmitie van een inbound applicatie geschiedt op dezelfde manier als bij het outbound Call Center. Voordat een inbound applicatie in het Call Center kan worden gebruikt moet er echter eerst voor worden gezorgd dat de applicatienaam ook voorkomt in de "menu.vap"-file. De "menu.vap"-file, die zich bevindt in de directory "VBV" van VBVoice, bevat de ingesproken teksten waaruit het keuzemenu voor de inbeBende klant is opgebouwd. Voor elke inbound applicatie moet er in deze file een gesproken tekst aanwezig zijn, anders treedt een fout op. Voor het toevoegen van een applicatienaam kan gebruik worden gemaakt van het programma "Announce!". Na het openen van menu.vap dient een extra vap-phrase worden toegevoegd met een label die precies gelijk is aan de applicatienaam.

Activeren van een inbound applicatie: Het activeren van een inbound applicatie gebeurt m.b.v. het programma "Inbound Server" (zie Figuur 22). Er kunnen maximaal 8 inbound applicaties tegelijk actief zijn. De lijst van actieve inbound applicaties wordt weer opgeslagen in de ccdemO.ini file (in windowsdirectory) en blijft dus ook na het stoppen van de Inbound Server bestaan.

De agent De agent ziet aan het al dan niet voorkomen van inbound applicaties in het "beschikbaarheids"-window of een bepaalde applicatie actief is. De agent kan zich opgeven voor inbound applicaties, maar kan op het moment dat een klant naar het Call Center belt zelf bepalen of hij de klant ook daadwerkelijk wil behandelen.

66

De klant De klant heeft in het begin alleen met de computer te maken. Pas als is aangegeven waarvoor wordt gebeld en het klantnummer is ingevoerd wordt de klant eventueel verder geholpen door een agent. Het initiele gesprek van de klant met de computer is op de volgende manier opgebouwd:

1. 2. 3. 4. 5. 6.

''Welkom'' (gesproken tekst) "Keuzemenu" (gesproken tekst) Invoerkeuze "Geef uw klantnummer" (gesproken tekst) Invoer klantnummer afgesloten met een hekje (#) "Even geduld" (gesproken tekst).

De klant wordt eerst welkom geheten in het Cail Center en krijgt vervolgens tijdens het tweede gedeelte te horen welke inbound applicaties in het Cail Center actief zijn. M.b.v. de druktoetsen van de telefoon kan de klant vervolgens een bepaalde keuze maken uit deze applicaties. In het vierde gedeelte wordt gevraagd het klantnummer in te toetsen en af te sluiten met een hekje. Deze constructie zorgt ervoor dat klantnummers van willekeurige lengte kunnen worden ingevoerd. Daarna krijgt de klant te horen dat hij even moet wachten voordat hij wordt doorverbonden met een agent. NB: Door tijdens gesproken tekst op een willekeurige toets te drukken gaat de computer onmiddellijk verder naar het volgende punt. Op deze manier is het dus mogelijk sneller door de zes punten te lopen. Opmerking: Er vindt geen controle plaats op de geldigheid van het klantnummer. Ook niet op correct invoeren door de klant.

67

Bijlage B: Network DDE in Visual Basic Voor de overdracht van data tussen applicaties op verschillende computers binnen een computernetwerk maakt Windows for Workgroups (versie 3.11) gebruik van het Network Dynamie Data Exchange protocol (NODE). Dit protocol is een uitbreiding van het oudere DDE dat de communicatie tussen verschillende applicaties op één computer regelt Binnen DDE is altijd sprake van een source en een destination. De DDE-destination is hierbij de applicatie die het initiatief neemt om een verbinding naar een andere applicatie, de DDE-source, te leggen (terminologie: de destination haalt informatie uit de source). De specificatie van een DDE-link bestaat uit 3 niveau's , namelijk ApplicationName, TopicName en ItemName. Windows maakt gebruik van een database (gesitueerd in de sectie "[DDEShares)" van de system.ini file) waarin wordt bijgehouden welke DDE-Topics per DDE-Application kunnen worden bereikt via netwerkcommunicatie. Om een bepaalde DDE-Topic op te geven voor NODE wordt gebruik gemaakt van de Windows API-functie "NDDEShareAdd". In VisuaI Basic wordt deze functie op de volgende manier aangeroepen: DecIare Function NDDEShareAdd Lib "NDDEAPI.DLL" (Server As Any, ByVal Level As Integer, ShareInfo As NDDESHAREINFO, ByVal nSize As Long) As Integer DecIare Function lstrcpy Lib "KERNEL" (ByVal szDesr As Any, ByVal szSource As Any) As Long Type NDDESHAREINFO szShareName As String * 65 LpszTArgetApp As Long LpszTargetTopic As Long lpbPasswordl As Long cbPasswordl As Long dwPermissionsl As Long lpbPassword2 As Long CbPassword2 As Long dwPermissions2 As Long lpszItem As Long cAddItems As Long lpNDdeShareItemInfo As Long End Type Dim Dim Dim Dim

ShareName As String FileName As String TopicName As String ShareInfo As NDDESHAREINFO

ShareName = "Agent" FileName = "Agent" applicatie) TopicName = "DS"

'ObjectName (Veranderen per applicatie) 'Naam van de .EXE file voor de source (Veranderen per 'Naam van het source-form.

ShareInfo.szShareName ShareName & Chr$(O) FileName = FileName & Chr$(O) ShareInfo.LpszTArgetApp = lstrcpy(ByVal FileName, ByVal FileName) TopicName = TopicName & Chr$(O) ShareInfo.LpszTargetTopic = lstrcpy(ByVal TopicName, ByVal TopicName) ShareInfo.lpszItem = lstrcpy(Chr$(O), Chr$(O» ShareInfo.cbPasswordl = 0 ShareInfo.lpbPasswordl = lstrcpy(Chr$(O), Chr$(O» ShareInfo.dwPermissionsl = &Hl Or &H2 Or &H4 Or &Ha Or &H16 ShareInfo.CbPassword2 = 0 ShareInfo.lpbPassword2 = lstrcpy(Chr$(O), Chr$(O» ShareInfo.dwPermissions2 = ShareInfo.dwPermissionsl ShareInfo.lpNDdeShareItemInfo = 15 Result

= NDDEShareAdd(ByVal

0&, 2, ShareInfo, Len(ShareInfo»

68

Vanuit een DDE-destination wordt vervolgens op de volgende manier een NDDE-verbinding naar een applicatie ergens in het netwerk (dus ook naar een applicatie op hetzelfde systeem) geopend: DD.Token.LinkTopic = " " " & SourceComputer & "'NDDE$I" & "Agent" DD.Token.LinkItem = "Token" DD.Token.LinkMode = 1

"NDDE$" is de naam van de DOE-applicatie die zorgt voor de daadwerkelijke DOE-verbinding over het netwerk. Het lezen van de eigen computemaam uit de system.ini file voor het automatisch herkennen van parallel lopende applicaties op verschillende systemen gaat op de volgende manier: DecIare Function GetPrivateProfileString Lib "KERNEL" (ByVal lpApplicationName As String, ByVal lpKeyName As String, ByVal lpDefault As String, ByVal lpReturnedString As String, ByVal nSize As Integer, ByVal lpFileName As String) As Integer Global ComputerName As String 'N.B. : Voeg de regel "ComputerName = GetComputerName()" toe aan de MAINsubroutine! ComputerName hoeft slechts eenmaal geinitialiseerd te worden.

,

Function GetComputerName () As String 'Deze functie leest de naam van de computer waarop dit programma draait uit 'de system.ini-file. Deze naam wordt gebruikt voor tokenpassing of om de 'identiteit van de computer door te geven aan een andere applicatie. Dit 'laatste is nodig indien een andere applicatie op eigen initiatief informatie 'terug moet kunnen zenden. Dim Result As Integer Dim TempName As String 'Lezen van ComputerName uit system.ini-file: TempName = String$(255, 0) Result = GetPrivateProfileString ("Network", "ComputerName" , Len(TempName), "system.ini")

.... ,

TempName,

If Result = 0 Then MsgBox "Can't find ComputerName in system.ini file", 16, "DDE ERROR" End End If GetComputerName

Left$(TempName, Result)

End Function

69