Kundenmails gehen im gemeinsamen Postfach unter: Lohnt sich ein Open-Source-Ticketsystem?

Der heikelste Punkt bei Open-Source-Systemen ist die Mail-Anbindung rein und raus. Auf Serverseite müssen die Cronjobs für den IMAP-Abruf absolut stabil laufen, und ausgehend müsst ihr DKIM, SPF und DMARC fehlerfrei konfigurieren. Wenn da was klemmt, landet das Ticket vom Kunden nie im System oder eure Antwort versackt unbemerkt im Spam-Ordner.

Führt im gemeinsamen Postfach als Sofortmaßnahme farbige Labels und klare Zuständigkeiten ein, noch bevor ihr die Software wechselt. Wenn nicht morgens eine feste Person den Hut aufhat und die neuen Mails fest an Kollegen zuweist bleiben Anfragen auch mit dem besten Ticketsystem liegen.

Wir hatten letztes Jahr genau dieselbe Sparidee und haben Open Source gehostet. Der Server kostete zwar nur 25 Dollar, aber unser Entwickler saß jeden Monat locker 8 Stunden an Updates und Datenbank-Wartung. Wenn man den Stundensatz gegenrechnet, lagen wir bei über 220 Dollar monatlich. Nach sechs Monaten haben wir entnervt auf eine fertige Cloud-Lösung gewechselt.

Das Problem ist nicht die Software, sondern die interne Kommunikationskultur. Wenn eine E-Mail im geteilten Postfach zwei Tage lang liegen bleibt, liegt das nicht an fehlenden Software-Features – da hat schlicht niemand Verantwortung übernommen. Wenn ihr ein Ticketsystem aufsetzt, werden sich auf dem Dashboard genauso dutzende offene Tickets stapeln, für die sich keiner zuständig fühlt.

wenn wir ein Open-Source-System auf unserem eigenen Server hosten landen die automatiscehn Mails mit der Ticketnummer dann beim Kunden im Spam? ist es sehr kompliziert, das richtig einzustellen?

Edit: Ich habe vom Handy geschrieben, entschuldigt die Tippfehler.

wir hatten mit unserem Viererteam damals genau dieselbe Krise. wenn ein Kunde wütend angerufen hat hat nur jeder den anderen ratlos angeschaut. wir haben dann eine Open-Source-Lösung aufgesetzt – drei Monate später ist beim PHP-Update das ganze Panel abgeschmiert und wir konnten einen kompletten Tag lang keine Kundenanfragen beantworten. den Stress ist das gesparte Geld echt nicht wert.

Edit: Ich habe oben etwas falsch geschrieben, entschuldigung.

Geht vor der Entscheidung mal diese Checkliste durch: 1) Habt ihr das technische Know-how, um mitten in der Nacht einzugreifen, wenn der Server abschmiert? 2) Sind die Kosten für einen externen SMTP-Dienst im Budget eingeplant? 3) Könnt ihr täglich automatische Datenbank-Backups gewährleisten? Wenn ihr diese Fragen nicht mit einem klaren „Ja“ beantworten könnt, lässt euch Open Source früher oder später im Stich.

hier habe ich einen Einwand. naja entscheidend ist nicht die Zahl, sondern worauf sie sich bezieht.

der meiste Zeitverlust etnsteht durch Arbeiten die auf Freigaben warten und viel Erfolg.

Ich schreibe mal meine Erfahrung auf. Neue Kunden zu gewinnen ist teurer als bestehende Kunden zu halten.

Entscheidend ist nicht die Zahl sondern worauf sie sich bezieht.

Vielen Dank, das hat mir sehr geholfen.

Hier lauert eine Falle, die ich nicht unerwähnt lassen möchte. Geht keine Vereinbarung ein, die keinen Exit-Plan hat.

Schau dir an, wo das Loch im Eimer ist; Wasser oben draufgießen löst es nicht. Viel Erfolg.

ich proiere es aus.

Richtig.

Ich bin derselben Meinung. Rechne das über die jährlichen Gesamtkosten, nicht über die monatliche Rechnung.

Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss. Ich hoffe, das hilft dir weiter.

Vor zwei Jahren habe ich genau dasselbe erlebt. Das allein zu versuchen, ist der teuerste Weg.

Wenn man versucht, alles gleichzeitig zu ändern, etabliert sich nichts richtig. Aus Erfahrung weiß ich das.

ich werde das Gegenteil vertreten bitte nicht böse sein dann naja beginnt mit einem kleinen Test bindet nicht gleich alles fest.

das ist meine Meinung ich behauppte nicht, dass es absolut richtig ist.

Bei uns ist es genauso.

die Diskussion ist abgeschweift, ich fasse mal zusammen. schau dir an wo das Loch im Eimeer ist; Wasser oben draufgießen löst es nicht.

an deiner Stelle würrde ich so vorgehen.