Seit 18 Jahren kenne ich Telefonanlagen der Marke Swyx, und die ersten 15 Jahre davon war es Liebe. Inzwischen sind wir auf dem Weg zu einer (langsamen) Scheidung, und auf unserer Firmenwebseite liest es sich, als würden wir langfristig in das Konzept der zukünftigen Swyx bzw. enreach-Gruppe nicht reinpassen. Weil der ein oder andere sich für Hintergründe interessiert, und weil ich hier privat schreibe (und mich darum auch ausk#### darf), hier ein paar mehr Details.

Langfristig nicht mehr ins Konzept reinpassen? Das stimmt auch, das ist Grund Nummer 1. Das Produkt SwyxWare ist für Hosting noch nie besonders gut geeignet gewesen und spätestens auf der letzten Partnerkonferenz konnte man zwischen den Zeilen lesen, dass enreach es auch nicht mehr schaffen wird (und auch nicht mehr schaffen will), SwyxWare "hostbar" zu machen. Also versuchen sie mit ihrem eigenen Hosting "SwyxOn" zumindest so zu tun, als könnten sie Cloud, aber de facto wird das ganze Thema Swyx nur noch am Leben gehalten, bis der Großteil der Kunden bereit ist, in die aus dem Voiceworks-Familienzweig stammende Nachfolgegeneration umzusteigen. Und ab dem Moment wären wir nur noch Vertriebspartner für ein bei enreach gehostetes und mit einer enreach-Carrierleistung versehenes Produkt. Und weder haben wir auf eine derartige Vertriebs-Tätigkeit generell strategisch besonders viel Lust, noch konkret mit enreach, dafür ist zu viel kaputtgegangen.

Was Grund Nummer 2 wäre. Nach 15 Jahren Liebe (und rosaroter Brille) zum Produkt SwyxWare bzw. zur Marke Swyx hat sich ein Mitglied der Geschäftsleitung einen Move erlaubt, der - freundlich ausgedrückt - gar nicht geht. Es gibt eigentlich fast nichts, wie man das Vertrauensverhältnis gegenüber einem Partner mehr schädigen könnte. Details spielen an der Stelle keine Rolle, aber ein Wort der Entschuldigung, oder später irgendwann wenigstens ein "ist irgendwie dumm gelaufen" und der Versuch einer Wiedergutmachung hätten sicherlich noch vieles retten können, statt dessen wurden wir einfach komplett (selbst bei einer Teil-Kündigung unseres Partnervertrages als Eskalationsversuch) anderthalb Jahre lang ignoriert, wir hatten keinen Partner-Manager mehr, darum auch keinen Ansprechpartner für irgendwas, und Gesprächswünsche wurden anderthalb Jahre lang überhört. Was nicht nur unprofessionell ist, was nicht nur emotional dazu geführt hat, dass ich Swyx heute mit einer geballten Faust in der Hosentasche verbinde - sondern ich kann mir auch nicht vorstellen, zukünftig reiner Vertriebspartner/Weiterverkäufer zu sein und im Falle von Problemen weder technisch eingreifen zu können, noch einen Lieferanten zu haben, der mich ernst nimmt. Danke, nein.

Und damit wären wir bei Grund Nummer 3, technische Probleme. Die gibt es, wenn man Swyx heute hosten will, schon genug, und dass die wirklich besser werden, daran habe ich irgendwie meine Zweifel. Diese Probleme sind alle nicht neu (mit denen ärgern wir uns teilweise schon seit 15 Jahren rum), aber durch den Wegfall der rosaroten Brille habe ich einfach keine Motivation mehr, die den Kunden gegenüber wegzulächeln oder ständig eigene Lösungen zu schaffen.

Ich glaube, so ähnlich haben sie sich mal selbst beworben. Tun sie (sicherlich nicht ohne Grund) nicht mehr, denn fehlende Innovation ist eines der großen Probleme.

Vor anderthalb Jahrzehnten war Swyx die Telefonanlage mit dem besten (ansprechendsten) Windows-Client am Markt, damals gab es aber auch noch sehr wenig, und die, die es gab, konnten funktional nichts. Swyx war anders, hatte den Funktionsumfang der Telefonanlage in eine echt coole Windows-Software verpackt. Und ebenfalls zu der Zeit war SwyxWare auch das Produkt mit dem besten Endgeräte-Konzept, was man in meinen Augen für eine "hersteller-unabhängige" IP-Telefonanlagen damals haben konnte: Swyx hat das CorNet.IP-Protokoll von Siemens lizenziert und konnte die optipoint-, später Openstage- und inzwischen OpenScape-Tischtelefone von Siemens/heute unify in HFA-Firmware als echte Systemtelefone steuern.

Und wenn man das verglichen hat mit dem, was die Konkurrenz so zu bieten hatte, war Swyx richtig gut. Zum Vergleich ein paar einfache Features:

• HotDesking (also das Anmelden mit meinem User an einem bestimmten Tischtelefon) haben viele IP-Telefonanlagen damals noch so gelöst: Ich rufe einen Sprachcomputer an, gebe meine PIN ein, die Telefonanlage schickt daraufhin neue AutoProvisioning-Konfiguration an mein Tischtelefon und das Telefon startet neu. Das dauert nicht nur 10 Minuten, ehe ich arbeiten kann, sondern in der Hälfte der Zeit ist der Switch-Port (an dem möglicherweise mein PC hängt und mit Netzwerk versorgt wird) auch noch nicht wieder gestartet.
• Rufumleitungen am Tischtelefon konnten sich bei dem meisten anderen IP-Telefonanlagen nicht mit der Telefonanlage synchronisieren. Das heißt, die Telefonanlage hat das Gerät trotzdem angesteuert (weil sie es nicht wusste), und das hat mit einem "302 moved temporarily" geantwortet, dem die Telefonanlage gefolgt ist. Soweit, so gut, aber wenn man sich vom Telefon abmeldet oder gar es stromlos schaltet, ist auch die Rufumleitung aus. Umgekehrt, wenn man die Rufumleitung vergessen hat auszuschalten, hat man von unterwegs keine Chance, denn die Telefonanlage weiß ja von dieser Umleitung gar nichts, kann sie also auch nicht steuern.
• Die Displayanzeige des Gesprächspartners blieb bei den meisten IP-Telefonanlagen nach dem Verbindungsaufbau unverändert. Klingelt es bei meinem Kollegen und ich picke den Anruf auf Knopfdruck, dann sehe ich im Display nicht die Rufnummer oder den Namen meines Gesprächspartners. Sondern die gewählte Kennziffer für "PickUp". Verbinde ich das Gespräch dann an einen anderen Kollegen und sage ihm vorher, wer dran ist, dann sieht er während des Gespräches dauerhaft meinen Namen (weil ich ihn angerufen habe) statt die Rufnummer des Anrufers.

Das sind nur einige Features, die bei Swyx einfach nahtlos zwischen Software und Hardware genau so funktionierten, wie man es als Kunde erwartet.

Aber: Das ist anderthalb Jahrzehnte her. In der Zwischenzeit hat sich Swyx doch eher behäbig entwickelt. Während alle anderen Cloud-Telefonanlagen natürlich über solche Beispiele wie oben nur müde lächeln und mit den großen Tischtelefon-Herstellern mehr Funktionen realisieren können, als Swyx heute zu träumen glaubt.

SwyxIt!, so heißt der Windows-Client, ist weiterhin der Hauptgrund, warum man sich für eine SwyxWare-Telefonanlage entscheidet. Das Ding ist Softphone oder CTI-Steuerung mit identischer GUI, diese ("Skin" genannt) ist austauschbar von ganz klein ("einfaches Telefon") bis zu bildschirmfüllend ("Telefonzentrale"), lässt sich ans Firmen-CI oder um Sonderwünsche wie WebExtensions anpassen; es gibt verschiedene Betriebs-Szenarien in Verbindung mit Terminal-Servern, es kann TAPI oder einfach die Kurzwahl per F11 und es lässt sich über .NET z.B. an CRM oder Ticketsystem anbinden. Oder noch viel einfacher über die eben schon mal angedeuteten WebExtensions, das sind quasi iFrame-Inhalte, deren URL eventgesteuert und mit Parametern bestückt bei Bedarf geladen wird.

Klingt auch nach rund 20 Jahren, die dieser Client auf dem Buckel hat, immer noch gut. Hat aber aufgrund der alten Code-Basis auch Nachteile. Z.B. dass die WebExtensions standardmäßig noch in einem alten InternetExplorer-Emulator laufen und für moderne Webinhalte nur mit Umwegen brauchbar sind. Oder da wäre die Skin-Technik, die genau das Gegenteil von responsivem Design ist und pixelgenau vorgibt, wie groß der Client aussehen soll. Spätestens, seit es HD- und UHD-Displays gibt, kann es bei falsch ausgewähltem Skin passieren, dass das SwyxIT! unbenutzbar ist, weil entweder ein paar Namenstasten bereits bildschirmfüllend sind, oder umgekehrt alles in Briefmarkengröße angezeigt wird. In einem halben Jahrzehnt, in dem das Problem nun bekannt ist, hätte man m.E. eine Lösung finden können (das SwyxIt! prüft beim Start, welche maximale Auflösung zur Verfügung steht. Und skaliert entsprechend ein zu kleines Skin hoch bei der Anzeige). Statt dessen hat man einfach viele Skins in verschiedenen Varianten, auch als HD und/oder UHD angeboten, und man kann wechseln. Also wenn das Wunsch-Skin in verschiedenen Versionen angeboten wird, denn natürlich wurden nicht alle Skins als HD/UHD bereitgestellt, so manches Feature-Skin feht netterweise. 

Klappt mittelmäßig gut. Nutzt ein Kunde SwyxIt! auf mehreren Rechnern (RemoteDesktop-Sitzung, Büro-PC, Notebook), die verschiedene Auflösungen haben, dann hat er auf einem Gerät immer die Arschkarte. Denn welches Skin eingestellt ist, wird pro User festgelegt und nicht pro Endgerät, d.h. ich muss mich für eines entscheiden, auch wenn das mit einem meiner Geräte kollidiert.

Und bei individuellen Skin-Anpassungen (und gerade dessen Flexibilität ist ja der USP von Swyx) im Hosting hat man auch noch Support-Unzufriedenheit. Swyx' Hauptgeschäft sind Swyx-Partner, die die Anlage verkaufen, aufstellen und übergeben und danach ist alles andere after-sales-Support, den der Kunde bezahlen darf. Wenn der Kunde dann neue Notebooks anschafft und aufgrund besserer Auflösung die Skins neu gebaut werden müssen, freut sich der Swyx-Partner über den Support-Auftrag. Im Hosting sieht das anders aus, der Kunde zahlt jeden Monat eine Grundgebühr dafür, dass er "stets das neuste Produkt" hat und sich nicht um Updates kümmern muss, das ist ja gerade die Werbestory, die man bei Cloud-Produkten erzählt. Und dieser Kunde hat von uns also die neuste Telefonanlage, kauft sich das neuste Laptop und die funktionieren nicht zusammen, weil das SwyxIt! noch auf 10 Jahre alte Display-Technologie ausgelegt ist … dem dann zu erklären, dass es kostenpflichtiger Support ist, ist teilweise schon schwierig.

Und nochmal sind es die Skins, über die man sich ärgern muss. Damit das SwyxIt! nicht so altbacken wirkt, hat Swyx ihm zwischendurch immer wieder ein neues Design verpasst. Vor 2010 waren das regelmäßige Facelifts, die aber eine gewisse Wiedererkennung hatten. 2013 kam dann ein komplett neues Design. 2015 wieder ein komplett neues Design. 2020 wieder ein neues, dieses Mal mit einer nachvollziehbaren Begründung: Es wurde optisch angepasst an die NG-Clients (also Mac und Smartphone), damit da eine Einheitlichkeit reingekommen ist. Diese Einheitlichkeit hat nur so halb lange gehalten, auf der diesjährigen Partnerkonferenz wurde dann wieder das nächste Design vorgestellt (die nächste Einheitlichkeit - die Kunden sollen schon mal optisch an das Nachfolgeprodukt gewöhnt werden). Wenn der Client alle paar Jahre sein Skin wechselt (ohne mehr zu können. Nur sind die Funktionen halt woanders) ist das im laufenden Support sehr nervig.

Ebenfalls ist nervig, wenn jahrelang bekannte Fehler einfach nicht behoben werden und zu Support führen. Schlimmer noch: Wenn sie verschlimmert werden. Wenn die Uhrzeit von Client und Server mehr als fünf Minuten abweicht, das weiß wohl inzwischen jeder Swyx-Partner, dann ist ein Login nicht möglich. Und ebenfalls jeder Swyx-Partner kennt auch die unsinnige Fehlermeldung, die der Client dann anzeigt: "Die Version des SwyxServers ist nicht kompatibel". Das Problem besteht mindestens seit Version 10 (also schon seit rund 10 Jahren) und die bekommen es einfach nicht in den Griff, einfach mal die Fehlermeldung so anzupassen, dass der Kunde nicht den Partner mit unnötigem Support belästigen muss. Nein, was machen sie statt dessen: Sie verschlimmbessern die Anmeldung. In den aktuellen Versionen kann es auch sein, dass die Fehlermeldung behauptet, die Zugangsdaten seien falsch. Der Kunde ändert dann fluchend sein Passwort mehrfach (verursacht also internen Support-Aufwand bei seiner IT), kommt nicht weiter, dann kontaktiert er uns (inzwischen klingt das Fehlerbild eher nach "User ist komplett verkonfiguriert und erlaubt gar keinen Login"); weil wir natürlich die Passwörter der Kunden auch nicht wissen wollen und darum auch nicht selbst testen können (also evtl. erstmal wieder selbst das Passwort ändern und es ausprobieren und dem Kunden schreiben, dass alles ok ist), ist der Supportaufwand am Ende deutlich höher, bis wir dann merken: Deine Uhrzeit geht falsch.

Womit wir beim nächsten Thema sind, was mit Support-Aufwand verbunden ist. Irgendwann ich glaube 2014/2015 hat Swyx den RemoteConnector eingeführt und damit erstmals die Möglichkeit, auch ohne VPN über das öffentliche Internet SwyxIt! mit seinem Server zu verbinden. Wirklich ein Quantensprung! Und der RemoteConnector funktionierte anfangs so gut, dass niemand sich am Mehr-Konfigurationsaufwand gestört hat. Doch der ist gar nicht mal ohne: Der User braucht ein Zertifikat. Anstatt das einfach (wie alle anderen Dinge, die der User ja auch technisch braucht - Lizenzen, Rufnummernzuweisungen, Beispiel-Callroutings) beim Anlegen des Users automatisch auszurollen, muss man das als Administrator nachträglich anstoßen. Und wenn man das SCC (SwyxControlCenter, also das Konfigurations-Webinterface) benutzt hat, mit dem man fast alles machen kann, muss man in die Windows-Adminsoftware wechseln, denn genau dieser eine Schritt geht nicht im SCC. Ich habe in meinen Swyx-Tipps u.a. ein PowerShell-Script veröffentlicht, was die fehlenden Zertifikate einfach vollautomatisch anlegt, denn das ist ja keinem Kunden zuzumuten. (Immerhin: Nach nur 7 Jahren hat Swyx eine solche Anlege-Automatik selbst bereitgestellt).

Jetzt muss das Zertifikat auf das Endgerät drauf. Dass das einfach geht, sieht man an den sog. NG-Clients (MacOS, iOS, Android): Die sind in der Lage, sich per https-Verbindung über eine API das Zertifikat vom Server abzuholen und darüber die Verbindung aufzubauen. So braucht man lediglich Servername, Username und Passwort und tatsächlich kann auch ein Laie diese Clients in Betrieb nehmen. So würde ich es nach 8 Jahren RemoteConnector auch heute im SwyxIt! erwarten.

Ist aber nicht so. Im Windows-Client SwyxIt! wird das Zertifikat "automatisch ausgerollt", wenn der Client eine direkte Verbindung (bzw. im Hosting: VPN) zum Server hat. Über's Internet ohne VPN geht das so nicht. In den ersten Versionen konnte man sich über's Internet immerhin mit dem SwyxServer verbinden, zwar konnte man das SwyxIt! nicht benutzen (weil es nicht NAT-geeignet ist), aber zumindest wurde das Zertifikat übertragen, so dass man danach im SwyxIt! einfach den RemoteConnector nachträglich aktivieren konnte. Seit ein paar Versionen geht auch das nicht mehr.

Also muss das Zertifikat auf dem Server exportiert werden (und das geht natürlich nur: Über die Windows-Admin-Software als Administrator. Über das SCC, oder gar für den Benutzer selbst: Keine Chance). Dabei ist auch das eigentlich kein großes Ding, auch hierfür habe ich in meinen SwyxTipps damals schon Lösungen bereitgestellt.

Hat der User das Zertifikat, dann muss er es noch installieren (mit einer Besonderheit, die man beachten muss), dann muss man im SwyxIt! das noch manuell konfigurieren, und dann muss man beten, denn in so etwa 20% der Fälle kommt inzwischen die Fehlermeldung "Verbindung zum RemoteConnector fehlgeschlagen" und dann hilft meistens, den Vorgang einfach drölf Mal zu wiederholen. Wir haben damals in unserer kleinsten "Self-Service-Cloudprodukt"-Produktlinie noch eine Installationsanleitung gemacht und 20 Euro Gebühr genommen, wenn wir die Einrichtung per Fernwartung machen sollen, inzwischen machen wir das kostenlos, aber mancher Support-Kollege traut sich selbst nicht, das per Fernwartung zu machen, weil man einfach jedes fünfte Mal hilflos vor "Verbindung zum RemoteConnector fehlgeschlagen" steht.

Nicht zu vergessen die Probleme, die der RemoteConnector mit sich bringt. Im Terminalserver-Betrieb ist er offiziell nicht freigegeben (Grund/Abhilfe siehe meine SwyxTipps), in Verbindung mit VisualContacts/DATEV führt er zu einem DeadEnd in der Konfiguration (Abhilfe siehe meine SwyxTipps), irgendwann hat Swyx ihn mal so umgebaut, dass wenn der gleiche User mehrfach über den RemoteConnector eingeloggt war (z.B. SwyxIt! und SwyxMobile-App), sich die beiden nach ein paar Minuten gegenseitig rausgeworfen haben (ist dann irgendwann gefixt worden) und vieles andere mehr.

Wie an anderer Stelle auch haben wir damals überlegt, ob wir nicht in Eigenregie die Installation vereinfachen sollen (einen eigenen Installer schreiben, der sich per Schnittstelle das Zertifikat runterlädt, importiert, in der Registry alle Einstellungen setzt und dann erst SwyxIt! runterlädt und installiert). Damals hieß es, mit der Version 12 würde das Zertifikatshandling deutlich verbessert und im Vertrauen darauf haben wir unsere Überlegungen eingestampft. Die Verbesserung war, dass jetzt ein weiterer Klick nötig ist.

Die Verbesserungen in Version 12, die keine waren, bringt mich zum nächsten Thema: Versionsmanagement. Die Version 12.00 war eine Major-Version (also ein Sprung vor dem Komma), da erwartet man in jedem anderen Softwareprodukt große Änderungen. Und die 12.10 war eine Minor-Version (also ein Sprung nach dem Komma), da erwartet man kleinere Änderungen, Bugfixes, vielleicht eine Unterstützung eines neuen Tischtelefons-Modells oder ähnlichen Kleinkram.

Bei Swyx ist es traditionell anders, auch in den Minor-Versionen verstecken sich manchmal ganze Hammer, die Dir das komplette Hosting-Konzept um die Ohren hauen. Unter der Haube hat sich beim Wechsel von 11.x auf 12.00 recht wenig geändert, dafür wurde bei der Minor-Version 12.10 die interne Ansteuerung der Yealink-Tischtelefone mal eben komplett geändert. Mit anderen Ports für die Firewall und unsere eigene VPNless-Umsetzung (super, wenn man im Hosting durch ein Support-Ticket davon erfährt, weil irgendwo was hakt). Und mit einer neuen Firmware, die auf den Tischtelefonen ausgerollt wird und die das Telefon anschließend für andere Mitbewerber unbrauchbar macht, aber auch einen Firmware-Wechsel verbietet ("OEM-Version unterschiedlich"). Immerhin, nur ein halbes Jahr später hat Swyx es dann mal geschafft, in einem Hilfeartikel zu erklären, dass das so ist und wie man das Telefon wieder auf normale Firmware zurücksetzen kann. Da man als Partner natürlich von derartigen Hilfeartikel auch nur durch aktives Suchen erfährt, macht das gegenüber einem kündigenden (und meistens ohnehin schon nicht so zufriedenen) Kunden einen tollen Eindruck, wenn man ihm den Wechsel zum Konkurrenzprodukt erschwert, in dem an steif und fest behauptet, es gäbe keine Firmware-Bindung an Swyx, weil das damals noch nicht öffentlich war.

Das ist leider keine Ausnahme, sondern Alltag, mit dem man sich als Swyx-Partner rumärgern muss. Im Versionszweig 11 gab es eine, die hat Datenmüll verursacht - Problem sei bekannt, die Version sei auch zurückgezogen worden, aber eine Info darüber an die Partner gab es nicht. (Argument: Ja, aber man kann sich die ja gar nicht mehr runterladen bei uns, sondern nur noch den Vorgänger … tolles Argument, dass wir als Hosting-Partner natürlich nicht jedes Mal die DVD neu vom Swyx-Webserver runterladen, entpacken, ein paar Änderungen vornehmen für die Installation im Hosting, sondern dass wir das einmal pro Version machen und die dann bei uns vorhalten, daran haben sie wohl nicht gedacht). Ebenfalls im 11er Zweig gab es wieder ein eine Minor-Version, in der das Autoprovisioning zu Yealink so geändert wurde, dass wir per Support-Ticket bei Swyx die IP-Adressen unserer Hosting-Infrastruktur mitteilen mussten. Erfahren haben wir davon natürlich erst, als ich beim Kunden einen Vor-Ort-Einsatz abbrechen musste, weil ich keine Yealink-Telefone konfigurieren konnte. 

Die gleiche Version hatte auch einen Bug, in dem die wohl wichtigste Funktion im CTI-Betrieb, nämlich "F11" nicht mehr funktionierte, sie vergaß - aber nur in Kombination mit Yealink-Telefonen - die führende Amts-Null. Ja, Bugs können auftreten, aber wenn sie im Hause Swyx bekannt sind (und das war hier der Fall), dann finde ich es angemessen, das den Partnern zu sagen. Dann kann ich entscheiden, ob ich mit dem Bug lebe, ob ich eine ältere Version installiere, oder ob ich (so, wie wir es aus der Not heraus dann gemacht haben) einen Patch baue. Aber den Partner in die Falle laufen zu lassen, damit der dann beim Kunden bemerkt, dass was nicht stimmt, das ist Murks. Zwei Versionen später gab es einen ähnlichen Bug in Kombination mit CTI/PickUp/unify-Telefonen, der stand nicht mal auf der Liste der "known bug"-Liste (d.h. den hätte man nicht mal erahnen können), obwohl er bekannt war.

Aber leider ist das bei Swyx Alltag. So ziemlich jeder Swyx-Partner kann sich noch an das Thema MediaBridge erinnern, Swyx bestreitet glaube ich bis heute, dass es zwischen 10.20 und 10.30 eine Änderung am T.38-Verhalten gab, und trotzdem ist das Netz voll von Tipps, dass man das dadurch entstandene Problem per RegistryKey lösen kann. Und irgendwann in der 12er Version funktionierten bei manchen Installationen die Besetztlampen nicht mehr. Die Abhilfe ist ein Powershell-Befehl zum Umstellen der Signalisierung auf TCP, doch der Hilfeartikel fängt nicht etwa an mit den Worten "wir haben irgendwas geändert, und seit dem treten Probleme auf". Sondern er liest sich so, als wäre die Ursache ganz woanders (unsauberes VPN, instabiles Netzwerk, …) zu suchen und die TCP-Umstellung würde lediglich helfen, die Übertragung zuverlässiger zu machen. Ja, ne, is klar.

Und nochmal ist es das Thema "Versionen", was zu nervigem Support führt: Wann immer Swyx eine neue Version rausbringt, landet sie zuerst auf der Webseite, und in der Folgenacht werden die Partner per Newsletter informiert. Nun ist der SwyxIt!-Client nur in eine Richtung kompatibel, man kann den Server aktualisieren, ohne dass die Clients mitziehen müssen (diese Richtung ist auch sinnvoll). Andersherum geht es aber nicht, d.h. es gab schon Fälle, wo wir dem Kunden die neuste (uns bekannte) Version bereitgestellt haben, und als der Kunde eine Stunde später den Client runterlädt, funktioniert der nicht (weil Swyx zufällig gerade eine neue Version freigegeben hat und damit der Client nun zu neu ist, aber wir als Partner davon noch gar nichts wussten). Okay, das kann man noch mit Humor sehen. Und das Argument "wir setzen nicht immer auf die neuste Version, wir gucken uns die erstmal selbst ein paar Wochen an, ob wir die auf Kunden loslassen wollen" versteht jeder Kunde.

Der Humor hört auf in dem Moment, in dem der Kunde nur noch diesen neusten Client runterladen kann. Die alten Versionen verstecken sich seit einigen Jahren schon hinter einem Passwort-geschützten Partnernet-Link (oder auch hier wieder: In meiner Link-Liste der SwyxTipps), d.h. der Kunde hat keine Chance, sich seine passende Version runterzuladen. Auch das mag bei dem typischen "Verkauf, Installation, Abnahme, Warten auf Folgegeschäft"-Swyx-Partner als Vorteil gesehen werden (der Kunde muss sich an den Partner wenden, und der verkauft ihm bei der Gelegenheit das Update). Im Hosting ist es einfach nervig, wenn der Kunde unseren Support bemühen muss, weil er sich nicht selbst helfen kann. Und noch nerviger ist es, dass wir derartige Kleinigkeiten wie den vorgeschalteten Passwortschutz mal wieder nur von Kunden erfahren und nicht vom Hersteller, denn das nimmt uns die Chance, unsere daraufhin gebaute Lösung (natürlich kann sich bei uns jeder Kunde inzwischen seine passende Version im Kundenmenü runterladen) rechtzeitig fertigzustellen.

Tja, was soll ich sagen. Mit jedem Schritt, den Swyx nach vorne macht, machen sie auch einen nach hinten. Sie haben damals PowerShell-Automatisierung eingeführt, dann haben sie Yealink-Tischtelefone ins Portfolio aufgenommen, aber was haben sie vergessen? PowerShell-Befehle, um Yealink-Tischtelefone einzurichten. Das SCC war lange Zeit noch unbrauchbar, weil man nur 80% da konfigurieren konnte und dann doch für den letzten Klick die Windows-Adminsoftware brauchte. Die Mac- und Smartphone-Clients wurden auf den Markt gebracht gerade rechtzeitig, um "immerhin haben wir einen MAC-Client, viele andere Mitbewerber haben das nicht" sagen zu können. Doch während bei anderen Produkten heute der Mac- mit dem Windows-Client gleichgezogen ist, ist er bei Swyx bis auf ganz wenige Funktionen auf diesem Stand von vor 5 Jahren geblieben und ist jetzt im "maintenance mode", was soviel bedeutet wie "es werden keinerlei Entwicklungskapazitäten mehr da reingesteckt" (bis wann eigentlich? Bis die ganze SwyxWare m.E. abgeschafft wird, weil die Voiceworks-basierenden Produkte in der enreach-Familie einen adäquaten Ersatz darstellen).

Und so verfallen dann leider auch Funktionen, die eigentlich noch weiter funktionieren können. Jahrzehntelang konnte man einstellen, wann ein User als "online" gelten soll - Tischtelefon rund um die Uhr aktiv, aber den PC abends zu und damit SwyxIt! offline, schon wusste die Swyx, dass dieser User nicht mehr da ist und kann das farblich den Kollegen anzeigen (Präsenzstatus) bzw. im CallRouting darauf eingehen. Außer … ja außer, man nutzt neue Endgeräte oder die NG-Clients, denn die wurden vergessen da als EndgeräteTyp nachzupflegen, die kann man nicht mehr voneinander unterscheiden. Oder das CallRouting, egal ob mit oder ohne grafischem Scripteditor - sicherlich auch heute noch das geilste Feature einer SwyxWare-Telefonanlage und ein "wow-Effekt" bei jedem Kunden. Aber es läuft halt nur unter Windows, die anderen Clients können es nicht. Zumindest eine "besser als gar nicht"-Unterstützung (ich kann mangels Windows-Editor die Routings nicht ändern. Aber ich sehe, welche es gibt und kann sie aktivieren/deaktivieren) hätte man in 10 Jahren wohl hinbekommen können, wenn man gewollt hätte.

VPN-loser Betrieb für Tischtelefone ist seit fast einem halben Jahrzehnt im Gespräch. Dass es möglich ist (zumindest für Yealink. Mit ganz viel Mühe und dennoch ein paar Einschränkungen haben wir es sogar für unify hinbekommen) haben wir vor 8 Jahren bewiesen, und auch andere Swyx-Hosting-Partner haben nachgezogen. Nur enreach bekommt es nicht hin. Das Problem auch hier: Sie versprechen es auf jeder Partnerkonferenz auf's Neue (so auch wieder dieses Jahr). Das macht es für uns unwirtschaftlich, in unsere eigene VPNless-Implementierung Geld in weitere Features reinzustecken (was nötig wäre). Und so vertrösten wir bzgl. der Features jetzt schon das vierte Jahr in Folge unsere Kunden.

Fairerweise muss man dazu sagen: Als Telefonanlage für einen "technisch passenden" Endkunden ist SwyxWare immer noch eine sehr gute Wahl. Und insbesondere auch in dem Segment (Firmengrößen, IT-Struktur), in dem die typischen Swyx-Partner unterwegs sind. Nur eben im Hosting nicht (das hat enreach wohl auch selbst eingesehen). Dass wir trotzdem gute Produkte daraus gebaut haben, war viel liebevoller Eigenregie zu verdanken, in Themengebieten, die eigentlich Aufgabe des Herstellers wären.

Aber andere Hersteller haben in den letzten anderthalb Jahrzehnten funktional längst gegenüber Swyx aufgeholt, und was Betriebskonzepte und "Einfachheit im Hosting" angeht, lassen sie Swyx links liegen. 

Das tun wir daher jetzt inzwischen auch. Nach langen Überlegungen (auch bei der Frage, ob ich mich nochmal in ein anderes Telefonanlagen-Produkt einarbeiten will) setzen wir jetzt auf Communi5 (ehemals Teles C5-Plattform), eine Lösung, die wirklich einfach nur für Carrier, die stressfrei in großem Stil etwas anbieten wollen, gedacht ist. Die ich ähnlich lange kenne (noch als "Kapsch CarrierCom MissiSIPpi" vor rund 18 Jahren kennengelernt) wie die Swyx. Von einem Lieferanten, mit dem wir gemeinsam unser Telefonnetz auf einer Teles C4-Plattform aufgebaut haben und der den operativen Betrieb komplett übernommen hat (d.h. wir sind zukünftig vom gleichen Anbieter und der gleichen Technik-Plattform abhängig, auf der heute auch schon unser Telefonnetz läuft). Und das ganze mit einer gesunden Mischung aus "Flexibilität für Kundenwünsche" und gleichzeitig "wir hosten nix mehr selbst und haben es einfacher".

Ach ja, und bei unserem früheren JointVenture-Partner und heutigem Lieferanten sowieso, aber auch bei Communi5 ist der Umgang uns gegenüber heute genauso herzlich und unkompliziert, wie bei der "früheren" Swyx Solutions AG vor der enreach-Fusion...