nicht angemeldet
Liebe Kolleginnen, Liebe Kollegen!
1. Einleitung
Meine Frage ist vorwiegend Organisationstechnisch angehaucht,
die Frage "welches System" ist dabei *fast* zweitrangig.
Es geht um das definieren von Arbeitsabläufen.
2. Die Firma / Produkte
Vor geraumer Zeit eröffnete ich mein eigenes Dienstleistungsunternehmen
im Bereich Webdesign, Programmierung, neue Medien, etc...
Ein wesentliches Produkt ist die Wartung von Webseiten.
Es gibt Wartungsverträge mit einer definierten maximalen
Anzahl an Wartungseinheiten je Kalendermonat
3. Das Ziel
Bei allen Unternehmen, in denen ich bisher arbeitete, war immer eine
gewisse (teils massive) Form der Unordnung und des Chaos.
Genau das möchte ich verhindern, von Anfang an.
Es sind jetzt bereits Mitarbeiter vorhanden,
und es werden hoffentlich noch mehr.
Einer muss wissen, was der andere tut / getan hat / tun wird.
Wenn mich heute der Kunde X anruft, muss ich wissen wann welche
Email gesendet / Empfangen wurde, welche Anrufe liefen, welche
Meetings angesetzt sind, etc...
Die Lösung schien einfach: Ein CRM muss her ...
Sehr lange teste ich selbst viele Lösungen durch,
und habe anschließend einen ebenfalls sehr langen Entscheidungsprozess hinter mich gebracht.
Die Entscheidung fiel auf "vtiger".
vtiger ist ein OpenSource CRM welches alles mitbringt, was ich brauche - fast ;-)
! Das Beste:
! Sogar die Wartungsverträge sind schon im System vorhanden!!!
! Das heißt: Ein Ticket wird geöffnet, wenn es unter "Support" erfolgreich geschlossen wird,
! zieht das System automatisch 1 Wartungseinheit von der Anzahl der Wartungseinheiten ab.
(Diese Option sollte auch jedes alternativ genannte System mitbringen!)
4. Das ganz große Problem
Dank einer sehr guten Anleitung welche ich im Internet fand, konnte ich vtiger so gestalten,
dass für eingehende E-Mail Anfragen automatisch eine Ticket-ID erzeugt wird, dem Absender
mit der Ticket-ID geantwortet wird, und somit der gesamte Verlauf von Emails sehr, sehr schlüssig überschaubar ist.
Das System konnte somit alles was ich mit wünschte....
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
LEIDER aber mit einer GANZ großen Heimtücke:
Die Tickets funktionieren \_nur\_ dann,
wenn die E-Mail-Adresse des Absenders dem System bekannt ist,
sei es als Person oder Organisation, hauptsache die
Absender-Email-Adresse ist dem System bekannt.
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
Wenn die Email-Adresse des Absenders dem System NICHT bekannt ist,
so wird ein Ticket erstellt, welches auf _niemanden_ zeigt,
und das bedeutet leider wirklich _niemanden_.
Man sieht nicht einmal eine Absender-Mail-Adresse,
ich könnte also nichtmal zurückschreiben.
Das ist generell ein Problem bei _allen_ Tickets, es wird nicht auf
die Absender-Email eingegangen.
(Das umzuprogrammieren versuche ich schon seit heute morgen)
Auch bei dem System bekannten Personen sehe ich _nicht_ die Absender-Email-Adresse.
Das bedeutet, ich antworte möglicherweise an die im System hinterlegte Standard-Adresse,
aber nicht an die Adresse von welcher der Kunde schrieb.
(Wenn da jemand ne Lösung dafür hat, wäre ich dankbar.)
5. Die Organisatorischen Fragen:
! Was wesentlich entscheidender ist:
! Ich weiß nicht, ab wann ich mit dem Ticketing überhaupt beginnen soll.
Ein Bekannter meinte, das sei alles kein Problem.
Anfragen auf alle öffnetlich bekannten Mail-Adressen würde mein Bekannter nur mit
einem Email-Client beantworten ... (ohne tickets also - und das gefällt mir persönlich gar nicht)
Ich solle - so der Bekannte - Tickets nur von einer Kunden-Web-Oberfläche (bietet vtiger) entgegennehmen,
und somit nur bekannte Kunden als Ticket-Erzeuger haben.
Da habe ich 2 Befürchtungen:
a) ich müsste den Kunden erklären, Support-Anfragen nur über ein Web-Portal zu versenden
Damit würde ich dem Kunden die einfache und bequeme Variante mit "ich sende mal eben ne Email" wegnehmen...
b) ich habe das Bedürnis (keine Idee ob das überhaupt gut ist) \_alle\_ Anfragen,
und zwar von _allen_ Email-Adressen der Firma zu Support-Tickets (natürlich mit jeweils anderen Bearbeitern)
zu speichern.
Warum? Stellen wir uns vor, ich bekomme heute eine Anfrage einer mir _nicht_ bekannten Person per Email.
Wir schreiben 5 oder 6 mal hin und her, und es kommt zu einem Abschluss.
\_Spätestens\_ dann wäre ich froh, alle Emails als Tickets mit einer strukturierten Übersicht
im System hinterlegt zu haben, um später jederzeit den ursprünglichen Verkaufsprozess nochmals verfolgen zu können,
und die näheren Wünsche des Kunden wieder ins Gedächtnis zu rufen.
Würde ich ohne Support-Tickets arbeiten, für NOCH-NICHT Kunden, hätte ich diese Möglichkeit nicht.
Selbiges gibt auch, wenn ich Ticket-Systeme von anderen Anbietern heranziehe... Das spätere zuweisen an einen vtiger-Kontakt
wäre nur über Copy & Paste möglich, und verstößt gegen den (guten) Gedanken von vtiger,
bereits ab dem Interessenten (Lead) alles zu dokumentieren.
Viele Unternehmen arbeiten mit OTRS, manche kleine auch mit ostickets,
aber wie bereits geschrieben, das bringt man dann mit vtiger nicht zusammen.
Ich brauche vielmehr eine Erklärung, wie man es sinnvoll strukturiert,
vielleicht mit Fallbeispielen wir ihr es bei euch lösen würdet.
Wie würdet ihr eure Verkaufprozesse und fortlaufende Kundenpflege realisieren?
Vielen Dank
Matthias E.