[Alg] Één support e-mail adres delen

[Verwijderd]

Ik weet niet of dit het juiste forum is, maar aangezien ik het zelf wil implementeren lijkt me deze het beste.

Stel je voor, de volgende situatie:
Een willekeurig bedrijf met een support afdeling. Op deze afdeling werken vijf mensen. Al deze mensen hebben hun eigen e-mail adres en er is één support e-mail adres.
Zodra een klant een mailtje stuurt naar dit support adres moeten alle vijf de werknemers deze ontvangen (liefst in hun eigen mailbox), maar slechts één hoeft er maar te antwoorden. De anderen moeten dus niet per ongeluk ook kunnen antwoorden (mag, indien nodig, natuurlijk wel).
Ook moet, als de klant weer reply-ed op een antwoord van het support-team, deze aanvankelijk terecht komen bij de support medewerker die op het eerste mailtje antwoorde. Maar, indien nodig, dienen ook de andere support medewerkers op dit mailtje te kunnen antwoorden (misschien is de betreffende medewerker wel plotseling drie weken ziek), zonder de hele mailbox van de medewerker in te kunnen zien (er kan tenslotte ook privé-mail inzitten).

Hoe is dit te implementeren en bestaat dit al? In principe wil ik met mail-clients (Outlook) werken, dus een mail-server schrijven. Maar, mocht dit echt niet mogelijk blijken, dan vind ik een webbased oplossing ook okay.

Mijn eerste idee, webbased helaas, was om een forum-achtig iets te maken waarin ieder ontvangen bericht een nieuw topic was. Support medewerkers kunnen dan via dit forum reageren en reacties worden dan automatisch naar de klant ge-emailt. Maar, zodra de klant dan daar weer op reageert dan is dit weer een nieuw topic (deze maakt namelijk geen gebruik van het forum systeem, en dit is ook niet te verplichten).

Kan iemand mij vertellen hoe dit geïmplementeerd zou kunnen worden?? Ik hoef dus geen code voorbeelden ofzo, puur globale en eventueel detailistische systeem-werking beschrijvingen.

[Verwijderd]

Kan je bij de eerste reply (van de support) geen unieke code meegeven. Ergens in de header of zo. Als je die mail dan terugkrijgt ga je kijken of er zo'n code voorkomt en die dan automatisch als reply zetten bij het juiste topic.

Dan zit je wel met een probleem als de gebruiker niet replyed maar gewoon een nieuwe mail stuurt. Maar ja zoiets kan je niet voorkomen natuurlijk.

[Grijze Vos]

Ik zou eerder een soort queue systeem bouwen, en het via dat laten lopen.

Dus:

klant stuurt mail naar support > wordt opgenomen in queue systeem, inclusief eigen ID > reply wordt gemaakt en teruggezonden > reply van klant wordt dmv de ID aan een bepaalde medewerker gekoppeld, en evt kan de aan-/afwezigheid van personeel in het systeem worden opgenomen, om die dan toch te koppelen aan een andere medewerker.

Zoiets lijkt me makkelijker, dan een hoop gekut met mail..

[Verwijderd]

Verwijderd schreef op 15 december 2003 @ 02:40:
Kan je bij de eerste reply (van de support) geen unieke code meegeven. Ergens in de header of zo. Als je die mail dan terugkrijgt ga je kijken of er zo'n code voorkomt en die dan automatisch als reply zetten bij het juiste topic.

Dan zit je wel met een probleem als de gebruiker niet replyed maar gewoon een nieuwe mail stuurt. Maar ja zoiets kan je niet voorkomen natuurlijk.

@Grijze Vos, zoiets als frosboy beschreef bedoel jij toch ook??

Ja, de unieke ID, dat was inderdaad ook nog een optie. Alleen het blijft, vrees ik, wel een webbased oplossing. Ik zou anders niet weten hoe je er voor kan zorgen dat, normaliter, slechts één persoon reageert op een bericht. Natuurlijk kan je wel een CC sturen naar alle andere support medewerkers, maar als je op een gegeven moment enkele honderden mailtjes per dag krijgt dan gaat dat overzicht natuurlijk heel snel verloren.

Ik vind het vreemd dat dit probleem nog niet door één-of-andere grote back-office toko is getackled. Of is dat wel al een keer gedaan?

[ Voor 5% gewijzigd door Verwijderd op 15-12-2003 03:19 . Reden: Paar regels toe gevoegd ]

[Verwijderd]

Misschien dat je hier wat mee kan: http://www.outlookforms.nl/wfm.htm

[Verwijderd]

Het overzicht blijft toch bewaard als je volgens het systeem van een forum werkt. Zeker als ze de mail via een site versturen. dan kan je ze door een form te laten invullen en een categorie te laten kiezen mooi onderverdelen in het forum. Elke support-medewerker hoeft dan alleen maar te lezen waar hij goed in is, of enkel de berichtjes die onbeantwoord zijn.

