Automatische Benachrichtigung an Absender aus Mail-In Datenbank

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Automatische Benachrichtigung an Absender aus Mail-In Datenbank

    Hallo in die Runde,
    da ich neu hier bin, hoffe ich, dass ich das richtige Unterforum gefunden habe und es einen ähnlichen Beitrag nicht schon gibt. (In der Suchfunktion habe ich nichts gefunden).

    Ich benötige Hilfe, da ich in einem Fall nicht weiterkomme.
    Wir arbeiten mit vielen Mail-In-Datenbanken, auf die dann in der Regel eine ganze Abteilung Zugriff hat.
    Nun würde ich diese Mail-In-Datenbanken gerne so gestalten, dass sobald sich jemand selbst eine eingegangene Mail zuweist oder die Mail durch jemand anderen zugewiesen wird, der Absender eine automatische Benachrichtigung bekommt, wer für diese Mail zuständig ist, damit er bei späteren Nachfragen einen direkten Ansprechpartner hat.

    Leider ist die Agentensteuerung in Notes nicht mein Sperzialgebiet und ich bekomme es selbst nicht hin.
    Hat jemand einen Tipp oder einen Lösungsvorschlag für mich?

    Vielen Dank schon mal :)
    Du sagst, nach allem, was du weißt hast du noch nie ein Pferd ein Rennen gewinnen sehen,

    das "Trübsal" heißt.
  • Zunächst einmal willkommen im Forum! :thumbup:

    Das Vorhaben an sich ist im Grunde relativ schnell realisiert. Man muss nur wissen, was man sucht und wo. Das "Wo" ist schnell erklärt: F1. Das "Wie" ist kaum schwieriger:
    - Setzen eines Feldes: @SetField
    - Nutzername: @UserName, geeignet kombiniert mit @Name
    - Mail versenden: @Compose

    Die Frage ist aber, ob es rein grundsätzlich wirklich Sinn macht, was du vorhast. Mail-In Datenbanken sind ja eigentlich u.a. dafür da, dass man "anonym" kommunizieren kann. Soll heißen: es meldet sich eben nicht mehr Lieschen Müller beim Kunden, sondern halt nur "support@firma.de" oder so. Weiters kann das Probleme geben, wenn Abwesenheiten nicht entsprechend berücksichtigt werden: Ist ja schön, wenn Lieschen Müller einen Vorgang übernimmt und ihn sich zuweist. Blöd nur, wenn Lissie morgen krank ist und niemand kümmert sich um den Vorgang und ggf. entsprechende Mails, die seitens der Kunden zurückkommen. Das ist aber ein technisches, sondern eher ein organisatorisches Problem. Dennoch muss es berücksichtigt werden.
    Überhaupt: was hast du dir vorgenommen, wie Follow-Ups berücksichtigt werden? Wie werden neue Mails, die sich auf einen bestehenden Vorgang beziehen, "einsortiert", sprich: Lissie zugeordnet? Was passiert, wenn sich Lissie einen Vorgang zuordnet, sich dabei aber verklickt hast und als Bearbeiter wieder rausnimmt, um sich woanders einzutragen? Gibt es dann eine entsprechende Mail an den Kunden: "April, April, es Lissie hat sich verklickt, versuchs nochmal"? Alternativ kannst du natürlich einen Agenten stricken, der nur stündlich oder von mir aus nur einmal täglich über die Dokumente drüberläuft und dann und nur dann eine entsprechende Mail rausschickt, wenn das Dokument neu ist seit dem letzten Lauf (Hint: UnprocessedDocuments).

    Die Idee, die du da hast, ist nicht grundverkehrt. Allerdings müssen da noch ein paar Dinge am Rande berücksichtigt und in Angriff genommen werden und an der einen oder anderen Stelle wird man dann merken, dass das eben nicht "mal eben so" zu realisieren ist. Jedenfalls nicht DAU-proof... Und ob das eine oder andere Detail im Workflow so in der Form wirklich Sinn ergibt, auch das wäre noch zu diskutieren.
    Hast du in dem Zusammenhang die TeamMailbox mal getestet? In dem Template sind Auto-Responder und IIRC Bearbeiter ohnehin schon realisiert. Das ist zwar AFAIK noch das alte 6er-basierte Template, aber zum einen kann man sich ja Anregungen holen und vllt. zum anderen das eine oder andere aufs 9er Template portieren?
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl
  • Erstmal danke für die Antwort. :)

    Grundsätzlich kann ich Deine Bedenken verstehen.
    Wir wollen die Datenbanken aber tatsächlich für den internen Mail-Verkehr nutzen, den externen Mail-Verkehr regeln wir anders.
    Von daher legen wir hier keinen Wert auf Anonymisierung, sondern möchten, dass Anfragen an die jeweilige Abteilung gehen, für
    die Kollegen aber ersichtlich ist, bei wem schlussendlich was in Arbeit ist. Auch die Vertretungen sind hier entsprechend geregelt, falls Lissie krank werden sollte ;)

    Danke für den Tipp mit der TeamMailbox, zu dem Bearbeiter finde ich hier auf die Schnelle nichts, aber ich werde es mir mal detaillierter ansehen.
    Du sagst, nach allem, was du weißt hast du noch nie ein Pferd ein Rennen gewinnen sehen,

    das "Trübsal" heißt.
  • schirmchen schrieb:

    Danke für den Tipp mit der TeamMailbox, zu dem Bearbeiter finde ich hier auf die Schnelle nichts, aber ich werde es mir mal detaillierter ansehen.
    Mein Fehler! Das, was ich noch "in Erinnerung" hatte, war das, was ich seinerzeit selbst drangebastelt hab *grmpf* :S
    Das war im Grunde aber auch denkbar trivial: in die Inbox eine neue (erste) Spalte eingefügt, nach dem Feld "Bearbeiter" kategorisiert und zudem noch einen Button mit einer "Simple Action", das den Bearbeiter setzt. Im einfachsten Fall:

    Quellcode

    1. @SetField("Bearbeiter"; @Name[CN]; @Username)


    Ich hatte es so gelöst, dass ich ein weiteres Profildokument erzeugt habe, in dem alle infrage kommenden Bearbeiter enthalten sind, der Button in der Inbox liest das Profildokument aus, öffnet mittels einen Prompt, aus dem man den Bearbeiter auswählen oder zurücksetzen kann.
    Kurz angerissen, nicht funktionsfähig:

    Quellcode

    1. Set notesDocument=notesDatabase.GetProfileDocument("bearbeiterprofil")
    2. valueArray=notesDocument.GetItemValue("alle_bearbeiter")
    3. variant=notesUIWorkspace.Prompt( 4, "titel","prompt", valueArray(0), valueArray )
    4. caretNoteID$=notesUIView.CaretNoteID
    5. Set notesDocument=notesDatabase.GetDocumentByID(caretNoteID$)
    6. Set notesItem=notesDocument.ReplaceItemValue("bearbeiter", variant(0))

    Bei mir war der default value dann der Name der aktuellen ID und das ganze hat noch kein error handling (Was passiert, wenn "Cancel" gedrückt wird? Was passiert, wenn das Profildokument nicht vorhanden oder nicht lesbar ist? Darf Lieschen Müller überhaupt Detlef Dau als Bearbeiter einsetzen? Wer darf sich von welchen Vorgängen selbst runternehmen? ....). Ich denke, du bekommst so schon einen Überblick, wie das lösbar wäre.

    Wenn man will (oder es für interne Prozesse benötigt), lassen sich Workflows einbauen. Zum Beispiel: du hast seit X Tagen einen Vorgang, der immernoch im Status "offen" oder "in Bearbeitung" steht, also geht eine Mail an deinen Chef oder den Produktverantwortlichen oder wen auch immer. Oder : das Ticketsystem schickt Benachrichtigungsmails an diese Mail-In und anhand der Subjects lässt sich automatisiert eine Zuweisung vornehmen. Beispiel: alles was mit User.IDs und vergessenen Passwörtern zu tun hat, geht an Lieschen Müller, alles was mit ACLs/Zugriffen zu tun hat, geht an Detlef Dau, ... und das auch nur, wenn Lieschen oder Detlef nicht gerade "Urlaub" (o.ä.) in ihrem Kalender vermerkt haben; in dem Falle soll es einem benannten Stellvertreter übergeholfen werden.

    Vermutlich führt das jetzt aber ein Stück zu weit. Versuch erstmal mit den Code Fragmenten oben zu realisieren, was dir vorschwebt.
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl