Bausteinbasiertes Newslettersystem

Florian Gehringer

Aktives Mitglied
Hallo Ayomler,

ich muss mal wieder auf das Thema Newsletter zurückkommen. Die ähnlichen Artikel habe ich soweit durchforstet und bin nicht ganz fündig geworden. Kennt den jemand ein Newsletter-System das auf Bausteinen basiert!?

Zur Erläuterung:
Die Agentur bereitet ein Template auf. Innerhalb des Templates kann man vordefinierte Bausteine platzieren und befüllen.
Ein Baustein wäre z.B. Text links, Bild rechts.

Mir geht es darum, dass der Kunde selbst nicht innerhalb eines Wysiwig alles machen kann was er lustig findet, sondern auf bestimmte "Bausteine" eingeschränkt wird.

Kennt jemand so ein System!?


Gruß und vielen Dank
Flo
 
Danke für den Link!
Das Tool kannte ich noch nicht... ist für unseren geplanten Einsatz zwar auch nicht ganz das richtige, aber es sieht verdammt gut aus!
Scheint eine wirklich gute Lösung zu sein. Interface gut, Funktionen gut... Bin sehr neugierig!

Danke Dir!

Sonst noch jemand etwas interessantes in der Hinterhand?

Flo
 
QUOTE (Florian Gehringer @ Mo 18.01.2010, 19:52)Die Agentur bereitet ein Template auf. Innerhalb des Templates kann man vordefinierte Bausteine platzieren und befüllen.
Ein Baustein wäre z.B. Text links, Bild rechts.

Mir geht es darum, dass der Kunde selbst nicht innerhalb eines Wysiwig alles machen kann was er lustig findet, sondern auf bestimmte "Bausteine" eingeschränkt wird.

Kennt jemand so ein System!?

Ich löse das Problem so, daß ein Html-Grundgerüst definiert wird:

Bsp. Kopf, rechte Spalte mit Ergebnissen von Abfragen, die zum Zeitpunkt der NL-Versendung aus der Datenbank ausgelesen werden.


Links hat der Kunde ein großes Feld, in das er mit einem WYSIWYG-Editor Text und Formatierungen einfügen kann.

Das läuft jetzt schon seit geraumer Zeit problemlos.

Der Kunde kann sich immer beim Bearbeiten mit jedem Speichern (wenn er will) sich das Ergebnis zuschicken lassen.
 
Hallo Jürgen,

genau so ist es auch geplant!
Die Frage ist... hast Du das über eine bestehende Software gelöst? Oder setzt Du auf eine Eigenentwicklung?

Wir stellen uns die Frage ob sich eine Eigenentwicklung in dem Maße rechnet... Wir haben einige Kunden die auf Newsletter setzen. Trotzdem wird man nicht die Manpower aufbringen können wie eine der beiden großen OpenSource-Systeme oder aber ein Unternehmen, dass sich darauf spezialisiert hat.

Gruß
Flo
 
QUOTE (Florian Gehringer @ Di 19.01.2010, 13:22)Die Frage ist... hast Du das über eine bestehende Software gelöst? Oder setzt Du auf eine Eigenentwicklung?


Das hatte sich vor etwa einem Jahr als Ergänzung innerhalb von Server-Daten ergeben, also innerhalb einer Infrastruktur, in der rasch Tabellen und Eingabeseiten hinzugefügt werden können.

Verschiedene Kunden hatten bereits Tabellen für Personen. Ein Kunde fragte dann nach einer ausgereiften Newsletter-Logik.

Eine einfache gab es bereits. Hier sollten aber personalisierte Newsletter mit Protokollierung als Html möglich sein.

Ergebnis war, daß das im Gesamtsystem dazugebaut wurde: Personen können Gruppen zugeordnet werden. Es lassen sich Mailings erstellen, wobei ein Mailing zu verschiedenen Zeitpunkten an unterschiedliche Gruppen geschickt wird. Ferner Html-Vorlagen plus die Möglichkeit, Attachments anzuhängen. Und eben solche Erweiterungen, daß rechts eine Spalte mit News steht, die zum Versendezeitpunkt als das Ergebnis einer Abfrage aus der Datenbank geholt wird.

Ein Kunde nutzt das inzwischen regelmäßig, um Newsletter zu verschicken. Ein anderer Kunde verwendet das, um Nachrichten an interne Mitarbeiter, externe Mitarbeiter und Kunden unterschiedlichen Typs zu verschicken. Das wird bsp. am Wochenende geschrieben und dann auf 'Versand Dienstag, 09:00' gesetzt.