Eventueel kun je ze dan allemaal een persoonlijke pagina geven waarop alle berichtjes gebundeld staan die zij al behandelt hebben. Op die manier kunnen ze alles goed opvolgen. Het gaat toch over een full-time job neem ik aan

Hoe je het gaat programmeren weet ik ni, maar in theorie klinkt het allemaal heel mooi. Veel succes. En als het lukt

[.oisyn]

Verwijderd schreef op 15 december 2003 @ 03:17:
Natuurlijk kan je wel een CC sturen naar alle andere support medewerkers, maar als je op een gegeven moment enkele honderden mailtjes per dag krijgt dan gaat dat overzicht natuurlijk heel snel verloren.

Je kunt de verstuurde mailtjes toch ook afvangen met een custom mail server? Als er nog een tweede mailtje wordt verstuurd door iemand anders kun je een error genereren dat er al op geantwoord is. En dat zou je dan weer kunnen overriden door een bepaalde code oid in de subject te zetten

[Verwijderd]

Verwijderd schreef op 15 december 2003 @ 03:30:
Misschien dat je hier wat mee kan: http://www.outlookforms.nl/wfm.htm

Hmm, wel een mooi pakketje, denk ik. Maar net niet helemaal waar ik naar zoek. Dit pakket is bedoeld om in relatief grote organisaties de workflow te automatiseren. Voorbeeld bij een autogarage: Persoon A ontvangt de auto icm klacht; Persoon B kijkt de auto na; Persoon C besteld de middelen nodig voor reparatie; Persoon D ontvangt de goederen; Persoon C repareert de auto; Persoon A levert de auto aan de klant. En tsja, dat was nou net niet wat ik zocht. Ik zoek meer een beschrijving van hoe een systeem zou kunnen werken voor het hierboven beschreven probleem.

[Verwijderd]

Verwijderd schreef op 15 december 2003 @ 03:33:
Het overzicht blijft toch bewaard als je volgens het systeem van een forum werkt. Zeker als ze de mail via een site versturen. dan kan je ze door een form te laten invullen en een categorie te laten kiezen mooi onderverdelen in het forum. Elke support-medewerker hoeft dan alleen maar te lezen waar hij goed in is, of enkel de berichtjes die onbeantwoord zijn.

Heb ik ook overwogen, maar ik wil niet dat alle klanten zich moeten registreren of, voor hen, moeilijke handelingen moeten verrichten. Niet iedereen beweegt zich gemakkelijk op een forum.

Eventueel kun je ze dan allemaal een persoonlijke pagina geven waarop alle berichtjes gebundeld staan die zij al behandelt hebben. Op die manier kunnen ze alles goed opvolgen. Het gaat toch over een full-time job neem ik aan

Dat is wel een mooie optie. Had ik eigenlijk nog niet bedacht. Die neem ik mee! Thnx!

.oisyn schreef op 15 december 2003 @ 03:40:
[...]

Je kunt de verstuurde mailtjes toch ook afvangen met een custom mail server? Als er nog een tweede mailtje wordt verstuurd door iemand anders kun je een error genereren dat er al op geantwoord is. En dat zou je dan weer kunnen overriden door een bepaalde code oid in de subject te zetten

Ja, dat zou inderdaad heel goed kunnen, en ook daar heb ik over nagedacht. Daar zat alleen één grote maar aan; stel dat een klant een complexe vraag stelt. Medewerker A reageert, na een tijdje research, met een lang e-mailtje. In de tussentijd stelt Medewerker B ook een soort gelijk mailtje op. Vrij frustrerend voor Medewerker B als Medewerker A net een minuut eerder dan hij/zij op 'Send' drukt en dus voor niets zijn best deed. Ook bijzonder jammer voor de werkgever die twee mensen betaald, terwijl er maar voor één man/vrouw werk wordt verzet.

En dan nog een iets kleinere maar: het is niet zichtbaar welke mailtje wel of niet beantwoord is, dus deze error krijg je dan meerdere malen per dag. Dat is niet goed voor de productiviteit.

[Wolfboy]

Verwijderd schreef op 15 december 2003 @ 01:20:
Maar, indien nodig, dienen ook de andere support medewerkers op dit mailtje te kunnen antwoorden (misschien is de betreffende medewerker wel plotseling drie weken ziek), zonder de hele mailbox van de medewerker in te kunnen zien (er kan tenslotte ook privé-mail inzitten).

Dit is natuurlijk op te lossen door bij elk probleem de datum van het laatste bericht (laastste bericht van de klant dus) op te slaan en dan automatisch (elke week ofzo) een melding geven aan de andere supportmedewerkers dat het geval nog niet afgehandeld is

moet je er natuurlijk nog wel een switch bij maken of het opgelost is of niet

[JeroenE]

Hoe is dit te implementeren en bestaat dit al? In principe wil ik met mail-clients (Outlook) werken, dus een mail-server schrijven.

