DE10328884A1

DE10328884A1 - Verfahren und Vorrichtung zur Implementierung einer Callback-Funktionalität

Info

Publication number: DE10328884A1
Application number: DE2003128884
Authority: DE
Inventors: Stephan Berendsen; Andreas Müller-Hermann; Ralf Eckstein; Tobias Kramer
Original assignee: LIVING BYTE SOFTWARE GmbH
Current assignee: LIVING BYTE SOFTWARE GmbH
Priority date: 2003-06-26
Filing date: 2003-06-26
Publication date: 2005-02-10

Abstract

Verfahren zum Implementieren einer Callback-Funktionalität, wobei das Verfahren aufweist: DOLLAR A Bereitstellen einer Eingabemöglichkeit auf einer Webseite eines Service-Anbieters auf einem Host-Server, um einem Benutzer an seinem mit dem Host-Server verbundenen Rechner die Anforderung eines Rückrufs (Callback) durch den Service-Anbieter zu ermöglichen; DOLLAR A in Reaktion auf die Anforderung des Rückrufs durch den Benutzer, Übermittlung von personenbezogenen Daten des Benutzers von dem Host-Server zu einem dem Service-Anbieter zugeordneten Server, um den Server zu veranlassen, die folgenden Schritte auszuführen: DOLLAR A Aufbau einer ersten Telefonverbindung von dem Server des Service-Anbieters zur einem Telefonanschluss des Service-Anbieters; DOLLAR A Aufbau einer zweiten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Benutzers; DOLLAR A Zusammenschalten der ersten und zweiten Telefonverbindung zur Herstellung einer Verbindung zwischen dem Service-Anbieter und dem Benutzer.

Description

Inzwischen werden viele Services über das Internet abgewickelt oder angeboten, beispielsweise Dienstleistungen oder auch Waren. Dies geschieht üblicherweise, indem eine Service-Anbieter auf einem Host-Server eine Website betreibt, mittels

1 illustriert schematisch eine Konfiguration zur Bereitstellung eines solchen Services. Die Kommunikation zwischen Service-Anbieter und dem (End-)Kunden (dem Benutzer) erfolgt häufig über E-Mail bzw. direkt über die Webseite (sogenannte Feedback-Formulare). Im professionellen Bereich erfolgt meist eine vollautomatisierte Abwicklung, d. h. Bestellungen auf der Webseite werden direkt an das Warenwirtschaftssystem oder das ERP-System des Service-Anbieters übertragen. Es kann jedoch auch erforderlich oder nützlich sein, daß eine Telefonverbindung zwischen dem Benutzer (dem Kunden) und dem Service-Anbieter hergestellt wird. Um dies zu ermöglichen, bieten manche Service-Anbieter eine sogenannte Callback-Funktionalität an. Hierzu wird auf der Website des Service-Anbieters, die auf dem Host-Server 100 gehostet wird und vom Benutzer mittels dessen Rechner 120 aufgerufen wird, beim Klicken auf einen "Callback-Button" ein Formular geöffnet, in dem der Kunde seine Telefonnummer und gegebenenfalls eine gewünschte Rückrufzeit eingeben kann. Die entsprechenden Informationen werden dann – typischerweise per E-Mail – vom Host-Server 100 an ein Call-Center 110 weitergeleitet. Im Call-Center erscheinen die Informationen am Arbeitsplatz bzw. am Terminal eines Sachbearbeiters oder Telefonservice-Mitarbeiters, der dann den Kunden – gegebenenfalls sofort oder zur gewünschten Zeit – im Auftrag des Service-Anbieters zurückruft.

Bei dieser herkömmlichen Implementierung der Callback-Funktionalität ist es jedoch erforderlich, daß ein Call-Center betrieben wird, in dem ständig Mitarbeiter zur Verfügung stehen, die gegebenenfalls den Kunden zurückrufen. Für kleine Firmen, die Services oder Waren über das Internet anbieten wollen und die nicht über die finanziellen oder personellen Resourcen verfügen, ein Call-Center zu betreiben, ist diese Lösung jedoch nicht praktikabel.

Es ist daher eine Aufgabe der vorliegenden Erfindung, einem Service-Anbieter die Bereitstellung einer Callback-Funktionalität über das Internet zu ermöglichen, ohne einee-aufwendiges Callcenter betreiben zu müssen.

Daneben ist im Falle der herkömmlichen Implementierung der Callback-Funktionalität auch erforderlich, daß eine permanente Verbindung zwischen dem Host-Server 100 und dem Call-Center 110 existiert, um sicherzustellen, daß Anforderungen eines Callbacks zeitnah bearbeitet werden.

Sowohl die ständige Bereitstellung eines Call-Centers als auch die Bereitstellung einer permanenten Verbindung zwischen dem Host-Server und dem Call-Center sind jedoch für kleinere Service-Anbieter, die teilweise im Falle von sogenannten Webshops nur aus Ein-Mann-Betrieben bestehen, nicht praktikabel.

Es ist daher eine Aufgabe der vorliegenden Erfindung, eine technische Lösung zur Anbietung einer Callback-Funktionalität zu schaffen, die auch für kleinere Firmen ohne größere finanzielle oder personelle sowie technische Resourcen implementierbar ist.

Gemäß einem ersten Aspekt der vorliegenden Erfindung wird diese Aufgabe im Wesentlichen dadurch gelöst, daß von einem Kunden oder Benutzer eingegebene personenbezogene Daten an einen Server des Service-Anbieters weitergeleitet werden, der dann eine erste Telefonverbindung zu dem Service-Anbieter herstellt. Eine zweite Telefonverbindung wird von dem Server zu dem Kunden hergestellt, und die beiden Telefonverbindungen werden dann zusammengeschaltet.

Gemäß einem bevorzugten Ausführungsbeispiel wird die erste Telefonverbindung zwischen dem Server des Service-Anbieters und dem Service-Anbieter zuerst hergestellt, nur dann, wenn der Service-Anbieter tatsächlich bereit ist, den Callback durchzuführen, wird dann die zweite Telefonverbindung zu dem Benutzer (dem Endkunden) hergestellt und beide Telefonverbindungen werden zusammengeschalten.

Die Bereitschaft des Service-Anbieters zur Durchführung des Callbacks kann dieser beispielsweise durch Annahme des Anrufs des Servers des Service-Anbieters signalisieren, erfolgt keine Annahme, so wird auch die zweite Telefonverbindung gar nicht erst hergestellt.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel erfolgt die Übermittlung der personenbezogenen Daten nicht direkt vom Host-Server zum Server des Service-Anbieters, sondern zunächst zu einem Trigger-Server. Von diesem Trigger-Server erfolgt dann der Aufbau einer Telefonverbindung zu dem Server des Service-Anbieters mittles eines sogenannten Triggeranrufs, wobei letzterer allerdings nicht abhebt, so daß keine kostenpflichtige Verbindung zustande kommt. Die Übermittlung der personenbezogenen Daten kann dennoch durch Verwendung der ISDN-Subadresse erfolgen. In Reaktion auf diesen Triggeranruf stellt dann der Server des Service-Anbieters die erste Telefonverbindung zum Service-Anbieter selbst her. Nimmt dieser die erste Telefonverbindung an oder erklärt dieser die Bereitschaft zur Durchführung des Callbacks, so wird die zweite Telefonverbindung zum Kunden hergestellt, und beide Verbindungen werden zusammengschalten.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel erfolgt der Aufbau der ersten Telefonverbindung abhängig von der Uhrzeit an bestimmte verschiedene Telefonnummern des Service-Anbieters.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel erfolgt eine Überprüfung der personenbezogenen Daten dahingehend, ob der Kunde oder Benutzer berechtigt ist, einen Rückruf anzufordern. Dabei können beispielsweise die Kundennummer, ein vorbezahltes Supportguthaben, Bonuspunkte, oder eine Priorisierung des Kunden als Kriterium verwendet werden, um zu beurteilen, ob der Kunde berechtigt ist, einen Callback anzufordern. Andere Kunden werden gegebenenfalls auf einen E-Mail-Support verwiesen.