QUOTE (Florian Gehringer @ Di 19.01.2010, 13:22)Wir stellen uns die Frage ob sich eine Eigenentwicklung in dem Maße rechnet... Wir haben einige Kunden die auf Newsletter setzen. Trotzdem wird man nicht die Manpower aufbringen können wie eine der beiden großen OpenSource-Systeme oder aber ein Unternehmen, dass sich darauf spezialisiert hat.


Typisch innerhalb von Server-Daten ist, daß die Kunden ihre Daten ja gerade nicht in ein auch kostenloses Drittsystem exportieren möchten - weil ihnen das einfach Zeit frißt, die sie nicht haben. Umgekehrt hat die Entwicklung natürlich Zeit gekostet, weil das zunächst auf so einem abstrakten Level abläuft, daß das anschließend für einzelne Kunden nur noch konfiguriert wird: Einige Tabellen erstellen, bestimmte Spalten speziell auszeichnen und die Eingabeformulare bereitstellen. Ab dann funktioniert das 'von selbst'. Der nächste Kunde hat das dann innerhalb von ein bis zwei Tagen.
 
Hallo Jürgen,

Danke für die schnelle Antwort.
Deine Beschreibung klingt nach einer ähnlichen Situation wie hier im Haus... Nennen wir es mal "organisch gewachsen" ;-)

Wir sammeln die Adressen bisher über bzw. im CMS. Ggf. würde man den Bestand direkt in das Dritt-System schieben und künftig direkt eintragen oder einen automatisierten Abgleich bauen. Das sehe ich nicht unbedingt als Problem.

Generell haben wir auch aus den Anfragen heraus jeweils kleinere Systeme gebaut. Die erfüllen soweit auch Ihren Zweck, allerdings ist es eine einfache und individuelle Umsetzung für die entsprechenden Kunden.

Genau aus dem Gedanken heraus nicht immer wieder fast bei 0 anfangen zu müssen bzw. ein "richtiges" System bieten zu können, stehen wir vor der Entscheidung entweder das passende System zu finden oder aber eine ordentliche Eigenenwicklung in Angriff zu nehmen.

Ich tendiere prinzipiell zur Eigenentwicklung... Umgekehrt habe ich allerdings auch Respekt vor dem Folgeaufwand.
Die Anforderungen verändern sich, Server auf den Blacklisten, Tracking soweit möglich... Soll heissen: Aus einem kleinen System wird schnell ein System das doch recht umfangreich wird und auch künftig supportet werden will.

Dann wiederum drängt sich die Frage auf ob der Aufwand für einen Hand voll Kunden wirklich lohnt.
Sicher werden darüber künftig auch weitere Kunden abgewickelt werden können, allerdings werden es sicher nicht über Nacht 100 Kunden werden.;-)

Was meint ihr? Wie seht ihr die Situation? Wie würdet ihr es anpacken?

Gruß und vielen Dank
Flo
 
QUOTE (Florian Gehringer @ Di 19.01.2010, 18:31)Generell haben wir auch aus den Anfragen heraus jeweils kleinere Systeme gebaut. Die erfüllen soweit auch Ihren Zweck, allerdings ist es eine einfache und individuelle Umsetzung für die entsprechenden Kunden.


Ich muß gestehen, daß genau das etwas ist, was ich nur als Horrorsituation bezeichnen kann.

Diverse individuelle Systeme, jedes alleine rechnet sich kaum, zum Erweitern ist jedes zu aufwendig. Die Kunden wollen mehr, eigentlich würden sie gerne wachsen. Das geht aber nicht so richtig. Gleichzeitig lassen sich auch alle Einzellösungen so gut wie nicht auf eine Lösung umziehen, so daß sich der Aufwand pro Lösung verringern würde.


QUOTE (Florian Gehringer @ Di 19.01.2010, 18:31)Deine Beschreibung klingt nach einer ähnlichen Situation wie hier im Haus... Nennen wir es mal "organisch gewachsen" ;-)


Meine Situation ist eine gänzlich andere. Alle Kunden nutzen ein einziges System, das auf gemeinsamer Hardware läuft, die Kunden sind aber gegeneinander abgeschottet. Dessen Grundentwicklung hat mich zwar fast drei Jahre (2003 - Ende 2005) gekostet und im ersten Jahr ein sattes Minus eingefahren. Aber baut man eine Erweiterung (so wie diese Newsletter-Logik) einmal im Gesamtsystem ein, dann kann das von da an jedem Kunden in relativ kurzer Zeit zur Verfügung gestellt werden.