Het meest simpele is gewoon een gedeelde mailbox maken in je (exchange?) mailserver. Iedere medewerker heeft dan zijn eigen persoonlijke mailbox en de gezamelijke mailbox.

Omdat Exchange hier (voor zover ik weet) niet echt voor bedoeld is moet je wel goede afspraken maken over de manier waarop men met het systeem om gaat, Iedereen die de mail leest moet er voor zorgen dat de het bericht niet automatisch al 'read' gemarkeerd wordt. Degene die reply'ed zet de mail wel op read.

De reply wordt gewoon vanuit de eigen mailbox gestuurd. Het handigst is om er voor te zorgen dat de mensen de 'from' kunnen aanpassen naar "support". De reply moeten ze wel nog steeds kopieren naar de gezamelijke mailbox (evt met outlook rules).

Nadeel is wel dat het allemaal samenhangt met goede afspraken waar iedereen zich dan altijd aan moet houden. In de praktijk werkt het dus niet echt vlekkeloos, waarschijnlijk.

Kan iemand mij vertellen hoe dit geïmplementeerd zou kunnen worden?? Ik hoef dus geen code voorbeelden ofzo, puur globale en eventueel detailistische systeem-werking beschrijvingen.

Je kan veel beter een echt helpdesk systeem kopen of zelf schrijven als je dat echt wil. Er zijn hele dure, maar ook (goede) goedkopere als deze. Ik weet niet of jullie alleen mail krijgen en geen telefoon? De meeste helpdesks krijgen meer telefoon dan mail omdat mensen eerder geneigd zijn te bellen dan te mailen.

Het is sowieso handiger om 1 persoon verantwoordelijk te maken voor de inkomende mail en die 'in het systeem' te laten zetten. Dat kan natuurlijk iedere dag/week iemand anders zijn. Sommige afdelingen vinden het fijn als medewerkers dan zelf tickets op hun naam kunnen zetten; andere afdelingen hebben liever dat dit meer gestuurd gebeurd om te voorkomen dat sommige mensen alleen de 'leuke' problemen nemen en de 'vervelende' langer blijven liggen.

[Verwijderd]

Wolfboy schreef op 15 december 2003 @ 04:01:
[...]
Dit is natuurlijk op te lossen door bij elk probleem de datum van het laatste bericht (laastste bericht van de klant dus) op te slaan en dan automatisch (elke week ofzo) een melding geven aan de andere supportmedewerkers dat het geval nog niet afgehandeld is

moet je er natuurlijk nog wel een switch bij maken of het opgelost is of niet

Dit klinkt wel als een werkende oplossing, maar toch 'voelt' het niet goed. Die switch vind ik wel een goede optie, en ook dat doorschuiven van een e-mail wanneer er niet op tijd geantwoord wordt vind ik mooi. Maar dan als vangnet, en niet als systeem om op te vertrouwen bij afwezigheid van een medewerker.

jeroene schreef op 15 december 2003 @ 06:19:
[...]
Het meest simpele is gewoon een gedeelde mailbox maken in je (exchange?) mailserver. Iedere medewerker heeft dan zijn eigen persoonlijke mailbox en de gezamelijke mailbox.

Omdat Exchange hier (voor zover ik weet) niet echt voor bedoeld is moet je wel goede afspraken maken over de manier waarop men met het systeem om gaat, Iedereen die de mail leest moet er voor zorgen dat de het bericht niet automatisch al 'read' gemarkeerd wordt. Degene die reply'ed zet de mail wel op read.

De reply wordt gewoon vanuit de eigen mailbox gestuurd. Het handigst is om er voor te zorgen dat de mensen de 'from' kunnen aanpassen naar "support". De reply moeten ze wel nog steeds kopieren naar de gezamelijke mailbox (evt met outlook rules).

Nadeel is wel dat het allemaal samenhangt met goede afspraken waar iedereen zich dan altijd aan moet houden. In de praktijk werkt het dus niet echt vlekkeloos, waarschijnlijk.

Ja, ook dit heb ik overwogen, maar ik vind het toch net effe te bewerkelijk allemaal. Het valt of staat, zoals jij ook al zei, met de discipline van de werknemers. En eerlijk gezegd durf ik daar niet op te vertrouwen.

[...]

Je kan veel beter een echt helpdesk systeem kopen of zelf schrijven als je dat echt wil. Er zijn hele dure, maar ook (goede) goedkopere als deze. Ik weet niet of jullie alleen mail krijgen en geen telefoon? De meeste helpdesks krijgen meer telefoon dan mail omdat mensen eerder geneigd zijn te bellen dan te mailen.

Ok, maar hoe is dan de werking van een 'echt' helpdesk systeem?? Keep in mind, ik ben nu niet opzoek naar de goedkoopste oplossing. Ik wil weten hoe dit werkt.

Maar inderdaad, telefonische support heb ik in deze omschrijving nog even geen rekening mee gehouden. Komt nog wel Eerlijk gezegd zie ik dat, wanneer ik er even snel over nadenk wel voor me hoe dat zou moeten werken, maar ongetwijfeld loop ik ook daar tegen problemen op; Welkom in de wereld die software ontwikkeling heet!