Gemäß einem weiteren Ausführungsbeispiel erfolgt eine Überprüfung hinsichtlich bestimmter Tage oder Zeiten dahingehend, ob ein Rückruf überhaupt möglich ist. Gemäß diesem Ausführungsbeispiel sind in einer Datenbank Zeiten oder Tage abgelegt, für ein Rückruf erfolgen kann.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel erfolgt dann, wenn kein Rückruf möglich ist, eine Benachrichtigung des Kunden, beispielsweise mittels E-Mail, mittels einer direkten Benachrichtung über eine Internet-Session, mittels eines automatischen Telefonanrufs oder mittels SMS.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel enthalten die personenbezogenen Daten die Rückrufnummer, unter der der Kunde zu erreichen ist. Gegebenenfalls können jedoch auch noch weitere personenbezogene Daten übermittelt werden, beispielsweise die Art der Anfrage oder die Art der Information, die der Kunde wünscht.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel werden die personenbezogenen Daten, beispielsweise die Telefonnummer des Kunden und/oder die weiteren personenbezogenen Daten wie die Art der Anfrage, die Priorität des Kunden etc. dazu verwendet, zu beurteilen, ob tatsächlich ein Callback erfolgt.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel kann der Service-Anbieter selbst nach Aufbau der ersten Telefonverbindung den Callback bzw. die Durchführung des Callbacks noch ablehnen. Beispielsweise kann der Service-Anbieter in seinem Display anhand der übermittelten Rufnummer des Anrufers (die der Telefonnummer des Servers des Service-Anbieters entspricht) erkennen, daß ein Callback angefordert wird. Lediglich dann, wenn der Service-Anbieter tatsächlich abhebt, erfolgt dann der Aufbau der zweiten Telefonverbindung und damit die Durchführung des Callback.

Falls kein Abheben oder Bestätigen des Callbacks durch den Service-Anbieter erfolgt, so kann der Kunde oder Benutzer mittels E-Mail, SMS oder direkt über Internet darüber informiert werden, daß momentan ein Callback nicht möglich ist.

Gegebenenfalls kann dem Kunden auch die Möglichkeit bereitgestellt werden, eine Nachricht oder weitere Informationen zu hinterlassen, beispielsweise wann er alternativ zurückgerufen werden möchte.

Gemäß einem weiteren bevorzugten Ausführungsbeispiel informiert der Server des Service-Anbieters vor oder nach Aufbau der ersten Telefonverbindung, jedenfalls vor dem Zusammenschalten der ersten und der zweiten Telefonverbindung, den Service-Anbieter über personenbezogene Daten des den Callback anfordernden Kunden, beispielsweise mittels Sprachausgabe oder über SMS.