QUOTE (Florian Gehringer @ Di 19.01.2010, 18:31)Ich tendiere prinzipiell zur Eigenentwicklung... Umgekehrt habe ich allerdings auch Respekt vor dem Folgeaufwand.
Die Anforderungen verändern sich, Server auf den Blacklisten, Tracking soweit möglich... Soll heissen: Aus einem kleinen System wird schnell ein System das doch recht umfangreich wird und auch künftig supportet werden will.

Dann wiederum drängt sich die Frage auf ob der Aufwand für einen Hand voll Kunden wirklich lohnt.


Solange für einzelne Kunden programmiert werden muß, dürfte sich das fast nie rechnen. Es geht in einem insgesamt eher hochpreisigen Segment, falls das System so starke Automatisierungen zuläßt, daß man Kunden schnell etwas zu Festpreisen anbieten kann, so daß Kunden dann ausbauen, sich das Ausbauen aber auch finanziell leisten können. Allerdings rechnet sich das nicht für eine Handvoll von Kunden, weil dann natürlich auch die Anforderungen an die gemeinsam genutzte Hardware höher liegen.



QUOTE (Florian Gehringer @ Di 19.01.2010, 18:31)Was meint ihr? Wie seht ihr die Situation? Wie würdet ihr es anpacken?


Ich bin froh, daß ich nicht in einer solchen Situation drinstecke. Ist zwar hart, hilft dir auch nicht weiter, stimmt aber. Als für mich so um 2002 die Frage anstand, ob ich ins Web gehe, war das eine zentrale Frage: Viele kleine Lösungen, die sich alle nicht richtig rechnen ... sind keine Lösung.
 
Ich gebe Dir soweit vollkommen Recht.

QUOTE Ich bin froh, daß ich nicht in einer solchen Situation drinstecke. Ist zwar hart, hilft dir auch nicht weiter, stimmt aber. Als für mich so um 2002 die Frage anstand, ob ich ins Web gehe, war das eine zentrale Frage: Viele kleine Lösungen, die sich alle nicht richtig rechnen ... sind keine Lösung.


Wir sind hauptsächlich in der technischen Umsetzung von Websites tätig. Die Umsetzungen sind insofern immer individuell.
Mit dem Newsletter-System würden wir uns damit gewissermaßen in einen neuen Sektor bewegen.
Dennoch zur Sicherheit - wir reden natürlich nicht von einer Hobby-Klitsche
wink.gif
- es hat dann noch ein gewisses Niveau. Wir wollen also nicht mal kurz ein ranziges Tool bauen, dass es schon 100fach besser und günstiger gibt. Zumal unsere Kunden zum Glück auch wissen, dass Newsletter genauso wie Zeitungsanzeigen o.ä. am Ende auch erstmal Geld kosten. Wir zielen nicht auf Spottleistungen für Spottpreise ab
wink.gif


Zur Erklärung - den Punkt habe ich wohl zu schwammig fomuliert:
Die Insellösungen basieren prinzipiell auf dem gleichen Kern - laufen allerdings als Insel.
Wir haben damit das Redaktionsystem erweitert. Fakt ist allerdings, dass man innerhalb dieses Content-Frameworks das Newsletter Management unterbringen kann - es bleibt aber ein erweitertes Redaktionssystem und nicht ein eigenständiges, vollwertiges Newsletter-System.

Wir könnten einen Teil der Entwicklungskosten abfedern, da wir mehrere Kunden haben die bereits ein System gekauft haben.
Deswegen stehen wir ja vor der Frage ob wir wieder das bestehende System verwenden und damit in Zukunft recht flexibel sind/werden/bleiben. Es werden mehr Inseln die autark laufen... - Soweit so gut. In diesem Fall hätte man es über ein OpenSource-Tool zumindest soweit offen, dass man ggf. updaten kann ohne weitere eigenen Entwicklungen. Ein Baustein basiertes OpenSource-Tool habe ich aber noch nicht gefunden.

Die Alternative wäre eben ein eigenständiges System zu bauen. Die Inseln natürlich dann auf das neue Tool integrieren und künftig mit einer eigenen Lösung und einem zentralen Kernsystem besser aufgestellt zu sein.