[Tomsworld]

Is een ticketting systeem waar iedereen inkan niet een mogelijkheid ?
http://www.bestpractical.com/rt mails ook sturen naar mailboxen kan ook dacht ik.

[mocean]

Ik heb ooit eens met topdesk gewerkt. Toen was het nog vrij buggy, maar werkte wel aardig. Een dergelijk systeem doet het volgende:

Vaak is een helpdesk systeem gebaseerd op een 1e lijns en 2e lijns helpdesk. Binnen het systeem komen mails/requests binnen, en je kan ook cases intypen die via de telefoon binnenkomen. De mensen vanuit de eerstelijns helpdesk delen het probleem in (je kan zelf categorien bedenken).

Vervolgens kan je ook in het systeem aangeven dat je met een case bezig bent, zodat je collega's niet aan dezelfde vraag beginnen. Wanneer je er niet uit komt, kan je een vraag doorspelen naar de 2elijns helpdesk (de experts). Zij krijgen een E-mailtje en na opstarten topdesk zien ze welke case ze hebben toebedeeld gekregen. Hun antwoord loopt via de eerstelijns Helpdesk, en die rapporteert weer naar de klant. Zo bouw je ook een knowledge base op.

en 500 US$ is niet veel voor een dergelijk pakket!

[curry684]

In React kun je mail ontvangen op een specifiek daarvoor aangewezen subforum, en replies worden automatisch gemaild. Dit gaan we als het goed is ooit nog inzetten voor gathering(at)t.net daar die ook door 12-15 mensen actief wordt gelezen en behandeld

[Apollo_Futurae]

Verwijderd schreef op 15 december 2003 @ 03:52:
Heb ik ook overwogen, maar ik wil niet dat alle klanten zich moeten registreren of, voor hen, moeilijke handelingen moeten verrichten. Niet iedereen beweegt zich gemakkelijk op een forum.
[...]
Ja, dat zou inderdaad heel goed kunnen, en ook daar heb ik over nagedacht. Daar zat alleen één grote maar aan; stel dat een klant een complexe vraag stelt. Medewerker A reageert, na een tijdje research, met een lang e-mailtje. In de tussentijd stelt Medewerker B ook een soort gelijk mailtje op. Vrij frustrerend voor Medewerker B als Medewerker A net een minuut eerder dan hij/zij op 'Send' drukt en dus voor niets zijn best deed. Ook bijzonder jammer voor de werkgever die twee mensen betaald, terwijl er maar voor één man/vrouw werk wordt verzet.

En dan nog een iets kleinere maar: het is niet zichtbaar welke mailtje wel of niet beantwoord is, dus deze error krijg je dan meerdere malen per dag. Dat is niet goed voor de productiviteit.

Het lijkt me dat je voor de helpdeskmedewerkers het beste een webbased oplossing kunt maken. Zoiets als een forum, maar dan toegespitst op deze situatie:
• Een topic is een probleem/vraag/opmerking. Elk topic is ofwel nog niet toegewezen ofwel toegewezen aan precies één medewerker.
• Maak één pagina met alle nieuwe/ongerichte berichten. Medewerkers kunnen hier een topic op hun naam zetten, zodat het op hun persoonlijke pagina komt en de rest weet dat zij het in principe afhandelen.
• Maak een pagina per medewerker met zijn/haar nieuwe/openstaande/afgehandelde problemen.
• Zorg voor de mogelijkheid om prioriteiten toe te kennen aan binnengekomen berichten (zowel gerichte als ongerichte).
• Reacties zijn er in verschillende soorten: een e-mail van de klant, een interne notitie van de medewerker, een notitie van een andere medewerker wiens hulp is ingeroepen, een e-mail naar de klant toe. Zet deze bij voorbeeld allemaal onder elkaar, op tijd gesorteerd, zodat ook een andere medewerker een volledig overzicht kan krijgen van wat er allemaal heeft plaatsgevonden.

Als je klanten niet wilt dwingen gebruik te maken van zo'n webbased systeem (wat ik me best voor kan stellen, hangt af van de doelgroep), maar wilt laten e-mailen, moet je op de één of andere manier vaststellen waar zo'n e-mail op het forum terecht moet komen. Dit zou bij voorbeeld zo kunnen:

code:

