Ankündigung

Einklappen
Keine Ankündigung bisher.

Suche Devs für Skalierbare Call Center Software

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Suche Devs für Skalierbare Call Center Software

    Hallo zusammen,

    *** TOPIC ***

    Ich baue aktuell an einer skalierbaren, cloudbasierten Call Center Software und suche noch Entwickler. Ich arbeite ca. seit einem Jahr in der Branche und musste feststellen, das die aktuell verwendete Software nicht nur Technologisch auf den Stand von Windows 2000, sondern auch noch extrem kostspielig ist. Die aktuell verwendete Software muss installiert werden und hat von Usability und Design noch nie was gehört. Ich habe lange gesucht um einen guten Anbieter zu finden, habe aber schlussendlich keinen Gefunden, der meine Anforderungen entsprach (überzeugt euch einfach selber und googelt mal nach den Begriffen: 'Call Center Software'). So habe ich angefangen selber eine Software zu entwickeln. Ich arbeite seit längern mit Twilio (http://twilio.com) zusammen, eine Plattform für Entwickler um Telefonie, SMS und Videoübertragungen zu programmieren. Das ganze wird eine responsive Webapp und basiert auf dem Google Material Design (https://www.google.com/design/spec/m...roduction.html): trash.PNG




    Screenshot der Settingspage (Layout)


    Aktueller Arbeitstitel: https://devcrm.de/de . Mir ist noch kein Name eingefallen


    *** TECHNOLOGIE ***

    Ich habe im ersten Satz meiner Beschreibung den Begriff 'skalierbar' verwendet. Um die Software global allen optimal Zugänglich zu machen, setzte ich schon seit längerer Zeit auf die Amazon Web Services. Hier ist eine Liste mit aktuellen Technologie, die ich verwenden möchte (für Vorschläge bin ich offen):

    Server:
    Amazon Linux AMI Instanzen (Serverbetriebsystem)
    Amazon Scale Apache2

    Backend:
    PHP
    Amazon dynamoDB
    domPDF (PDF Template Engine)
    Twilio API SDK
    Amazon AWS SDK

    Frontend:
    jQuery (JavaScript-Bibliothek)
    dejavu.js (objekorientiers javascript)
    Handlebars.js (Template Engine)
    Velocity.js (Javascript animation Repleacer)
    JStorage (Javascript Lokaler Speicher)
    History.js (History/State APIs)
    Less.css (Dynamic Styles)
    Google Webfonts (Font)
    Twilio (Call-Client)
    Diverse jQuery Plugins

    Amazon Web Services:
    Cloudfront (CDN)
    EC2 (Server)
    Cloudflare (DNS) / Route53 (DNS)
    S3 (Speicher)
    CodeComit (Versionskontrolle)
    CodeDeploy (Veröffentlicher)

    Payment API:
    2checkout (Paypal, Kreditkarte)

    Telefon/SMS API/Client:
    Twilio

    Ticket/Support System:
    Zendesk

    Design:
    Google Material

    Email:
    Amazon SES

    Team Koordination:
    Bitrix24 (Social Team Network, Aufgabenverteilung, Dokumentation,...), eventuell Jira und Confluence


    *** KONTAKT ***

    Falls du Interesse hast, dann kontaktiere mich einfach auf PHP.de als private Nachricht.


    Fragen beantworte ich hier im Forum oder gerne auch in Skype, Teamspeak oder per Mail.

  • #2
    Verwendest du ein PHP Framework?
    Wenn ja, welches?
    Wenn nein, warum nicht?

    Wie weit ist die Entwicklung ca. voran geschritten (%)?
    Für was ist der Entwickler zuständig?

    Hört sich aufjeden Fall interessant an
    "Software is like Sex, it's best if it's free." - Linus Torvalds

    Kommentar


    • #3
      Hallo,

      Ich habe vor ca 5 Wochen mit dem Projekt begonnen, also rund 2%. Ich hatte letztes Jahr den Auftrag, das ich Twilio (also die Kommunikationsplatform) in SugarCRM einbauen sollte. Da Sugar aber genau so ein *** ist, wollte ich das selber bauen. Es lässt sich davon wahrscheinlich nichts wiederverwerten außer die Erfahrung in der Programmierung mit Twilio und anderen Diensten wie 2checkout oder Zendesk.

      Zum Thema Frameworks:
      Ich habe recht lange überlegt, ob ich eins Verwende und wenn ja welches. Normalerweise verwende ich Laravel, Phalcon oder Symfony (je nach Kundenwunsch). Jetzt kommt aber die Amazon Cloud die viele Sachen anders handhabt als auf einen normalen Server. Statische Dateien (CSS, JS, HBS, Fonts) werden auf S3 gelegt, die wiederum mit Cloudfront ausgeliefert werden, Instanzen bauen sich auf und wieder ab. Ich habe da viel mit befreundeten Programmieren gesprochen (der bei AWS arbeitet) und auch selber ein bissel rumprobiert und es ist zwar möglich Frameworks zu verwenden aber es bringt in diesem Fall auch gewisse Nachteile mit sich. So brauchen Instanzen länge um den Status "Ready" zu bekommen. Ich habe deshalb selber basierend auf dem Default PHP eine AWS passende Struktur aufgebaut. Es gibt eine totale Trennung zwischen den PHP Files (Backend) und dem Frontend. Die Kommunikation erfolgt über eine REST-Json Schnittstelle. Wenn jetzt jemand ankommt und mir erzählt, dass es mit dem und dem Framework auch auf die AWS Anforderungen wunderbar passt und es keine gravierenden Nachteile gibt, ist das Projekt aktuell in einem Status, wo man noch auf eine Framework Switchen kann.

      Zur Frage, für was ist der Entwickler zuständig:

      Das hängt hauptsächlich von den Fähigkeiten des Entwicklers ab. Neben der Programmierung hoffe ich natürlich auch auf die Einbringung von Ideen und anderen Qualifikationen. Lass es Projektmanagament, Systemintegration oder sonst was sein

      Grüße

      Kommentar


      • #4
        Wäre noch interessant. Hast du potenzielle Kunden oder wie willst du das kommerzialisieren?

        Es muss nicht zwingend ein Framework sein. Solange du den Code sauber trennst und Design Patterns optimal einsetzt (wie DI, Services, ...), kann das auch ohne FW sehr gut kommen. Allerdings: Framework != Library. Also bspw. Twig oder so würde ich nicht missen wollen in manchem Projekt.
        [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

        Kommentar


        • #5
          Hallo Christian,

          Zu ersten Frage:

          Ich habe viele Kontakte zu Call Centern Leitern, die übrigends immer nach bessern und vor allem zeitgemäßen Programmen suchen. Das soll aber auf keinen Fall ein Kundenprojekt sein, sondern auf lange Sicht eine global eingesetzte Software.

          Zur weiten Frage bzw. Aussage:

          Ich kenne persönlich Twig jetzt nicht, aber es sieht so aus als wäre es eine Serverseitige Template Engine. Ich bin generell der Ansicht möglichst wenig über den Server laufen zu lassen. Und seit ich mit AWS entwickle, achte ich aufgrund der teuren stundengenauen Abrechnung noch viel stärker darauf, möglichst wenig über den Server laufen zu lassen. Ich benutze als Template Engine http://handlebarsjs.com/. Diese läuft komplett über den Client (also Javascript) und spart so Serverressourcen (und damit Serverkosten) und beschleunigt den Ajax Request. Des weiteren speichere ich nach dem ersten laden von .hbs Dateien die Templates im "Local Storage" (mit http://www.jstorage.info/) und habe daran eine Versionierung gekoppelt. Das heißt sobald eine hbs Datei ändert, werden die Template Dateien neu gezogen (von S3) und wieder im "Local Storage" gespeichert. Außerdem setzt ich auf ein komplette no-reload Strategie, sowie auf eine modulare JS Struktur ("only load, what you need"). So gibt es in der gesamten Anwendung kein einziges neuladen der Seite und Javascript Dateien werden nur nach Gebrauch nachgeladen. Ich setzte außerdem auf die #hash History (https://github.com/cowboy/jquery-hashchange), die wunderbar mit der Backend Struktur zusammen passt.


          Grüße

          Kommentar

          Lädt...
          X