Trotzdem scheue ich mich vor dem Aufwand der womöglich noch kommen mag.

Auch wenn das pauschal schwer zu sagen ist - ab welchen monatlichen Einnahmen hältst Du/Ihr es für sinnvoll es zu betreiben.
Letztendlich muss ich das natürlich an meiner Stelle entscheiden. Eure Meinung interessiert mich natürlich trotzdem
smile.gif


Mal ganz grob - ohne es durchgerechnet zu haben:
500 € Umsatz / Monat mit ca. 15 Newsletter-Kunden
Damit würde ich behaupten lässt sich so ein System supporten ohne, dass man zwingend neue Kunden für das System gewinnen müsste um es rentabel zu betreiben.

Alles was darüber hinaus geht würde es leichter machen...

Was sagt Ayom dazu!?
wink.gif


Gruß
Flo
 
QUOTE (Florian Gehringer @ Di 19.01.2010, 22:59)Auch wenn das pauschal schwer zu sagen ist - ab welchen monatlichen Einnahmen hältst Du/Ihr es für sinnvoll es zu betreiben.


Das läßt sich aus der Entfernung praktisch nicht abschätzen. In Server-Daten stecken drei Jahre Fulltime-Entwicklung, seit dem Start dürften nochmals 2 Jahre dazu gekommen sein. Die monatlichen Fixkosten sind vierstellig - aber dafür sind bsp. die Verwaltungsports durch die Hardware-Firewall komplett abgeschottet. Da kommt dann einfach nichts mehr durch.

Relativ heikel finde ich das:


QUOTE (Florian Gehringer @ Di 19.01.2010, 22:59)Die Insellösungen basieren prinzipiell auf dem gleichen Kern - laufen allerdings als Insel.


Es passieren halt eigene Fehler, grade dann, wenn man etwas dazu baut. Da ist es ein immenser Unterschied, ob ich das in einem System fixe - und gut iss - oder ob ich womöglich fehlerhaften Code erst auf 10 oder 20 Inseln verteile, dann einen Fehler finde - und ich die Verteilungsaktion erneut machen darf. Mit jedem Kunden mehr verschlimmert sich dieses Problem. Das ist durchaus ein Vorteil innerhalb von Server-Daten: Interessenten, die eine Lösung haben wollen, die auf ihrem eigenen Server läuft, die schicke ich sofort wieder weg. Es sind nur Kunden, die das System auf gemeinsamer Hardware und auf Mietbasis nutzen. Das reduziert natürlich auch das Problem möglicher Forderungsausfälle, damit wiederum bleiben heikle Interessenten von vornherein weg.



QUOTE (Florian Gehringer @ Di 19.01.2010, 22:59)500 € Umsatz / Monat mit ca. 15 Newsletter-Kunden


Ist das realistisch? Mir ist bsp. völlig egal, wieviele Newsletter meine Kunden verschicken, das wird weder gezählt noch wird das Trafficvolumen ermittelt. Bei Newslettern entstehen einmalige Einrichtungskosten (i.d.R. zwischen 440 - 880 Euro), das wars. Die Kunden zahlen Miete in Abhängigkeit von der Gesamtgröße der Datenbank, seit gut einem Jahr (seit dem Umstieg auf neue Server) läuft das ohnehin mit einer dezidierten 200 MBit/Anbindung und einer 200 MBit-Flatrate. Wenn da ein Kunde einen Newsletter verschickt (das ist ohnehin gebremst, ein paar Sekunden liegen pro Verschickung), dann fällt das nicht ins Gewicht. Mir hat das erspart, die ganze Infrastruktur für eine Messung und Abrechnung aufzubauen.

Ein Kunde mit Newsletterlogik braucht dafür aber mehr Platz, daran verdiene ich. Bei Kunden, die euer Angebot auf eigener / Hoster-Hardware nutzen, entfällt diese Verdienstmöglichkeit höherer laufender Einnahmen komplett.


500 Euro / Monat sind 6000 Euro / Jahr, bei 15 Kunden 400 Euro Jahresumsatz / Kunde. Bewegen sich die Kunden in einem Segment, so daß die Kunden das zahlen können?



QUOTE (Florian Gehringer @ Di 19.01.2010, 22:59)Die Alternative wäre eben ein eigenständiges System zu bauen. Die Inseln natürlich dann auf das neue Tool integrieren und künftig mit einer eigenen Lösung und einem zentralen Kernsystem besser aufgestellt zu sein.