[*] Kijk aan wie de e-mail gericht is:
    Als de e-mail gericht is aan een zekere helpdeskmedewerker ("To: Henkie <[e-mail]>"):
        [*] Zoek op of het e-mailadres van de klant bekend is en kijk waar de e-mail over gaat.
            Bepaal op basis hiervan of de e-mailadres duidelijk een vervolgreactie is op een bestaand/openstaand probleem.
    Als er geen of een niet-bestaande naam in de To-regel staat:
        [*] Zoek op of het e-mailadres van de klant bekend is.
            Komt het b.v. voor in de lijst met kopers van een zeker product?
            Wijs het bericht dan toe aan de expert van dat product.
            Is er al eerder een e-mail gekomen van dit e-mailadres?
            Wijs het bericht dan toe aan degene die als laatste een probleem afkomstig van dat e-mailadres heeft afgehandeld.
        [*] Is het e-mailadres onbekend, dan kun je eventueel nog de Subject-regel doorzoeken op bekende kreten en op basis daarvan het bericht alsnog bij een bepaalde medewerker plaatsen.
            Kun je ook daaraan niets zien, zet het bericht dan bij "Nieuw".

[Verwijderd]

Kan je niet gewoon een exchange server groeps mailbox aanmaken voor de helpdesk. Dan gebruikt iedereen dezelfde mailbox en zie je het gewoon als hij als is gelezen. Bijvoorbeeld alle mailtjes die zijn gelezen naar een mapje gelezen te verplaatsen.

Zo deden wij dat in ieder geval altijd

[samo]

Op werk gebruiken wij hiervoor http://www.kana.com/ client.
Geeft idd een ID in de message subject mee, waarmee case ownership gegeven wordt aan agents. Dit in een organisatie met ong. 40-60 email agents denk ik (kweet niet hoeveel dr in de US zijn namelijk)... En mn oude wergever werkte dr ook mee (100-en agents).... Werkt wel goed.. Zal wel duur zijn...
Een nog oudere werkgever had gewoon een agent die mails versleepte in een exchange box naar mapjes van andere agents. Kom je een email tegen met een reply van een andere, of mocht de slepende agent het zien, dan sleeptje je de mails zelf door. (afd. van 15 mensen)

[Verwijderd]

curry684 schreef op 15 december 2003 @ 11:21:
In React kun je mail ontvangen op een specifiek daarvoor aangewezen subforum, en replies worden automatisch gemaild. Dit gaan we als het goed is ooit nog inzetten voor gathering(at)t.net daar die ook door 12-15 mensen actief wordt gelezen en behandeld

Kijk, dat is dus zo ongeveer waar ik nu naar neig. Op die manier houd je een duidelijk overzicht voor iedereen, maar de klant hoeft zelf geen moeilijke dingen te doen. Kennis van zijn eigen e-mail client is voldoende. Maar dat zit dus standaard al in React?

[Verwijderd]

Verwijderd schreef op 15 december 2003 @ 11:39:
Kan je niet gewoon een exchange server groeps mailbox aanmaken voor de helpdesk. Dan gebruikt iedereen dezelfde mailbox en zie je het gewoon als hij als is gelezen. Bijvoorbeeld alle mailtjes die zijn gelezen naar een mapje gelezen te verplaatsen.

Zo deden wij dat in ieder geval altijd

Nee sorry, die methode vind ik iets teveel quick-and-dirty. Het valt of staat met de discipline van medewerkers. En overzicht is er al helemaal niet meer.

samo-arne schreef op 15 december 2003 @ 11:44:
Op werk gebruiken wij hiervoor http://www.kana.com/ client.
Geeft idd een ID in de message subject mee, waarmee case ownership gegeven wordt aan agents. Dit in een organisatie met ong. 40-60 email agents denk ik (kweet niet hoeveel dr in de US zijn namelijk)... En mn oude wergever werkte dr ook mee (100-en agents).... Werkt wel goed.. Zal wel duur zijn...

En hoe werkte dit dan voor de medewerkers die ermee aan de gang moesten?

Een nog oudere werkgever had gewoon een agent die mails versleepte in een exchange box naar mapjes van andere agents. Kom je een email tegen met een reply van een andere, of mocht de slepende agent het zien, dan sleeptje je de mails zelf door. (afd. van 15 mensen)

Mmmm, beetje zoals o.a. mens_rea het beschreef, maar dan iets meer geautomatiseerd?? Ik weet het zo net nog niet.

[ Voor 47% gewijzigd door Verwijderd op 15-12-2003 13:59 . Reden: Nog een reply bij geplakt ]

[Grijze Vos]

Wat ik bedoelde is dat je de backend van je systeem niet in de vorm van mailtjes laat lopen. Dat forum voorbeeld is handig.

Het forum kan zelfs van de gebruiker verborgen blijven.

- gebruiker stuurt mail, forum topic wordt geopend;
- medewerker replied, mail wordt verstuurd, en de reply wordt in het topic bijgeschreven;
- reply-mails van klant en evt andere medewerkers kunnen hier ook worden bijgehouden;

[curry684]

Verwijderd schreef op 15 december 2003 @ 13:54:
[...]

Kijk, dat is dus zo ongeveer waar ik nu naar neig. Op die manier houd je een duidelijk overzicht voor iedereen, maar de klant hoeft zelf geen moeilijke dingen te doen. Kennis van zijn eigen e-mail client is voldoende. Maar dat zit dus standaard al in React?

