Besuchsberichte best practice

Hallo Liebe Forenanwender,

ich arbeite in Hannover bei einem Dienstleistungsunternehmen und führe im Vertrieb gerade MS CRM 2011 ein.

Eigentlich bietet MS CRM erst mal alles was man braucht, jedoch fehlt der Besuchsbericht.

Nun gibt es ja unzählige Möglichkeiten diesen zu konfigurieren, was wäre denn das best practice ?

Der Bericht als solcher kann ruhig Freitext sein, es wäre halt gut wenn man prüfen könnte ob es zu jedem Termin auch einen Bericht gibt,
der Bericht sollte quasi als Historie in der Liste der Aktivitäten beim Kunden/Verkaufschance sichtbar sein und von allen Anwendern gelesen werden können.

Die Überprüfung würde ich gerne am Ende über einen Report "Zeige Termine ohne Besuchsbericht" für alle VBs einmal im Monat o. ä. ausgeben lassen.

Hat jmd. so etwas schon mal gemacht und einen Tip wie man das am Besten abbildet ?


Besten Dank im Voraus,

Reno

Hallo Reno,

ich gehe mal davon aus, dass für jeden Besuch im Vorfeld ein Termin definiert ist, spontane Besuche kann man ja auch kurzfristig eintragen.

Wenn der Besuchsbericht "nur ein paar Felder" haben soll, dann kannst du ruhig über eine Felderweiterung beim der CRM-Entität- Termin nachdenken. Die Prüfung ist dann einfach: das Protokollfeld darf nicht leer sein.

In einem anderen Projekt haben wir für Besuchsberichte eine Custom-Entity erstellt. Bei dem Kunden wurden dann intensiver geplant (Felderweiterung in Entität Termin) und Ergebnisse exakter hinterlegt (neue Custom Entity Besuchsbericht). Es gab in dem BB-Formular z.B. spezielle Felder für die angesprochenen Maschinen und das Anwendungsumfeld beim Kunden, für die nächsten Schritte und Nachbearbeitungsschritte für technische Kollegen etc.

Wir haben dabei den Besuchsbericht automatisch über einen Workflow für die Entität Termin erstellt. Da sich Ort, Dauer und Teilnehmer bis ein paar Stunden vor dem Start noch verschieben können, habe wir den Workflow ein paar Stunden nach dem Beginn des Termins ausgelöst und viele Felder aus dem Termin übernommen (Ort, Beteiligte, Dauer, Startzeit, Thema, Planungsdaten). Die Wartezeit haben wir so kalkuliert, dass der Bericht verfügbar ist, wenn die AD-Mitarbeiter dann vom Termin zurück sind (entweder im Büro oder im Homeoffice).

Wenn kurzfristig Daten zu ändern sind, dann muss man da nur an einer Stelle tun: Bis zur Erstellung des BB in der Entität Termin. Da kann man den Termin auch deaktiveren oder verschieben, falls der Kundenmitarbeiter oder der AD erkranken. Mit der Erstellung des BB über den Workflow machen wir die Felder im Termin dicht. Alle anderen Erfassungen erfolgen dann im Besuchsbericht. Die Auswertung erfolgt über den Besuchsbericht. Wer bei Absagen/Verschiebungen seine Termine schlampig pflegt, der hat viele leere Besuchsberichte, die er von Hand (und nachweisbar) deaktivieren muss.

Für den Kunden war auch wichtig, dass der Innendienst die Termine (=Abwesenheiten) sehen kann. Und dann abschätzen kann, ob man den Kollegen noch im Auto anrufen kann oder ob der Termin bereits läuft. Hier gab es über die Besuchsbericht eine Motivation, die Termine gut einzutragen.

Es kommt also darauf an, was Ihr umsetzen wollt. Es macht Sinn, dass Ihr eure Anforderung mal kurz aufschreibt, intern abstimmt und dann erst umsetzt. Wenn Ihr dabei Hilfe braucht, dann kann man ja aktive Schreiber im Forum mal ansprechen

wir haben custom felder in der standard-termin-entität eingeführt die unseren Nutzen erfüllen.
der eigentliche Besuchsbericht wird dann per aufgehübschtem SSRS-Report erstellt, kann als PDF gespeichert und dem Kunden als "Gesprächsprotokoll" gesendet werden. Da wir follow-up-aktiviten in Form von Aufgaben mit Terminen verknüpfen, können hier auch Todos etc. im Report mit ausgegeben werden.