Trotzdem scheue ich mich vor dem Aufwand der womöglich noch kommen mag.


Wie lange würde die Entwicklung dauern? Wenn man dafür 2 - 3 Monate ansetzt (minimal 10.000 Euro), dann dürfte das lange dauern, bis diese Kosten wieder eingespielt sind.

Die Gegenfrage ist natürlich: Gibt es die Gefahr, daß Ihr Kunden verliert, wenn Ihr da nicht etwas Leistungsfähigeres anbietet?
 
QUOTE (Florian Gehringer @ Di 19.01.2010, 22:59)
Die Insellösungen basieren prinzipiell auf dem gleichen Kern - laufen allerdings als Insel.


Es passieren halt eigene Fehler, grade dann, wenn man etwas dazu baut. Da ist es ein immenser Unterschied, ob ich das in einem System fixe - und gut iss - oder ob ich womöglich fehlerhaften Code erst auf 10 oder 20 Inseln verteile, dann einen Fehler finde - und ich die Verteilungsaktion erneut machen darf. Mit jedem Kunden mehr verschlimmert sich dieses Problem. Das ist durchaus ein Vorteil innerhalb von Server-Daten: Interessenten, die eine Lösung haben wollen, die auf ihrem eigenen Server läuft, die schicke ich sofort wieder weg. Es sind nur Kunden, die das System auf gemeinsamer Hardware und auf Mietbasis nutzen. Das reduziert natürlich auch das Problem möglicher Forderungsausfälle, damit wiederum bleiben heikle Interessenten von vornherein weg.


Exakt - Genau deshalb wollen wir nachdem es etwas mehr in die Breite geht ja eine sinnvollere Lösung. Die Systeme die bereits laufen konnte man überblicken und im Zweifel per Hand updaten. Es werden aber zuviele im das auf Dauer so handhaben zu können.
Bei den Inseln sind wir natürlich nicht verpflichtet noch irgendwie etwas zu tun. Die "neue" Lösung ist logischerweise auch auf einem zentralen System auf Mietbasis angedacht. Alles andere macht in der Breite keinen Sinn.



QUOTE 500 Euro / Monat sind 6000 Euro / Jahr, bei 15 Kunden 400 Euro Jahresumsatz / Kunde. Bewegen sich die Kunden in einem Segment, so daß die Kunden das zahlen können?


Die die wir haben bewegen sich in diesem Rahmen. Die die wir haben wollen auch
wink.gif

Ich habe kein Interesse daran auf Basis der Empfängerzahlen abzurechnen. Natürlich gibt es im Zweifel eine Obergrenze. Ob es aber 500 oder 50.000 Empfänger sind ist für mich aber eher irrelevant - Dafür ist über die Miete eine gesunde Basis abgedeckt. Die Einrichtungspauschale ist in diesem Fall ja auch noch nicht berücksichtigt.


QUOTE Die Gegenfrage ist natürlich: Gibt es die Gefahr, daß Ihr Kunden verliert, wenn Ihr da nicht etwas Leistungsfähigeres anbietet?


Nein, das ist nicht der Fall. Wir würden damit unsere Kunden gerne ein Stück weit mehr an uns binden und im zweiten Schritt ein Stück unabhängiger vom Projektgeschäft machen.


QUOTE Wie lange würde die Entwicklung dauern? Wenn man dafür 2 - 3 Monate ansetzt (minimal 10.000 Euro), dann dürfte das lange dauern, bis diese Kosten wieder eingespielt sind.


Aufwand und Kosten schätze ich ähnlich. Allerdings finde ich, dass man sie in einem überschaubaren Rahmen wieder einspielen kann.
Kombination Mietbasis und Einrichtungspauschale. Auch das würde mit 15 Kunden funktionieren können. Klaro muss man das als Investition sehen und dementsprechend auch nicht mit dem 1 Kunden darauf Geld verdienen.
Letztendlich spielen ja über den reinen Einnahmen/Ausgaben ja auch noch strategische Gesichtspunkte.

Soweit so gut... Danke für den ausführlichen Austausch!
Sofern wir uns für die Entwicklung entscheiden versuche ich ggf. die Entwicklung bzw. das finale Tool hier zur Debatte stellen.

Gruß und wie immer vielen Dank an Ayom und im besonderen an Dich Jürgen.

Florian
 
Zurück
Oben