Yup, tevens via het reeds aangegeven concept van de trackingID tag in de emails. Dit zou dan intern naar ons Doktersoverleg gekoppeld worden alwaar we van alles de progressie kunnen traceren en geen dubbele afhandelingen meer hebben.

[Verwijderd]

Grijze Vos schreef op 15 december 2003 @ 14:14:
Wat ik bedoelde is dat je de backend van je systeem niet in de vorm van mailtjes laat lopen. Dat forum voorbeeld is handig.

Het forum kan zelfs van de gebruiker verborgen blijven.

Nee, het forum MOET van mij zelfs verborgen blijven van de gebruiker.

- gebruiker stuurt mail, forum topic wordt geopend;
- medewerker replied, mail wordt verstuurd, en de reply wordt in het topic bijgeschreven;
- reply-mails van klant en evt andere medewerkers kunnen hier ook worden bijgehouden;

Heb ik alleen nog een moeilijke vraag: hoe filter je netjes uit de ontvangen mailtjes van de klanten alle voorgaande berichten? Wanneer deze op de reply knop ramt wordt het volledige voorgaande bericht ge-quote. En... Helaas quote iedere mail client weer anders. Ik kan er wel voor kiezen deze mailtjes te laten staan, maar dan wordt op een gegeven moment het forum wel verschrikkelijk groot, aangezien alles er meerdere keren in staat.

curry684 schreef op 15 december 2003 @ 14:46:
[...]

Yup, tevens via het reeds aangegeven concept van de trackingID tag in de emails. Dit zou dan intern naar ons Doktersoverleg gekoppeld worden alwaar we van alles de progressie kunnen traceren en geen dubbele afhandelingen meer hebben.

Maaruh, waar komt dit trackingID dan terecht?? In het subject?? Het kan niet onzichtbaar in een mailtje meegenomen worden (hoe heet dat ook alweer?) toch? Tenminste, het kan wel, maar zodra de klant replyed dan ben je 'm weer kwijt.

[ Voor 23% gewijzigd door Verwijderd op 15-12-2003 15:02 . Reden: Nog een reply erbij. ]

[chem]

Het hele verhaal is bij React min of meer als volgt.
De mailserver wordt zo geconfigged, dat mail naar 1 (of meerdere) adressen naar een .php file wordt gestuurd (onder unix is dat een piece of cake).
De .php file verwerkt de (mime) email, en maakt er een goede html/text versie van. Het originele bericht, incl. alle mime-attachements blijven bewaard in een zip.
Dan wordt het mailtje als nieuw topic in een per ontvangend-emailadres te definieeren forum geplaatst.

Als de forumgebruiker een reply geeft, kan er gekozen worden om tevens een mail te sturen, met een te definieeren afzender en signature. Daarnaast kan er een subject opgegeven worden, evt. met een tracking-nummer.

De ontvanger kan weer reply-en, waarbij de reply in hetzelfde topic (op eenzelfde wijze) als nieuw bericht wordt geplaatst.
Met de diverse functies zoals splitten, mergen, rechten en archivering hou je zo een overzicht van je externe communicatie.

Als je interesse hebt, of meer informatie wil, dan weet je ons vast wel te vinden

[ Voor 5% gewijzigd door chem op 15-12-2003 15:01 ]

[Verwijderd]

chem schreef op 15 december 2003 @ 15:00:
De ontvanger kan weer reply-en, waarbij de reply in hetzelfde topic (op eenzelfde wijze) als nieuw bericht wordt geplaatst.
Met de diverse functies zoals splitten, mergen, rechten en archivering hou je zo een overzicht van je externe communicatie.

Maar hoe strip je de reply dan weer van alle voorgaande mailtjes?? Die wil je natuurlijk niet in je forum hebben.

[chem]

Verwijderd schreef op 15 december 2003 @ 15:31:
[...]

Maar hoe strip je de reply dan weer van alle voorgaande mailtjes?? Die wil je natuurlijk niet in je forum hebben.

Ik ga hier niet de volledige werking en structuur uitleggen uiteraard

Als je interesse hebt, moet je maar even contact opnemen.

[Apollo_Futurae]

Verwijderd schreef op 15 december 2003 @ 15:31:
Maar hoe strip je de reply dan weer van alle voorgaande mailtjes?? Die wil je natuurlijk niet in je forum hebben.

Als je klanten zich aan de netiquette houden, citeren ze alleen relevante passages uit vorige berichten. Die verwijzingen laat je er liever in staan lijkt me; dan zie je waar de ander in zijn antwoord aan refereert.
Ik weet dat veel mensen als een hersenloze lemming op reply rammen, er iets bij kramen en de hele meut ongezien verzenden. Als je daar veel last van hebt, kun je medewerkers de mogelijkheid geven om delen van e-mails te verwijderen of (liever) onzichtbaar te maken.

[curry684]

Apollo_Futurae schreef op 15 december 2003 @ 17:00:
[...]

