| Beide Seiten, vorherige ÜberarbeitungVorherige ÜberarbeitungNächste Überarbeitung | Vorherige Überarbeitung |
| ticketsystem [2026-01-18 00:50] – [Departments] Aktualisierung des gesamten Abschnitts über Departments marco.rosenthal | ticketsystem [2026-04-12 17:44] (aktuell) – [Spendennachfrage] marco.rosenthal |
|---|
| Für jedes Standort-Department und für das //Überregionale Anfragen//-Department existiert ein separates //Abgelehnte Anfragen//-Department, in dem sich alle Standortagent*innen befinden. Sie erhalten jedoch standardmäßig keinerlei Benachrichtigungen über darin neu angelegte Tickets. Dennoch haben sie die Berechtigung, die geschlossenen Tickets zu prüfen. Denn hin und wieder finden sich darin bspw. E-Mails von Versanddienstleistern, da Spender*innen, die uns Hardware zusenden, dort gerne unsere internen E-Mailadressen für den Versandstatus hinterlegen. | Für jedes Standort-Department und für das //Überregionale Anfragen//-Department existiert ein separates //Abgelehnte Anfragen//-Department, in dem sich alle Standortagent*innen befinden. Sie erhalten jedoch standardmäßig keinerlei Benachrichtigungen über darin neu angelegte Tickets. Dennoch haben sie die Berechtigung, die geschlossenen Tickets zu prüfen. Denn hin und wieder finden sich darin bspw. E-Mails von Versanddienstleistern, da Spender*innen, die uns Hardware zusenden, dort gerne unsere internen E-Mailadressen für den Versandstatus hinterlegen. |
| |
| Übrigens kann der Vorstand den entsprechenden Filter anpassen, sofern das Team Direktmails von bestimmten Absendern empfangen möchte. Diese Aufweichung des Filters sollte aber nur in begründeten Ausnahmefällen erfolgen. Dies betrifft insbesondere Situationen, in denen externe Partner regelmäßig wichtige Informationen an interne Teams senden müssen. Nehmen wir an ein Standortteam nutzt von der //Computertruhe// angemietete Räumlichkeiten eines anderen Vereins. Für organisatorische Abläufe gibt es von diesem Verein eine feste Kontaktperson, die dem Standortteam gelegentlich Informationen zu den Räumlichkeiten oder zum Gebäude mitteilen muss. Das können z. B. Hinweise zu geänderten Öffnungszeiten des Gebäudes oder zu Wartungsarbeiten sein. In diesem Fall wäre es gerechtfertigt, den Filter so anzupassen, dass die Mailadresse dieser Kontaktperson nicht blockiert und stattdessen dem Standortteam zugänglich gemacht wird. | Übrigens kann der Vorstand den entsprechenden Filter anpassen, sofern das Team Direktmails von bestimmten Absendern empfangen möchte. Diese Aufweichung des Filters sollte aber nur in begründeten Ausnahmefällen erfolgen. Dies betrifft insbesondere Situationen, in denen externe Partner regelmäßig wichtige Informationen an interne Teams senden müssen. Nehmen wir an ein Standortteam nutzt von der //Computertruhe// angemietete Räumlichkeiten eines anderen Vereins. Für organisatorische Abläufe gibt es von diesem Verein eine feste Kontaktperson, die dem Standortteam gelegentlich Informationen zu den Räumlichkeiten oder zum Gebäude mitteilen muss. Das können z. B. Hinweise zu geänderten Öffnungszeiten des Gebäudes oder zu Wartungsarbeiten sein. In diesem Fall wäre es gerechtfertigt, den Filter so anzupassen, dass die Mailadresse dieser Kontaktperson nicht blockiert und stattdessen deren Mails dem Standortteam zugänglich gemacht werden. |
| |
| ==== Standardzugriffsberechtigung ==== | ==== Standardzugriffsberechtigung ==== |
| ==== Bedeutung ==== | ==== Bedeutung ==== |
| |
| Unter //Überregionale Anfragen// fallen alle Anfragen, die keinem Standort zugeordnet werden können. Häufig handelt es sich hierbei um Spendenangebote, die per Versand an uns geschickt werden. Jede*r Agent*in hat die Möglichkeit, das aus dieser Anfrage resultierende Ticket zu übernehmen und ins eigene Department zu verschieben. Anfragen, um die sich nach sieben bis zehn Tagen noch niemand gekümmert hat, werden vom Vorstand oder von einem von ihm beauftragten Mitglied bearbeitet. | Unter //Überregionale Anfragen// fallen alle Anfragen, die keinem Standort zugeordnet werden können. Häufig handelt es sich hierbei um Spendenangebote, die per Versand an uns geschickt werden. Jede*r Agent*in hat die Möglichkeit, das aus dieser Anfrage resultierende Ticket zu übernehmen und ins eigene Department zu verschieben. Dies ist zudem auch unerlässlich, damit die in den Canned Responses enthaltenen Links auf die Standortbezogenen Upload-Ordner für Berechtigungsnachweise korrekt sind. Anfragen, um die sich nach sieben bis zehn Tagen noch niemand gekümmert hat, werden vom Vorstand oder von einem von ihm beauftragten Mitglied bearbeitet. |
| |
| ==== Standardzugriffsberechtigung ==== | ==== Standardzugriffsberechtigung ==== |
| * //Bildschirm//: Wird angehakt, wenn ein Bildschirm gewünscht ist. | * //Bildschirm//: Wird angehakt, wenn ein Bildschirm gewünscht ist. |
| * //Laptop//: Wird angehakt, wenn ein Laptop gewünscht ist. | * //Laptop//: Wird angehakt, wenn ein Laptop gewünscht ist. |
| * //Tablet//: Wird angehakt, wenn ein Tablet gewünscht ist. | |
| * //Smartphone//: Wird angehakt, wenn ein Smartphone gewünscht ist. | |
| * //Anderes Gerät//: Wird etwas anderes gewünscht (z. B. ein Videoprojektor), wird dies hier vermerkt. | |
| * //Reservierung//: Hier können Seriennummern von Geräten eingetragen werden, die für die anfragende Person zurückgelegt wurden, z. B.: MR-20231112-2 (Desktops), AL-20231129-13 (Bildschirm) | * //Reservierung//: Hier können Seriennummern von Geräten eingetragen werden, die für die anfragende Person zurückgelegt wurden, z. B.: MR-20231112-2 (Desktops), AL-20231129-13 (Bildschirm) |
| * //Notizen//: s. o. | * //Notizen//: s. o. |
| * //Berechtigungsnachweisformular erstellt und im Tresor abgelegt//: Hier muss grundsätzlich ein Wert hinterlegt sein, damit das Ticket geschlossen werden kann. Wurde das Berechtigungsnachweisformular im Tresor abgelegt, wird hier //Ja// angegeben. Wurde das Ticket abgelehnt, weil bspw. kein passender Berechtigungsnachweis vorgelegt werden konnte, bitte //Nein// auswählen und ggf. einen Kommentar dazu verfassen, sollte der Grund nicht offensichtlich sein. Leider ist dieser Weg etwas umständlich, aber //osTicket// bietet hier aktuell keine uns bekannte bessere Möglichkeit an. | * //Berechtigungsnachweisformular erstellt und im Tresor abgelegt//: Hier muss grundsätzlich ein Wert hinterlegt sein, damit das Ticket geschlossen werden kann. Wurde das Berechtigungsnachweisformular im Tresor abgelegt, wird hier //Ja// angegeben. Wurde das Ticket abgelehnt, weil bspw. kein passender Berechtigungsnachweis vorgelegt werden konnte, bitte //Nein// auswählen und ggf. einen Kommentar dazu verfassen, sollte der Grund nicht offensichtlich sein. Leider ist dieser Weg etwas umständlich, aber //osTicket// bietet hier aktuell keine uns bekannte bessere Möglichkeit an. |
| | * //Umfrage verschickt//: Hier muss grundsätzlich ein Wert hinterlegt sein, damit das Ticket geschlossen werden kann. Direkt nach der Geräteausgabe wird das Fälligkeitsdatum (//Due Date//) des Tickets auf den siebten Tag nach der Ausgabe gesetzt. Die Umfrage (Canned Response //!All Umfrage//) soll dann 1-2 Wochen nach der Geräteausgabe versendet werden. Wurde die Umfrage versendet, wird hier im Anschluss //Ja// angegeben. Wurde die Umfrage nicht versendet, bitte //Nein //auswählen und ggf. einen Kommentar dazu verfassen, sollte der Grund nicht offensichtlich sein. |
| | |
| |
| ===== Canned Responses ===== | ===== Canned Responses ===== |
| |
| //Dieses Unterkapitel wird nach einer Restrukturierung der Canned Responses in 2024 erstellt werden.// | //Dieses Unterkapitel wird nach einer Restrukturierung der Canned Responses erstellt werden.// |
| |
| ====== Zwei-Faktor-Authentifizierung ====== | ====== Zwei-Faktor-Authentifizierung ====== |