Die vorliegende Erfindung wird nun unter Bezugnahme auf die beiliegenden Zeichnungen anhand mehrerer Ausführungsbeispiele im Detail beschrieben. Es zeigen:
1 eine Konfiguration gemäss dem Stand der Technik.
2 eine Konfiguration gemäss einem Ausführungsbeispiel der vorliegenden Erfindung.
3A und 3B zeigen ein Fulussdiagramm gemäss einem Ausführungsbeispiel der vorliegenden Erfindung
2 zeigt schematisch eine Anordnung gemäss einem ersten Ausführungsbeispiel der vorliegenden Erfindung. Host-Server 200 ist ein Web-Server, beispielsweise der Web-Server eines Internet-Providers, der als Host für eine oder mehrere Webseiten von Kunden des Host-Serverbetreibers dient. Eine der Webseiten, die vom Host-Server 200 gehostet werden, ist dabei die (nicht dargestellte) Webseite eines Servicebetreibers, beispielsweise eines Webshop-Betreibers, auf der Produkte zum Verkauf angeboten werden.
Vom PC 210 eines beliebigen Benutzers aus ist diese Webseite über das Internet 220 abrufbar. Auf dem Display des PCs 210 kann sich der Benutzer die Angebote des Webshop-Betreibers anzeigen lassen. Durch Ausfüllen von Formularen und Verschicken der Formulare über das Internet 220, z.B. per email, kann der Benutzer Bestellungen tätigen. Diese Bestellungen werden dann z. B. über das Internet 220 per email an den PC 230 des Webshop-Betreibers versandt, der dann die bestellten Waren liefert.
Bei dem PC 230 kann es sich gemäss einem Ausführungsbeispiel um einen handelsüblichen PC handeln, der durch Ausstattung mit geeigneter Software und Hardware (z. B. ISDN-Karte oder Modem) in die Lage versetzt wird, auf die nachfolgend beschriebene Weise die Funktion eines Callback-Servers auszuführen. Durch diese Funktionalität wird der PC bzw. Rechner 230 des Service-Anbieters zu einem "Server" 230, des Service-Anbieters, der beispielsweise bei ihm zu Hause – aber auch an einem anderen Ort – stehen kann. Der Server 230 des Service-Anbieters ist diesem zugeordnet und übernimmt für ihn auf die nachfolgend beschriebene Weise die Funktion eines Callcenters, bzw. ermöglicht es dem Service-Anbieter eine solche Callcenter-Funktionalität seinem Endkunden anzubieten.
Zusätzlich zu dem ereits beschriebenden herkömmlichen Ablauf bietet also das in 2 schematisch dargestellte System dem Endnutzer am PC bzw. Terminal 210 die Möglichkeit, einen Rückruf (Callback) durch den Service-Anbieter anzufordern. Um dem Benutzer diese Anforderung der telefonischen Kontaktaufnahme zu ermöglichen, befindet sich auf der Webseite des Service-Anbieters ein Button, der dem Benutzer die Anforderung eines Rückrufs (Callback) durch den Service-Anbieter ermöglicht. Beim Klicken auf diesen Button öffnet sich für den Benutzer ein Fenster (z. B. eine neue Webseite), in das er z. B. durch Ausfüllen eines Formulars personenbezogene Daten eingeben kann. Bei den personenbezogenen Daten handelt es sich insbesondere um die Telefonnummer, unter der der Benutzer zurückgerufen werden möchte, es können aber beispielsweise noch weitere (oder andere) personenbezogene Daten eingegeben werden, beispielsweise der Name des Kunden, die Kundennummer, die gewünschte Rückrufzeit, der Grund für den Rückrufwunsch (Reklamation, Information zu Garantieleistungen, etcetera), zusätzlich optional die Mobiltelefonnummer des Kunden, usw. Für die Eingabe des Grunds für den Wunsch des Rückrufs kann beispielsweise ein Drop-down-Menü vorgesehen sein, um die Auswahlmöglichkeiten zu begrenzen und die spätere Verarbeitung dieses Eingabeparameters zu vereinfachen.
Falls es sich bei der Webseite des Servicebetreibers um eine Seite handelt, die eine vorherige Authorisierung erfordert, bzw. optional für vorregistrierte Kunden anbietet, so können die personenbezogenen Daten auch bereits vorab im Host-Server (oder im Server des Service-Anbieters) unter der ID des Benutzers abgespeichert sein und müssen nur noch aufgerufen werden.
Bei dem Callback-Button handelt es sich beispielsweise um eine Webseite, die von dem Betreiber des Host-Servers 200 als Service angeboten wird und die ein Betreiber einer auf dem Host-Server gehosteten Webseite als Button beispielsweise über einen Link in seine Webpage integrieren kann. Damit wird dann die Callback-Seite in die Webseite des Service-Anbieters integriert. Ein solcher Link kann beispielsweise folgendermassen aussehen:
www.hoster.com/callback/callback.php?KD=145567
Mit diesem Link wird ein php-Skript aufgerufen, das als Parameter KD die Kundennummer des Service-Anbieters hat, der ja Kunde bei dem Betreiber des Host-Servers 220 ist. Der Parameter „KD" (Kundennummer) dient somit zur eindeutigen Identifikation des „Service-Anbieters", um festzulegen, für wen die vom Benutzer in die Callback-Seite eingegebenen Informationen bestimmt sind.
Wird dieses „call-back-formular" nun von einem Kunden aufgerufen, so geschieht dies in einer eigenen „user-session". Dabei wird dem aufgerufenen link z.B. eine dynamische „session-id" als Parameter hinzugefügt, z. B. in der Form
www.hoster.com/callback/callback.php?KD=145567?sid=356424595476256
Dadurch kann diese Session später wieder eindeutig identifiziert werden, um z. B. genau diesem Endbenutzer ueber diese Internetwebsite eine bestimmte Information zukommen zu lassen, (z.b. der „webshop-betreiber" ist momentan nicht erreichbar, bitte...)
In einer Datenbank des Host-Servers 220 sind sämtliche Session-IDs der momentan geöffneten Sessions gespeichert, zusammen mit Informationen über die Ports bzw. die IP-Adressen, über die die jeweiligen Benutzer an ihrem Terminal erreicht werden können. Damit kann einem Benutzer, dem eine Session zugeordnet ist, direkt von einem anderen mit dem Internet verbundenen Teilnehmer oder Rechner, der diese Session kennt, eine Nachricht übermittelt werden.
Die session-ID wird in der Datenbank des Host-Servers gelöscht sobald der Endkunde die Seite des webshop-betreibers löscht bzw. schliesst, damit ist feststellbar, ob er sich noch auf dieser Seite befindet und ihm im Bedarfsfalle eine Nachricht angezeigt werden kann.
Die telefonische Kontaktaufnahme erfolgt nun mit Hilfe des PCs 230 des Service-Anbieters, der beispielsweise bei ihm zuhause steht. Dabei handelt es sich beispielsweise um einen handelsüblichen PC, der mit einem Modem oder einer ISDN-Karte ausgerüstet ist. Der PC muss zwar nicht permanent online sein, vorteilhafterweise sollte er aber über die Möglichkeit verfügen, sich mit dem Internet zu verbinden. Daneben sollte er über die Möglichkeit verfügen, gleichzeitig zwei Telefonanrufe über verschiedene Leitungen aufzubauen, wie nachfolgend noch deutlich wird.
Die einfachste Hardware-Konfiguration, die diese Anforderungen erfüllt, ist die Installation einer ISDN-Karte auf dem PC 230. Für die Durchführung des nachfolgend beschriebenen Verfahrens ist es ferner vorteilhalft, wenn der PC 230 eingeschaltet ist.
Neben dem PC 230 des Service-Anbieters sowie dem Host-Server 200 und dem PC 210 des Endkunden ist in 3 ein Trigger-Server 240 gezeigt. Dieser Trigger-Server verfügt über die Fähigkeit, in Reaktion auf den Empfang einer entsprechenden Anforderung einen Triggeranruf durchzuführen, der beispielsweise den PC 230 des Service-Anbieters veranlasst, einen Rückruf zu initiieren.
Der Service-Anbieter, dem der PC 230 gehört, betreibt nun wie beschrieben auf dem Host-Server 200 des Host-Serverbetreibers seine Webseite, er ist also ein Kunde des Host-Serverbetreibers. Auf dem Host-Server sind für den Service-Anbieter spezifische Kundendaten abegelegt, z.B. in einem Konfigurationsmenü, das dem Service-Anbieter, beispielsweise über eine ihn als Kunden des Host-Serverbetreibers identifizierende ID zugeordnet und auf dem Host-Server abgespeichert ist, z. B. in Form einer Tabelle, einer Liste, einer Datenbank oder ähnliches.
Dabei handelt es sich auch beispielsweise um Daten, die für den Callback-Service spezifisch bzw. erforderlich sind, z. B. um die Telefonnummer, unter der sein PC 230 bzw. dessen ISDN-Karte erreichbar ist. Weitere in dem Konfigurationsmenü abgelegte Informationen können beispielsweise Kategorisierungsdaten hinsichtlich des Endkunden sein, z. B. wer (welcher Endkunde) nun tatsächlich einen Rückruf anfordern darf, mit welcher Priorität eine Rückrufanforderung eines bestimmten Kunden behandelt wird, ob z. B. ein vorbezahltes Supportguthaben für einen bestimmten Kunden vorhanden ist oder nicht, ob die Kundennr. einen berechtigten Kunden identifiziert, etc. Einen zur Rückrufanforderung berechtigter Kunde kann dann beispielsweise anhand seines Namens, seiner Kunden-ID oder seines Supportguthabens identifiziert werden, oder beispielsweise auch dadurch, dass der Grund des Rückrufwunsches einer bestimmten vorgegebenen Bedingung entspricht, etcetera. Anhand derartiger Kategorisierungen oder Filter kann beispielsweise entschieden werden, ob tatsächlich ein Rückruf eingeleitet wird, oder ob der Endkunde z. B. auf den email-Support verwiesen wird. Wird ein Callback von einem Endkunden angefordert, so kann in den abgelegtend Kategorisierungsdaten nachgeschlagen werden, wie dieser bestimmte Kunde hinsichtlich seiner Calbackanforderung behandelt wird. Dabei können auch Regeln für diejenigen Kunden vorgegeben werden, für die keine spezifischen Kategorisierungsdaten abgelegt sind. Beispielsweise kann für diejenigen Kunden, die keine spezielle Priorisierung aufweisen können, vorgesehen sein, dass sie auf den emailsupport verwiesen werden.
Neben Kategorisierungen oder Priorisierungen des Rückrufs an Endkunden im Konfigurationsmenü oder in einer Datenbank des Host-Servers können solche Kategorisierungen oder Priorisierungen aber auch im PC 230 des Service-Anbieters anstelle des Host-Servers, beispielsweise in einer Tabelle oder Datenbank abgelegt oder definiert werden. Dort können beispielsweise aber auch hinsichtlich der Erreichbarkeit des Service-Anbieters Informationen abgelegt werden, etwa wann der Service-Anbieter wo bzw. unter welcher Rufnummer erreichbar ist. Dabei können auch für einzelne Zeiten oder Zeiträume unterschiedliche Rufnummern mit unterschiedlichen Prioritäten abgelegt werden, die dann beispielsweise nacheinander durchprobiert werden. Daneben kann beispielsweise in der Datenbank oder Tabelle auch definiert werden was passiert, wenn der Service-Anbieter zwar im Prinzip erreichbar wäre aber die Durchführung eines Callbacks nicht wünscht. So kann in einem solchen Fall vorgesehen sein, dass der Endkunde über Internet (innerhalb seiner Session) oder per email oder per SMS eine Nachricht erhält, dass der Service-Anbieter momentan nicht erreichbar ist.
Nachfolgend wird nun der Ablauf gemäss einem Ausführungsbeispiel der Erfindung im Detail beschrieben.
Zunächst wählt der Endkunde von seinem PC oder Terminal 210 aus auf der Website des Servicanbieters „call back" an, beispielsweise durch clicken auf den Callback-Button. Damit öffnet er eine Webseite des Hostserverbetreibers, die auf bereits beschriebene Weise in die Webpage des Service-Anbieters integriert ist.
Diese Webseite ermöglicht dem Endkunden die Eingabe personenbezogener Daten. Der Endkunde trägt beispielsweise seine Rückrufnummer sowie seinen Namen sowie optional (wenn Rückruf nicht sofort) einen Rückrufzeitpunkt ein, sowie optional ferner seine Mobil-Nr., um gegebenenfalls (z.B. per SMS) informiert zu werden, wenn z.B. der Service-Anbieter nicht erreichbar ist. Es wird dabei eine sogenannte „session" geöffnet, deren Parameter die ID des Service-Anbieters sowie eine die Session identifizierende Session-ID sind.
Die eingegeben Informationen werden nach erfolgter Eingabe zum Host-Server 200 übertragen.
In Reaktion auf die Übertragung der Daten überprüft der Host-Server in einer Datenbank, bzw. im Konfigurationsmenü desjenigen Kunden (Service-Anbieters) des Host-Serverbetreibers, dem die Kunden-ID der Session zugeordnet ist, unter welcher Telefonnummer der PC 230 des Service-Anbieters erreichbar ist.
Vom Host-Server 200 werden die in das Callback-Formular eingegebenen Informationen zusammen mit der vom Service-Anbieter im Konfigurationsmenü eingegebenen Rufnummer seines PCs 230 an den Trigger-Server 240 übergeben. Dies kann beispielsweise über email oder auch direkt über eine Internetverbindung zwischen dem Host-Server 200 und dem Trigger-Server 240 geschehen.
In Reaktion auf den Erhalt der übermittelten Informationen betreffend eine Callback-Anforderung triggert der Trigger-Server 240 nun den Server 230 des Service-Anbieters, der beispiesweise ein handelsüblicher PC ist, auf dem eine ISDN-Karte installiert ist. Dies geschieht durch Absenden eines oder mehrerer Anrufe vom Trigger-Server zum Server 2230 des Service-Anbieters (bzw. dessen ISDN-Karte), und zwar unter Verwendung der Rufnummer des Servers 230, die durch Nachschlagen im Konfigurationsmenü ermittelt wurde. Dabei wird allerdings keine Verbindung aufgebaut, sondern lediglich mittels der ISDN-Subadresse u.a. die gewünschte Rückrufnummer des Endkunden übertragen. Neben der gewünschten Rückrufnummer können auch noch weitere Informationen, die in das Callback-Formular eingetragen wurden, übertragen werden. Mittels der ISDN-Subadresse kann kostenfrei ohne Abheben beim Angerufenen an diesen mittels eines ISDN-Anrufs eine gewisse Menge an Informationen übertragen werden. Falls dafür ein Anruf aufgrund der begrenzten Länge der kostenfrei übertragbaren ISDN-Subadresse nicht ausreicht, so können auch mehrere derartige Triggeranrufe durchgeführt werden, um die erforderlichen Informationen in mehreren Schritten zu übertragen. Hierzu wird zunächst überprüft, welchen Umfang (wieviele Zeichen) die zu übertragenden Informationen ausmachen, gegebenenfalls werden dann mehrere solche Triggeranrufe hintereinander durchgeführt. Im Triggerserver ist hierzu ein geeignetes Regelwerk abgelegt, das festlegt, in welcher Form und gegebenenfalls mit wie vielen Trigeranrufen die für die Initiierung des Callbacks erforderlichen Informationen vom Triggerserver zu dem PC 230 des Service-Anbieters übertragen werden.
Statt der Übertragung über die Zwischenstation eines Triggerservers kann gemäss einem weiteren Ausführungsbeipiel die Übertragung der Informationen vom Host-Server direkt zum PC 230 des Service-Anbieters erfolgen. Hierfür ist es dann allerdings erforderlich, dass entweder der Host-Server selbst die Funktion des Triggerservers übernimmt, oder dass der PC 230 des Service-Anbieters über eine Verbindung mit dem Host-Server, z. B. das Internet, für diesen erreichbar ist. Um eine zeitnahe Beantwortung einer Anforderung sicherzustellen muss – im Falle der Informationsübertragung über das Internet der PC 230 ständig online sein. Die Verwendung eines Triggeranrufes entweder durch einen separaten Triggerserver 240 oder durchden Host-Server selbst hat dagegen den Vorteil, dass keine ständige Verbindung des PC 230 mit einem Netz oder dem Host-Server erforderlich ist, der PC muss lediglich über seine ISDN-Karte „anrufbar" sein und sollte vorzugsweise hierzu eingeschaltet sein.
Der Server 230 des Service-Anbieters verfügt nun nach erfolgter Übermittlung über die nötigen Informationen, um den Rückruf durchführen zu können. Gemäss dem vorliegenden Ausführungsbeispiel baut er jedoch zunächst eine Telefonverbindung (über ein nicht gezeigtes Telefonnetz oder Mobilfunknetz) zum Service-Anbieter auf (evtl. nacheinander über verschieden priorisierte Telefonnummern, die in einer Datenbank oder Tabelle des PCs 230 abgelegt sind). Dies ist schematisch über die beiden in 2 gezeigten Telefone 240 und 250 angedeutet, die dem Service-Anbieter zugeordnet sind. Beispielsweise kann zunächst versucht werden, den Festnetzanschluss 250 (höchste Priorität) zu errreichen, falls nach einer vorbestimmten Anzahl von Klingelsignalen keine Verbindung zustandekommt, kann dann z. B. versucht werden, das Mobiltelefon 240 des Service-Anbieters (nächsthöhere Priorität) zu erreichen.
Diese Datenbank (oder eine in 2 nicht gezeigte separate Kundendatenbank) kann gemäss einem Ausführungsbeispiel auch noch Informationen über bereits registrierte Kunden enthalten, wobei vor dem Anruf des Service-Anbieters in der Datenbank nachgesehen werden kann, ob zu dem Kunden, der den Rückruf anfordert, spezifische Informationen abgelegt sind.
Ist die Verbindung zum Service-Anbieter aufgebaut kann dann diesem (z.B. per Sprachausgabe) mitgeteilt werden, dass ein Endkunde mit ihm verbunden werden will sowie eventuell das Themengebiet um das es sich handelt (dies kann der Endkunde z. B. über die call-back-webssite übermittelt haben – die Information kann als Information in der isdn-subadresse übermittelt werden/z.b. eine „1" an vordefinierter Stelle der Subadresse für Informationen zu Garantieleistungen, eine „2" an der selben Stelle für ein anderes Thema, etcetera)
Falls über den Kunden schon Informationen in der Kundendatenbank auf dem PC 230 des Service-Anbieters vorliegen, so könnte davon eine Zusammenfassung erstellt werden und die relevanten Daten könnten dem Service-Anbieter per SMS oder per Sprachausgabe vorab übermittelt werden (z.B. bei Kunden, die einen Wartungsvertrag haben, so dass der Service-Anbieter alle wichtigen Details kennt, frühere Fehlerfälle, etcetera). Alternativ zur Sprachausgabe können die Vorab-Informationen auch per SMS übermitelt werden.
Gemäss einem bevorzugten Ausführungsbeispiel soll der website-betreiber das Gespräch jetzt (nach Initiierung der ersten Telefonverbindung) noch ablehnen können, indem er eine entsprechende vordefinierte Aktion durchführt, beispielsweise durch Drücken der Raute-Taste auf seinem Telefon. Die entsprechende Information würde dann an den PC 230 übermittelt, woraufhin dieser dann wiederum eine vordefinierte Aktion initiiert. Beispielsweise könnte der Endkunde mittels eines automatisierten Anrufes des PCs 230 oder durch Versendung einer SMS darüber informiert werden, dass der Service-Anbieter momentan nicht für einen Rückruf zur Verfügung steht. im Falle der Information per Anruf könnte ihm die Möglichkeit des Hinterlassens einer Nachricht gegeben werden, die dann auf einer mailbox des PCs 230 aufgezeichnet wird. Falls die Session des Endkunden am Terminal 210 noch existiert, kann dem Endkunden die entsprechende Nachricht auch direkt auf seinen Bildschirm übermittelt werden, z. B. über ein pop-up-Fenster, das ihm die entsprechende Mitteilung darstellt, dass der Service-Anbieter momentan nicht verfügbar ist. Im PC 230 kann eine nach Prioritäten geordnete Liste von Handlungen in einer Datenbank oder Tabelle für einen solchen Fall des Ablehnens des Rückrufs durch den Service-Anbieter abgespeichert sein. So kann z. B. zunächst direkt über das Internet die Übermittlung der Nachricht versucht werden, bei Ablauf der Session wird dann – falls eine Mobilfunknummer vorliegt – eine SMS versandt, als letzte Alternative kommt dann ein automatischer Anruf mit vorab aufgezeichnetem Text in Frage.
Nimmt der Service-Anbieter das Gespräch, das von dem PC 230 ausgeht, an, so stellt der PC 230 noch eine weitere zweite Telefonverbindung zum Endkunden bzw. dessen Telefon 260 her, und zwar über die zweite ISDN-Leitung bzw. den zweiten B-Kanal und die ISDN-Karte des PCs 230. Sobald die Verbindung zum Endkunden bzw. dessen Telefon 260 steht, schaltet der PC 230 beide Verbindungen zusammen und stellt damit den Rückruf vom Service-Anbieter bzw. dessen Telefon (240 oder 250) zum Endkunden bzw. dessen Telefon 260 her.
Ist der Service-Anbieter nicht erreichbar, so wird der Endkunde wie im Falle des bewussten Ablehnens des Gesprächs durch den Service-Anbieter nach erfolgtem Abheben per SMS oder online bzw. per Telefonanruf informiert, dass der Ansprechpartner momentan nicht erreichbar ist. Optional kann dabei vorgesehen sein, dass der Endkunde eine Nachricht für den Service-Anbieter hinterlässt.
Falls mit dem vom PC 230 zum Telefon (240, 250) des Servicanbieters ausgehenden Anruf auch die Rufnummer (die der ISDN-Karte des PC zugeordnete Rufnr.) übertragen wird, so erkennt der Servicanbieter natürlich, dass es sich um eine Callbackanforderung handelt und kann z. B. durch Nichtabheben veranlassen, dass der Endkunde über die Nichtverfügbarkeit des Service-Anbieters informiert wird. Anstelle des Nichtabhebens kann der Service-Anbieter aber auch beispielsweise mittels eines weiteren Telefons (z. B. eines Mobiltelefons) eine weitere Rufnummer der ISDN-Karte seines PC 230 anrufen. Der PC kann dann so konfiguriert sein, dass er diesen Anruf auf dieser bestimmten Rufnummer so interpretiert, dass der Service-Anbieter nicht für einen Callback verfügbar ist bzw. das Gespräch nicht annehmen möchte. Damit kann unter Umständen schneller als durch einfaches Nichtabheben die für die Ablehnung einer Callback-Anforderung vorgesehene Prozedur, also die Benachrichtigung des Endkunden über die Nichtverfügbarkeit des Service-Anbieters, eingeleitet werden.
Sollte der Endkunde einen Rückrufzeitpunkt definiert haben (durch Eingabe in das Callback-Formular), so erhält gemäss einem bevorzugten Ausführungsbeispiel der Service-Anbieter zuvor, d. h. bevor er vom PC 230 angerufen wird, eine SMS oder eine email oder beides, etwa mit dem Inhalt " – Hr. xy möchte um xx Uhr angerufen werden". Gegebenenfalls kann er das Gespräch schon jetzt ablehnen, etwa durch Rückruf unter der erwähnten weiteren Nr. der ISDN-Karte. Gemäss einem Ausführungsbeispiel kann der Zeitpunkt des Anrufes in einen Kalender auf dem PC 230 des Service-Anbieters eingetragen werden. Dieser informiert dann den Service-Anbieter zu einem voreingestellten Zeitpunkt vor dem Gespräch und übermittelt evtl. die zum Kunden gehörenden Daten, beispielsweise durch einen Anruf oder die Versendung einer SMS wie bereits oben beschrieben.
Das Verfahren und die Vorrichtung gemäss den Ausführungsbeispielen der vorliegenden Erfindung bietet zahlreiche Vorteile. So muss der PC 230 muss nicht permanent mit dem Host-Server verbunden sein, da ein Triggeranruf mit Rufnummernübergabe erfolgt.
Daneben erfolgt die Abrechnung über die eigene Telefonrechnung des Service-Anbieters und nicht die des Host-Serverbetreibers. Insgesamt wird damit auch einem kleinen Service-Anbieter (z. B. einem Webshop-Betreiber, etwa einem ein Mann-Betrieb) eine praktisch 24-stündige Erreichbarkeit ermöglicht.
Gemäss einem weiteren Ausführungsbeispiel handelt es sich bei dem Trigger-Server 240 nicht um einen getrennten Server, sondern dessen Funktion wird vom Host-Server mit übernommen. Dies verringert die Gesamtzahl der erforderlichen Kommunikationsvorgänge, es macht es aber erforderlich, dass sich der Betreiber des Host-Servers auch hinsichtlich der Funktionalität des Trigger-Servers hardware- und softwaretechnisch die Verantwortung übernimmt.
Gemäss einem weiteren Ausführungsbeipiel kann im Fall, dass der Service-Anbieter nicht erreichbar ist, der PC 230 einen neuen Vermittlungsversuch zu einem vorbestimmten Zeitpunkt, nach einem voreingestellten Zeitintervall unternehmen. Die Kommunikation mit den Partnern (Service-Anbieter und Endkunde), um diese darüber und über den neuen Gesprächszeitpunkt zu informieren, kann der PC 230 mitttels Sprachausgabe oder mittels SMS durchführen.
Gemäss eines weiteren Ausführungsbeispiels erhält der Endkunde im Falle der Nichtverfügbarkeit des Service-Anbieters eine SMS mit der Anfrage eines neuen gewünschten Gesprächstermins, er beantwortet diese SMS, in Reaktion auf diese Antwort veranlasst der PC 230 dann das neue Gespräch und den Informationsaustausch im Vorfeld auf die bereits beschriebene Weise.
Gemäss einem weiteren Ausführungsbeispiel kann für den Fall, dass ein Gespräch nicht zustande kommen kann (Service-Anbieter nicht erreichbar) der PC 230 auch intelligent (ev. nach Auswertung der über den Kunden vorhandenen Informationen, Datenbank, s.o.) auf einen anderen Dienstleister (z.B. ein professionelles Call-Center, einen Hauplieferanten des Kunden, ...) weiterleiten, damit der Kunde einen Service bekommt. Der Service-Anbieter verliert dadurch zwar evetuell für den Moment den Kunden, hat weniger Einnahmen, muss ggf. Zahlungen an andere Dienstleiter leisten, später gegebenenfalls die Provisionen aufteilen, bietet aber seinem Kunden selbst im Falle der Nichtverfügbarkeit einen optimalen Service.
Für den Fachmann ist erkennbar, daß die vorliegende Erfindung mittels handelsüblicher Computer, die mit geeigneter Hardware ausgestattet sind, sowie mittels darauf ablaufender Computerprogramme implementiert werden kann.
Nachfolgend wird noch kurz ein Ausführungsbeispiel gemäß der vorliegenden Erfindung unter Bezugnahme auf das in 3A und 3B gezeigte Flußdiagramm beschrieben.
Im Schritt 300 erfolgt dabei die Callback-Anforderung durch den Endkunden. Im Schritt 310 wird überprüft, ob personenbezogene Daten des Endkunden bereits vorhanden sind. Falls nein, werden diese vom Endkunden im Schritt 320 eingegeben. Liegen die personenbezogenen Daten bereits vor, so kann gleich mit Schritt 330 fortgefahren werden, in dem die personenbezogenen Daten an den Triggerserver weitergeleitet werden.
Der Triggerserver identifiziert dann im Schritt 340 den Server 230 des Service-Anbieters, der von ihm getriggert werden soll. Dies geschieht anhand der personenbezogenen Daten, die vom Host-Server 200 an den Triggerserver übermittelt wurden.
Nach Identifikation des vom Triggerserver anzurufenden Servers des Service-Anbieters führt der Triggerserver im Schritt 350 einen oder mehrere Triggeranrufe durch, um dem Server des Service-Anbieters 230 mitzuteilen, daß ein Callback angefordert wurde, sowie die weiteren personenbezogenen Daten, die den Endkunden betreffen und für die Durchführung des Callback erforderlich sind.
Im Schritt 360 empfängt der Server 230 dann die Callback-Anforderung.
Im Schritt 370 wird in im Server 230 abgelegten Daten oder Datenbanken nachgeschlagen, um zu entscheiden, wie die Callback-Anforderung weiterverarbeitet werden soll. Beispielsweise kann hierunter die Entscheidung fallen, unter welcher Nummer der erste Anruf an den Telefonanschluß des Service-Anbieters durchgeführt werden soll, falls dieser nicht erreichbar ist, welche Alternativ-Rufnummer dann probiert werden soll, ob gegebenenfalls vorab gespeicherte Daten über den Endkunden mit übermittelt werden sollen, etc.
Ist durch Schritt 370 die Entscheidung über die Weiterverarbeitung der Callback-Anforderung getroffen, so wird in Schritt 380 die erste Telefonverbindung aufgebaut.
Im Schritt 390 wird dann überprüft, ob vom Service-Anbieter signalisiert wird, daß der Callback gewünscht wird oder überhaupt möglich ist, beispielsweise abhängig davon, ob der Service-Anbieter erreichbar ist oder nicht. Wird in Schritt 390 festgestellt, daß ein Callback sowohl gewünscht als auch möglich ist, so wird im Schritt 400 eine zweite Telefonverbindung mit dem Endkunden aufgebaut und die beiden Telefonverbindungen werden in Schritt 410 zusammengeschalten.
Wird im Schritt 390 festgestellt, daß der Service-Anbieter entweder keinen Callback durchführen möchte oder daß der Service-Anbieter nicht erreichbar ist, so wird im Schritt 420 der Endkunde hierüber benachrichtigt.
Bei dem in Zusammenhang mit 3A und 3B beschriebenen Ablauf sind weitere Modifikationen denkbar. So ist zum Beispiel denkbar, daß abhängig davon, ob die zweite Telefonverbindung mit dem Endkunden überhaupt aufgebaut werden kann, gegebenenfalls der Endkunde per E-Mail, SMS, oder per Internet benachrichtigt werden kann, daß zwar ein Callback versucht wurde, jedoch keine Verbindung aufgebaut werden konnte.
Weitere Modifikationen der beschriebenen Ausführungsbeispiele sind denkbar. So ist es beispielsweise denkbar, daß die personenbezogenen Daten, die mittels eines Triggeranrufs vom Triggerserver zum Server des Service-Anbieters übermittelt werden, auch mittels eines herkömmlichen Telefonanrufs bzw. mittels Modem vom Triggerserver zum Server des Service-Anbieters übermittelt werden, falls keine ISDN-Verbindung möglich ist. Es ist dann denkbar, daß ein Modem des Triggerservers das Modem des Servers des Service-Anbieters anruft und ihm die personenbezogenen Daten nach Herstellung der Verbindung übermittelt und dann wieder die Verbindung abgebrochen wird. Hier fallen dann zwar Verbindungskosten an, diese Vorgehensweise ist jedoch auch dann möglich, wenn keine ISDN-Hardware und -Software zur Verfügung steht, um die kostenfreie Datenübermittlung mittels ISDN-Subadresse zu ermöglichen.
Erfolgt die Datenübermittlung über eine analoge Verbindung vom Triggerserver zum Server des Service-Anbieters, so ist es vorteilhaft, wenn das Modem beim Server des Service-Anbieters über zwei analoge Kanäle verfügt, damit sowohl der erste als auch der zweite Telefonanruf getätigt und dann beide zusammengeschaltet werden können.
Ist auf Seiten des Servers 230 des Service-Anbieters nur ein Modem mit einer analogen Amtsleitung vorhanden, so kann dennoch unter Zuhilfenahme der Vermittlungsstelle der Callback initiiert werden. Gemäß einer ersten Alternative baut hierzu das Modem die erste Telefonverbindung zu einem Telefon des Service-Anbieters auf, fordert dann bei der Vermittlungsstelle an, daß diese Verbindung gehalten wird, baut dann die zweite Telefonverbindung zum Telefon des Endkunden auf und fordert schließlich von der Vermittlungsstelle die Zusammenschaltung der beiden Verbindungen an. Die Anforderungssignale werden dabei auf bekannte Weise vom Modem beispielsweise mittels Tonwahlsignalen oder ähnlichem an die Vermittlungsstelle übermittelt.
Eine weitere Alternative besteht darin, eine "Dreierkonferenz" aufzubauen. Hierzu fordert das Modem des Servers 230 des Service-Anbieters von der Vermittlungsstelle (dem Telekom-Anbieter bzw. dem Telefonnetzbetreiber) den Aufbau einer Dreierkonferenz an, wobei die drei Teilnehmer das Telefon des Service-Anbieters, das Modem des Servers des Service-Anbieters und das Telefon des Endkunden sind. Die Vermittlungsstelle baut dann diese Dreierkonferenz auf, so daß letztlich ein Datenaustausch zwischen dem Telefon des Endkunden und dem des Service-Anbieters möglich ist, wodurch schließlich der Callback zustandekommt.

Claims

Verfahren zum Implementieren einer Callback-Funktionalität, wobei das Verfahren aufweist: Bereitstellen einer Eingabemöglichkeit auf einer Webseite eines Service-Anbieters auf einem Host-Server, um einem Benutzer an seinem mit dem Host-Server verbundenen Rechner die Anforderung eines Rückrufs (Callback) durch den Service-Anbieter zu ermöglichen; in Reaktion auf die Anforderung des Rückrufs durch den Benutzer, Übermittlung von personenbezogenen Daten des Benutzers von dem Host-Server zu einem dem Service-Anbieter zugeordneten Server, um den Server zu veranlassen, die folgenden Schritte auszuführen: Aufbau einer ersten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Service-Anbieters; Aufbau einer zweiten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Benutzers; Zusammenschalten der ersten und zweiten Telefonverbindung zur Herstellung einer Verbindung zwischen dem Service-Anbieter und dem Benutzer.
Verfahren zum Implementieren einer Callback-Funktionalität, wobei das Verfahren aufweist: Empfang von personenbezogenen Daten eines Benutzers durch einen Server eines Service-Anbieters, wobei die personenbezogenen Daten vom Benutzer über eine Eingabemöglichkeit zur Anforderung eines Callbacks auf einer Webseite des Service-Anbieters auf einem Host-Server eingegeben wurden, um vom Benutzer aus einen Callback des Service-Anbieters anzufordern, der die Webseite betreibt, in Reaktion auf die Übermittlung der personenbezogenen Daten des Kunden vom Host-Server zum Server des Service-Anbieters, Aufbau einer ersten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Service-Anbieters; Aufbau einer zweiten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Benutzers; Zusammenschalten der ersten und zweiten Telefonverbindung zur Herstellung einer Verbindung zwischen dem Service-Anbieter und dem Benutzer.
Verfahren nach Anspruch 1, welches ferner umfasst: Übermittlung der personenbezogenen Daten des Benutzers von dem Host-Server zu einem Trigger-Server anstelle des dem Service-Anbieter zugeordneten Servers, um den Trigger-Server zu veaqnlassen, die folgenden Schritte auszuführen: Aufbau einer Trigger- Wählverbindung von dem Trigger-Server zu dem Server des Service-Anbieters, um die personenbezogenen Daten des Benutzers an den Server des Service-Anbieters zu übermitteln und diesen zu veranlassen, eine Telefonverbindung zu dem Service-Anbieter aufzubauen, wobei in Reaktion auf die Trigger-Wählverbindung kein Abheben durch den Server des Service-Anbieters erfolgt und die personenbezogenen Daten als ISDN-Subadresse übertragen werden.
Verfahren nach Anspruch 2, welches ferner umfasst: Empfang der personenbezogenen Daten durch den Server des Service-Anbieters von einem Triggerserver, der die personenbezogenen Daten von dem Host-Server erhalten hat, wobei die personenbezogenen Daten vom Server des Servicanbieters erhalten werden, indem eine Trigger- Wählverbindung von dem Trigger-Server zu dem Server des Service-Anbieters aufgebaut wird, um die personenbezogenen Daten des Benutzers an den Server des Service-Anbieters zu übermitteln und diesen zu veranlassen, eine Telefonverbindung zu dem Service-Anbieter aufzubauen, wobei in Reaktion auf die Trigger-Wählverbindung kein Abheben durch den Server des Service-Anbieters erfolgt und die personenbezogenen Daten als ISDN-Subadresse übertragen werden.
Verfahren nacheinem der Ansprüche 1 bis 4, wobei die Funktionalität des Trigger-Servers vom Host-Server übernommen wird.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: in Reaktion auf die Callback-Anforderung durch den Benutzer, Öffnen einer Eingabemaske, um dem Benutzer die Eingabe personenbezogener Daten zu ermöglichen.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die personenbezogenen Daten eine oder mehrere der folgenden Daten umfassen: die Telefonnummer des Benutzers, unter der er zurückgerufen werden möchte; der Name des Benutzers; die Kundennummer des Benutzers; die gewünschte Rückrufzeit; der Grund für den Rückrufwunsch; eine weitere Rückruf-Telefonnummer des Benutzers.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die personenbezogenen Daten ganz oder teilweise vorab im Host-Server oder im Server des Service-Anbieters unter einer dem Benutzer zugeordneten ID gespeichert sind und unter Bezugnahme der vom Benutzer eingegebenen ID, gegebenfalls nach erfolgter Authentifizierung, zur weiteren Verarbeitung abgerufen werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Möglichkeit zur Anforderung des Callbacks als auf dem Host-Server abgelegte Webseite implementiert ist, die vom Service-Anbieter über einen Link in seine eigene Seite eingebunden werden kann.
Verfahren nach Anspruch 9, wobei das Öffnen der Callback-Anforderungsseite in Verbindung mit einer den Service-Anbieter als Kunden des Host-Serverbetreibers identifizierenden Benutzer-ID, gegebenfalls zusätzlich mit einer den Endbenutzer identifizierenden Session-ID als Parameter, erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei auf dem Host-Server Konfigurationsdaten abgespeichert sind, die für den Service-Anbieter spezifisch sind und für die Durchführung der Callback-Funktionalität durch den Service-Anbieter erforderlich sind.
Verfahren nach Anspruch 11, wobei die Konfigurationsdaten eine oder mehrere folgender Daten enthalten: die ID des Service-Anbieters, die ihn als Kunden des Host-Serverbetreibers identifiziert; eine oder mehrere der Telefonnummern, unter denen der dem Service-Anbieter zugeordnete Server telefonisch erreichbar ist; Kategorisierungsdaten, die festlegen, wie eine Rückrufanforderung eines Endkunden abhängig von auf den Endkunden bezogenen Daten weiter verarbeitet wird.
Verfahren nach Anspruch 12, wobei die Kategorisierungsdaten einen oder mehrere der folgenden Parameter enthalten, anhand derer über die weitere Verarbeitung der Rückrufanforderung entschieden wird: eine ID des Endkunden; ein gegebenfalls vorhandenes oder nicht vorhandenes Support-Guthaben des Kunden; eine dem Kunden zugeordnete Priorität; ein dem Kunden zugeordnetes Berechtigungsflag, das angibt, ob ein Kunde zur Anforderung eines Rückrufs berechtigt ist.
Verfahren nach Anspruch 11, 12, oder 13, bei dem die Kategorisierungsdaten statt im Host-Server im Server des Service-Anbieters abgelegt sind.
Verfahren nach einem der Ansprüche 11 bis 14, welches aufweist: Überprüfen der Kategorisierungsdaten des den Rückruf anfordenden Kunden; falls die Kategorisierungsdaten die Berechtigung des Kunden zur Anforderung des Rückrufs indizieren, Initiierung des Rückrufs, gegebenenfalls vor oder nach dem Rückruf eines weiteren Endkunden abhängig von der Priorisierung der Endkunden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei im Server des Service-Anbieters Daten abgelegt sind, die festlegen, zu welcher Zeit der Service-Anbieter unter welcher Telefonnummer für den ersten Telefonanruf erreichbar ist.
Verfahren nach Anspruch 16, wobei zu einer bestimmten Zeit mehrere Telefonnummern unterschiedlicher Priorität abgelegt sind, mittels derer nacheinander die Durchführung des ersten Anrufs versucht wird.
Verfahren nach einem der vorherhehenden Ansprüche, wobei falls die erste Telefonverbindung nicht zustandekommt, dem Endkunden eine Nachricht übermittelt wird, dass der Service-Anbieter für einen Rückruf momentan nicht zur Verfügung steht.
Verfahren nach Anspruch 18, wobei die Übermittlung der Nachricht an den Endkunden auf eine der folgenden Weisen erfolgt: Versenden der Nachricht über das Internet an den Rechner des Benutzers, vorzugsweise unter Verwendung der Session-ID der Session des Benutzers; Versenden der Nachricht per SMS; Versenden der Nachricht als email; Durchführen eines automatischen Telefonanrufs durch den Server des Servicebetreibers und Abspielen einer vorab aufgezeichneten Nachricht für den Endkunden.
Verfahren nach Anspruch 19, welches ferner umfasst; Ablegen von Nachrichtenregeln im Server des Service-Anbieters, die festlegen, unter welcher Bedingung der Endkunde auf welche Weise benachrichtigt wird, dass der Service-Anbieter für einen Rückruf nicht zur Verfügung steht.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner aufweist: Bereitstellen einer Möglichkeit für den Service-Anbieter, die Durchführung des Rückrufs abzulehnen, wenn er den ersten Telefonanruf vom Server des Service-Anbieters erhält.
Verfahren nach Anspruch 21, wobei das Ablehnen des Rückrufs durch den Service-Anbieter umfasst: Annahme der ersten Telefonverbindung durch den Service-Anbieter; Vornahme einer vordefinierten Aktion durch den Service-Anbieter, um dem Server des Service-Anbieters zu signalisieren, dass die Durchführung des Rückrufs vom Service-Anbieter nicht gewünscht wird.
Verfahren nach Anspruch 21 oder 22, bei dem die Möglichkeit zum Ablehnen des Rückrufs durchden Service-Anbieter eine der folgenden Aktionen umfasst: Eingabe eines Codes in das Telefon des Service-Anbieters; Auflegen durch den Service-Anbieter zum Beenden der ersten Telefonverbindung; Nichtabheben durch den Service-Anbieter in Reaktion auf die erste Telefonverbindung; Anruf des Service-Anbieters von einem weiteren Telefon unter einer weiteren Rufnummer des Servers des Service-Anbieters.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: falls der Service-Anbieter die Durchführung eines Rückrufs ablehnt, Benachrichtigung des Endkunden, dass der Service-Anbieter momentan nicht für einen Rückruf zur Verfügung steht.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: falls dem Endkunden eine Nachricht übermittelt wird, dass der Service-Anbieter momentan nicht erreichbar ist, Bereitstellen einer Eingabemöglichkeit, um dem Kunden die Eingabe einer gewünschten Rückrufzeit zu ermöglichen, und Benachrichtigung des Service-Anbieters über die vom Kunden gewünschte Rückrufzeit.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: Ablegen von kundenspezifischen Informationen auf dem Rechner des Service-Anbieters; falls eine Rückrufanforderung den Server des Service-Anbieters erreicht, überprüfen, ob für den anfordernden Kunden spezifische Informationen abgelegt sind, falls die Überprüfung ergibt, dass kundenspezifische Daten vorliegen, Übermitteln der kundenspezfischen Daten an den Service-Anbieter bevor die erste und die zweite Telefonverbindung zusammengeschaltet werden.
Verfahren nach Anspruch 26, bei dem die Übermittlung an den Service-Anbieter auf eine der folgenden Arten erfolgt: durch Versenden einer SMS an den Service-Anbieter; durch Sprachausgabe der kundenspezifischen Daten, nachdem die erste Telefonverbindung zustandegekommen ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei dem Service-Anbieter vor dem Zusammenschalten der ersten und der zweiten Telefonverbindung Informationen darüber übermittelt werden, weshalb der Endkunde einen Rückruf wünscht.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner aufweist: Bereitstellen einer Engabemöglichkeit für den Endkunden zur Eingabe eines gewünschten Rückrufzeitpunkts; Übermittlung des gewünschten Rückrufzeitpunkts an den Server des Servicebetreibers; Versenden einer Vorabinformation vom Server des Service-Anbieters an den Service-Anbieter betreffend die Rückrufanforderung und die gewünsche Rückrufzeit, gegebenenfalls zusammen mit weiteren den den Rückruf anfordernden Kunden betreffenden Informationen.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: falls der Service-Anbieter für die erste Telefonverbindung nicht erreichbar ist, erneutes Versuchen des Aufbaus der ersten Telefonverbindung zu einem späteren Zeitunkt gemäss eines im Server des Servicanbieters abgelegten für diesen Fall vorgesehenen Regelwerks.
Verfahren nach einem der vorhergehenden Ansprüche, welches ferner umfasst: falls der Service-Anbieter für die erste Telefonverbindung nicht erreichbar ist, Abfrage einer im Server des Service-Anbieters abgelegten Regelwerks und, falls dieses Regelwerk abhänigig von endkundenspezifischen Daten eine solche Funktionalität vorsieht, Weiteleitung der Rückrufanforderung an einen weiteren Service-Anbieter.
Vorrichtung zur Implementierung einer Callback-Funktionalität, welche aufweist: einen Host-Server, welcher umfasst: eine Einrichtung zum Bereitstellen einer Eingabemöglichkeit auf einer Webseite eines Service-Anbieters auf dem Host-Server, um einem Benutzer an seinem mit dem Host-Server verbundenen Rechner die Anforderung eines Rückrufs (Callback) durch den Service-Anbieter zu ermöglichen; eine Einrichtung, um in Reaktion auf die Anforderung des Rückrufs durch den Benutzer die Übermittlung von personenbezogenen Daten des Benutzers von dem Host-Server zu einem dem Service-Anbieter zugeordneten Server durchzuführen, um den Server zu veranlassen, die folgenden Schritte auszuführen: Aufbau einer ersten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Service-Anbieters; Aufbau einer zweiten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Benutzers; Zusammenschalten der ersten und zweiten Telefonverbindung zur Herstellung einer Verbindung zwischen dem Service-Anbieter und dem Benutzer.
Vorrichtung zur Implementierung einer Callback-Funktionalität, welche aufweist: einen Server eines Service-Anbieters, der auf einem von dem Server separaten Host-Server eine Webseite zum Anbieten eines Services betreibt, wobei der Server aufweist: eine Einrichtung zum Empfang von personenbezogenen Daten eines Benutzers, wobei die personenbezogenen Daten vom Benutzer über eine Eingabemöglichkeit zur Anforderung eines Callbacks auf einer Webseite des Service-Anbieters auf einem Host-Server eingegeben wurden, um vom Benutzer aus einen Callback des Service-Anbieters anzufordern, der die Webseite betreibt, eine Einrichtung um, in Reaktion auf die Übermittlung der personenbezogenen Daten des Kunden vom Host-Server zum Server des Service-Anbieters, eine ersten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Service-Anbieters aufzubauen; eine Einrichtung zum Aufbau einer zweiten Telefonverbindung von dem Server des Service-Anbieters zu einem Telefonanschluss des Benutzers; eine Einrichtung zum Zusammenschalten der ersten und zweiten Telefonverbindung zur Herstellung einer Verbindung zwischen dem Service-Anbieter und dem Benutzer.
Vorrichtung nach Anspruch 32, wobei die Vorrichtung ferner aufweist: eine Einrichtung zur Übermittlung der personenbezogenen Daten des Benutzers von dem Host-Server zu einem Trigger-Server anstelle des dem Service-Anbieter zugeordneten Servers, um den Trigger-Server zu veaqnlassen, die folgenden Schritte auszuführen: Aufbau einer Trigger- Wählverbindung von dem Trigger-Server zu dem Server des Service-Anbieters, um die personenbezogenen Daten des Benutzers an den Server des Service-Anbieters zu übermitteln und diesen zu veranlassen, eine Telefonverbindung zu dem Service-Anbieter aufzubauen, wobei in Reaktion auf die Trigger-Wählverbindung kein Abheben durch den Server des Service-Anbieters erfolgt und die personenbezogenen Daten als ISDN-Subadresse übertragen werden.
Vorrichtung nach Anspruch 33, wobei die Vorrichtung ferner aufweist: eine Einrichtung zum Empfang der personenbezogenen Daten durch den Server des Service-Anbieters von einem Triggerserver, der die personenbezogenen Daten von dem Host-Server erhalten hat, wobei die personenbezogenen Daten vom Server des Servicanbieters erhalten werden, indem eine Trigger- Wählverbindung von dem Trigger-Server zu dem Server des Service-Anbieters aufgebaut wird, um die personenbezogenen Daten des Benutzers an den Server des Service-Anbieters zu übermitteln und diesen zu veranlassen, eine Telefonverbindung zu dem Service-Anbieter aufzubauen, wobei in Reaktion auf die Trigger-Wählverbindung kein Abheben durch den Server des Service-Anbieters erfolgt und die personenbezogenen Daten als ISDN-Subadresse übertragen werden.
Vorrichtung nach einem der Ansprüche 32 bis 35, welche ferner aufweist: eine Einrichtung zur Durchführung eines Verfahrens gemäss einem der Ansprüche 1 bis 31.
Computerprogramm mit von einem Computer ausführbaren Code zur Durchführung eines Verfahrens gemäss einem der Ansprüche 1 bis 31.