Als je klanten zich aan de netiquette houden, citeren ze alleen relevante passages uit vorige berichten. Die verwijzingen laat je er liever in staan lijkt me; dan zie je waar de ander in zijn antwoord aan refereert.
Ik weet dat veel mensen als een hersenloze lemming op reply rammen, er iets bij kramen en de hele meut ongezien verzenden. Als je daar veel last van hebt, kun je medewerkers de mogelijkheid geven om delen van e-mails te verwijderen of (liever) onzichtbaar te maken.

Je geeft de medewerkers toch volledige modrechten op het betreffende forum, anders kunnen ze een zaak ook niet sluiten of het subject/topic veranderen. Dan krijgen ze iig in React automatisch editrechten erbij.

[Johannes]

Ik wil natuurlijk niet met React concurreren , maar ik vind toch dat ik een balletje voor een open source product waar ik aan mee werk opgooien. Wij hebben namelijk voor Python een soortgelijke tracker opgezet (helaas private). Daar kenden we namelijk een aantal problemen toen [e-mail] gewoon naar een mailinglist ging, zoals dubbele replies. Alle mensen die [e-mail] opereren hebben wel iets beters te doen, zoals aan Python werken, dus hebben we een Roundup issuetracker opgezet. Zie onder andere deze thread.

Roundup bevat namelijk al bijna alle functionaliteit om te implementeren wat jij beschrijft: een mail gateway naar de tracker, geen duplicatie omdat iedereen kan zien wat er verstuurd en niet verstuurd is en een ID per issue om eventuele followups uit elkaar te houden. Roundup kan dus alles wat React kan, alleen flexibeler, goedkoper en onder de bijzonder vrije Python licentie.

Maar even serieus, mail naar [e-mail] als je interesse hebt, daar kunnen we je wel verder helpen.

[chem]

Johannes schreef op 15 december 2003 @ 19:39:
Roundup kan dus alles wat React kan, alleen flexibeler, goedkoper en onder de bijzonder vrije Python licentie.

Afgezien van de licentie, vind ik de rest onzin

Ik vind het erg voorbarig om een pakket als React (met rechtenstructuur) te vergelijken met een eenvoudige mailmanager.

maar da's heel nofi, natuurlijk

[Verwijderd]

Apollo_Futurae schreef op 15 december 2003 @ 17:00:
[...]

Als je klanten zich aan de netiquette houden, citeren ze alleen relevante passages uit vorige berichten. Die verwijzingen laat je er liever in staan lijkt me; dan zie je waar de ander in zijn antwoord aan refereert.
Ik weet dat veel mensen als een hersenloze lemming op reply rammen, er iets bij kramen en de hele meut ongezien verzenden. Als je daar veel last van hebt, kun je medewerkers de mogelijkheid geven om delen van e-mails te verwijderen of (liever) onzichtbaar te maken.

Ik ben blij dat je zelf al zegt dat je weet dat de meeste mensen gewoon op reply rammen
Zou dit verwijderen/onzichtbaar maken ook (voor een deel) automatisch kunnen laten doen?? Ja natuurlijk, ongetwijfeld, maar hoe?? Iemand goede ideeën??

Johannes schreef op 15 december 2003 @ 19:39:
Roundup bevat namelijk al bijna alle functionaliteit om te implementeren wat jij beschrijft: een mail gateway naar de tracker, geen duplicatie omdat iedereen kan zien wat er verstuurd en niet verstuurd is en een ID per issue om eventuele followups uit elkaar te houden. Roundup kan dus alles wat React kan, alleen flexibeler, goedkoper en onder de bijzonder vrije Python licentie.

Hmm, even snel bekeken, zal me er morgen meer in verdiepen. Iig alvast bedankt voor de tip!

[dirkpostma]

Waar we hier over spreken heet ook wel een "support ticket systeem".

Kijk eens op http://www.osticket.com/

Dit is een opensource ticketsysteem in PHP waarmee je via POP3 een mailbox kunt leegtrekken. osTicket analyseert de mailtjes en opent een nieuw ticket, of voegt een mailtje toe aan een bestand ticket. De ID wordt meegestuurd in het subject. Ook is er de mogelijkheid om te strippen. Verder is het ook mogelijk om diverse "afdelingen" te creeren, en per afdeling kun je weer representatives (werknemers) toewijzen.

[ Voor 18% gewijzigd door dirkpostma op 16-12-2003 03:08 ]

[JeroenE]

Verwijderd schreef op 15 december 2003 @ 11:07:
Ok, maar hoe is dan de werking van een 'echt' helpdesk systeem?? Keep in mind, ik ben nu niet opzoek naar de goedkoopste oplossing. Ik wil weten hoe dit werkt.

Maar inderdaad, telefonische support heb ik in deze omschrijving nog even geen rekening mee gehouden. Komt nog wel Eerlijk gezegd zie ik dat, wanneer ik er even snel over nadenk wel voor me hoe dat zou moeten werken, maar ongetwijfeld loop ik ook daar tegen problemen op; Welkom in de wereld die software ontwikkeling heet!

