Die 3CX-Telefonanlage bietet viele Möglichkeiten bekannte CRM-Systeme anzubinden. Als weiteres ist es möglich Datenbanken auf Basis von MongoDB, MySQL, MS SQL und PostgreSQL abzufragen.
Vorteil der Integration ist, das man bei einem eingehenden Gespräch gleich sieht wer anruft. Je nach Grad der Integration öffnet sich automatisch bespielsweise die Kunden-Historie im CRM. Ein weiterer Pluspunkt ist das Entfallen der Pflege mehrerer Adressdatenbanken. Wenn man den Kunden- und Lieferanten-Stamm sowieso im CRM hat, macht es wenig Sinn parallel dazu das Anlagenadressbuch zu pflegen.
Seitens 3CX wird JTL-Wawi nicht nativ unterstützt, allerdings kann direkt der zugrundeliegende MS SQL-Server angesprochen werden. Zu diesem Zweck muss der Datenbankserver für die Telefonanlage erreichbar sein, d.h. gegebenenfalls Firewall und Port Server-seitig konfigurieren.
Die grundlegende Verbindungskonfiguration stellt keine allzugroße Hürde dar. Schwieriger ist da schon die richtige Query zu ermitteln. Innerhalb der Datenbank speichert JTL-Wawi in drei unterschiedlichen Tabellen die Kunden, Lieferanten und Ansprechpartner ab. Hinzu kommen Unterschiede in der Gross-/Kleinschreibung bei der Bezeichnung der Tabellennamen sowie Spalten und dann noch Schreibfehler.
- An der 3CX Verwaltungskonsole anmelden.
- Zu „Einstellungen – CRM-Integration“ wechseln.
- „Database Ms SQL“ auswählen.
- Konfigurieren wann die Datenbank abgefragt werden soll. Möglich ist immer oder nur wenn ein Kontakt nicht im internen Anlagenadressbuch vorhanden ist.
- Bei „Server:“ den FQDN oder die IP-Adresse des Datenbankserver eingeben.
- Bei „Database:“ für JTL-Wawi „eazybusiness“ eintragen.
- Bei „Username:“ und „Password:“ die Zugangsdaten eingeben. In der Voreinstellung von JTL wäre das „sa“ und „sa04jT14“.
- Unter „Lookup SQL Statement:“ die Datenbankabfrage (Query) eintragen.
An dieser Stelle wird es dann, wie angedeutet, mitunter kniffelig.
Folgende Tabellen mit Kontaktdaten gibt es:
- tAdresse (Kunden)
- tansprechpartner (Ansprechpartner sowohl bei Kunden als auch Lieferanten)
- tlieferant (Lieferanten)
Bereits an dieser Stelle fällt die unterschiedliche Namensgebung auf. Für jede dieser Tabellen sieht die jeweilige Query beispielsweise wie folgt aus:
SELECT kAdresse as contactid, cFirma as companyname, cVorname as firstname, cName as lastname, cMail as email, cTel as phonebusiness, cMobil as phonemobile, cFax as faxbusiness FROM tAdresse WHERE cTel LIKE '%[Number]%' or cMobil like '%[Number]%' or cFax LIKE '%[Number]%' SELECT kAnsprechpartner as contactid, cAbteilung as companyname, cVorName as firstname, cName as lastname, cMail as email, cTel as phonebusiness, cMobil as phonemobile, cFax as faxbusiness FROM tansprechpartner WHERE cTel LIKE '%[Number]%' or cMobil like '%[Number]%' or cFax LIKE '%[Number]%' SELECT kLieferant as contactid, cFirma as companyname, cVorname as firstname, cNachname as lastname, cEMail as email, cTelZentralle as phonebusiness, cTelDurchwahl as phonemobile, cFax as faxbusiness FROM tlieferant WHERE cTelZentralle LIKE '%[Number]%' or cTelDurchwahl like '%[Number]%' or cFax LIKE '%[Number]%'
Auch hier wieder Unterschiede wie „cMail“ und „cEMail“. „cTel“ wiederum gibt es nur in „tAdresse“ und „tansprechpartner“, aber nicht unter „clieferant“. Auf der anderen Seite gibt es „cTelZentralle“ (kein Schreibfehler von mir, steht wirklich so in der Datenbank) und „cTelDurchwahl“ nur unter „clieferant“.
Da mehrere Einzelabfragen in der 3CX nicht möglich sind, müssen diese drei zu einer Abfrage kombiniert werden. Möglich ist dies mit „UNION“. Schlicht bei der zweiten und dritten Abfrage ein „UNION“ voranstellen und alle drei Zeilen kopieren und in der 3CX einfügen.
SELECT kAdresse as contactid, cFirma as companyname, cVorname as firstname, cName as lastname, cMail as email, cTel as phonebusiness, cMobil as phonemobile, cFax as faxbusiness FROM tAdresse WHERE cTel LIKE '%[Number]%' or cMobil like '%[Number]%' or cFax LIKE '%[Number]%' UNION SELECT kAnsprechpartner as contactid, cAbteilung as companyname, cVorName as firstname, cName as lastname, cMail as email, cTel as phonebusiness, cMobil as phonemobile, cFax as faxbusiness FROM tansprechpartner WHERE cTel LIKE '%[Number]%' or cMobil like '%[Number]%' or cFax LIKE '%[Number]%' UNION SELECT kLieferant as contactid, cFirma as companyname, cVorname as firstname, cNachname as lastname, cEMail as email, cTelZentralle as phonebusiness, cTelDurchwahl as phonemobile, cFax as faxbusiness FROM tlieferant WHERE cTelZentralle LIKE '%[Number]%' or cTelDurchwahl like '%[Number]%' or cFax LIKE '%[Number]%'
Tipp: Damit man nicht alles in einer Zeile bearbeiten, tippen, etc. muss kann man beispielsweise in Notepad++ jede „SELECT“ bzw. „UNION SELECT“-Zeile einzeln editieren. Am Ende dann alle drei Zeilen markieren und in die 3CX einfügen.
Wie man sieht habe ich bei der Abfrage von „tlieferant“ der Einfachheit halber geschummelt und die Durchwahl als Mobil-Nummer übergeben. Im Regelfall stehen bei uns keine Durchwahlen im Lieferranten-Kontakt drinnen, sondern werden unter Ansprechpartner gepflegt.
Soweit die „Minimal-Abfrage“ durch die 3CX gegenüber JTL-Wawi bzw. dessen MS SQL-Server.
Woher stammt der Kontakt?
In der 3CX Verwaltungskonsole ist unter „Erweitert – Kontakte“ erkennbar, welchen Ursprung der Kontakt hat, also ob intern oder CRM:
An gleicher Stelle können Kontakte aus der Telefonanlage gelöscht werden. CRM-Kontakte werden bei der nächsten Abfrage bzw. erneutem Anruf neu angelegt.
Rufnummernformat und Anrufererkennung
Wie gut oder schlecht eine Rufnummer erkannt wird ist zum einen davon abhängig, wie viele Stellen verglichen werden. Konfigurierbar ist das in der Verwaltungsoberfläche unter „Erweitert – Kontakte – Optionen“:
Als nächstes kommt es zudem darauf an, wie die Rufnummer in der Datenbank eingetragen ist. Im einfachsten Fall hat man die Rufnummern ohne jedweden „Schnickschnack“ hinterlegt.
Weiteres:
Was letztlich im Display des Telefons, in der 3CX App oder im Web-Interface angezeigt wird, ist von mehreren Faktoren abhängig: Zu allererst wie der Kontakt im Adressbuch- (Persönlich wie auch Anlage!) bzw. im CRM hinterlegt ist, dann ob ggf. Regel- und/oder Signalisierungsgruppennamen greifen.
Erfahrungswerte und Meinung
Bis jetzt, sind ja erst ein paar Tage, läuft das soweit relativ gut. Unschön ist, das anscheinend erst ab dem zweiten bekanntem Anruf der Name angezeigt wird. Ungut finde ich persönlich hingegen, das in umgekehrter Richtung, also wenn man selbst eine Nummer wählt oder einen Namen eingibt, keine Auflösung gegenüber der Datenbank stattfindet. Der Workflow ist anscheind darauf ausgelegt, das man aus dem CRM heraus arbeitet, was soweit ja erstmal in Ordnung ist. Ist man allerdings unterwegs und sucht einen Kontakt, beispielsweise einen Ansprechpartner, und dieser ist noch nicht im Anlagenadressbuch enthalten, so zieht man sozusagen den kürzeren.
Was aktuell noch nicht funktioniert ist die Aktualisierung eines Kontakt bei Änderungen in der Datenbank. 3CX setzt dazu allem Anschein nach zwingend eine URL voraus.
Danksagung
Vielen Dank an Martin Schittig von Die Schittigs GmbH für die Unterstützung bei der Ermittlung der Datenbankabfrage.
Links:
3CX – Docs – Adminhandbuch – Konfigurieren der Microsoft Office-/CRM-/Datenbank-Integration
3CX – Integrieren Sie Ihre Telefonanlage mit Ihrem CRM-System
3CX – Docs – Microsoft SQL Server, MySQL, PostgreSQL Database Integration on the Server Side
3CX – Docs – Integrating a CRM with 3CX
w3schools – SQL – SQL UNION Operator
Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.