Right. Ik wil niet bot overkomen, maar als je geen idee hebt wat het probleem is is het niet echt handig om daar dan de oplossing voor te gaan programmeren. Tenzij je natuurlijk tijd over hebt en je afvraagt wat je eens zou willen gaan doen...

Anyway, de meeste helpdesk zijn tegenwoordig wel redelijk georganiseerd. Als het voorbeeld uit je openingspost niet fictief is (waar ik aan twijfel gezien het feit dat je niet eens rekening hebt gehouden met telefoonverkeer) kan je aan die mensen daar wel meer info krijgen over de gegevens die ze moeten verwerken etc.
Het is sowieso wel handig om wat meer info te zoeken op Internet. Probeer eens te googlen (of de search) op ITIL zou ik zeggen.

[Verwijderd]

jeroene schreef op 18 december 2003 @ 08:36:
[...]
Right. Ik wil niet bot overkomen, maar als je geen idee hebt wat het probleem is is het niet echt handig om daar dan de oplossing voor te gaan programmeren. Tenzij je natuurlijk tijd over hebt en je afvraagt wat je eens zou willen gaan doen...

Ik zou willen dat ik tijd over had om zomaar wat te programmeren . Maar het probleem is mij volkomen duidelijk, zie mijn openingspost. Het hele telefoongebeuren is erbij gekomen tijdens deze thread. Dat was niet iets waar ik een oplossing voor zocht. Zodra de oplossing voor de eerste post er is zou ik het wel intressant vinden om er een telefoonmodule bij te bouwen (en dat is inderdaad programmeren als werkverschaffing, gewoon omdat ik uitbreiding dan leuk vind ). En mijn stelling in deze was dat ik globaal wel een indruk had over hoe dit dan zou moeten werken. Dit in tegenstelling tot de organisatie van de mails (zie openingspost weer).

Anyway, de meeste helpdesk zijn tegenwoordig wel redelijk georganiseerd. Als het voorbeeld uit je openingspost niet fictief is (waar ik aan twijfel gezien het feit dat je niet eens rekening hebt gehouden met telefoonverkeer) kan je aan die mensen daar wel meer info krijgen over de gegevens die ze moeten verwerken etc.
Het is sowieso wel handig om wat meer info te zoeken op Internet. Probeer eens te googlen (of de search) op ITIL zou ik zeggen.

Het voorbeeld in de openingspost is in zoverre fictief dat het inderdaad niet voor de support afdeling van een bedrijf is. Het is voor een vereniging. Maar om te voorkomen dat ik eerst de structuur van de vereniging uit moest leggen om aan de hand daarvan mijn probleem te formuleren heb ik een support afdeling als (simpel ??) voorbeeld genomen. Achteraf misschien niet de handigste aangezien ik inderdaad geen rekening hield met bijvb. telefoonverkeer.

[Verwijderd]

Dus, niemand meer aanvullende informatie over dit onderwerp?? Jammer, ik had gehoopt dat er toch ook nog andere duidelijke oplossingen zouden zijn.

[faabman]

/me heeft niet het hele topic gelezen, geeft gewoon ff antwoord op de eerste vraag

www.myvevida.nl heeft hier wel een aardig online systeem voor (weet niet of het systeem exact zo werkt als ik het hier beschijf, maar dit is de manier waarop ik het zelf toe ga passen voor mijn klanten):
- elke klant kan zelf vragen stellen via een internetsite
- na een vraag zal waarschijnlijk een mailtje uitgaan naar de supportafdeling (met daarin een linkje naar de vraag)
- een werknemer begint met antwoorden en blokkeerd daarmee meteen het topic (kan hem later ook weer deblokkeren)
- het antwoord gaat per mail naar de klant en wordt toegevoegd aan de vraag
- de klant kan zonodig reageren op jullie antwoord...

de klant hoeft in principe alleen maar in te loggen met de gegevens die door jullie verstrekt zijn...

[faabman denkt groot modus]
als je dit systeem echt uitgebreid maakt dan catagoriseer je meteen de vragen die worden gesteld en kan je op de lange termijn een faq extraheren

eventueel kan je de app koppelen aan jullie klantendatabase en leg je een beginnentje neer voor een crm

je kan natuurlijk ook gewoon meteen siebel kopen
[/faabman denkt groot modus]

[Johannes]

chem schreef op 15 december 2003 @ 19:58:
[...]

Afgezien van de licentie, vind ik de rest onzin

Ik vind het erg voorbarig om een pakket als React (met rechtenstructuur) te vergelijken met een eenvoudige mailmanager.

maar da's heel nofi, natuurlijk

Als Roundup een eenvoudige mailmanager was dan had ik het niet aangedurfd om ook maar een reactie te plaatsen in dit topic. Misschien kun je dan ook beter eerst even naar http://roundup.sf.net kijken voordat je post.

net zo nofi, natuurlijk