Künstliche Intelligenz: Experten Interview: KI im Handel – Gegenwart oder Zukunft?

Das Trendthema der vergangenen Monate, wenn es um die digitale Transformation geht: Künstliche Intelligenz. Keine Technolgie wird so diskutiert. Und die Ausmaße dieser für die Arbeitswelt, sind nicht mal im Ansatz absehbar. Die Marktführer im Online-Bereich zeigen erste interessante Anwendungen auf, wie Service- und Chat-Bots oder Prognosesysteme zur Betrugsprävention. Doch wie weit ist der Handel in Sachen KI? Wird sie in Zunkuft eine größere Bedeutung im Online- oder Offlinehandel haben? Und wie groß wird die Durchdringung in den nächsten Jahre aussehen? Ein Interview mit Dominique Ziegelmayer, Director Enterprise Platform bei Trusted Enterprise.

KI im Handel – Gegenwart oder Zukunft?

KI im Handel – Gegenwart oder Zukunft?

1. Welche KI-Anwendungen im Handel (Online, Stationär, Crosschannel) kennen Sie (außer vielleicht Amazon Echo)? Können Sie ein, zwei Beispiele nennen?

Dr. Dominique Ziegelmayer: Im Online-Handel sind vor allem Chat- und Service-Bots zu nennen. Dies sind intelligente Programme, die zum Beispiel im Live-Chat auf der Händlerseite zu Produktdetails, einer Lieferung oder einer Retoure befragt werden können. Beeindruckend dabei finde ich, dass die Systeme zum Teil so gut sind, dass man nicht sicher ist, ob man nun mit einem Menschen oder einer Maschine spricht.

Eine Anwendung die gleichermaßen im Online- als auch im Offlinehandel Anwendung findet, sind intelligente Prognosesysteme. Diese lernen zum Beispiel aus vergangenen Bestellungen, bilden Käufergruppen und betrachten saisonale Effekte. Aus den gewonnen Einsichten prognostizieren sie z.B. den Absatz der Produkte und wissen im Optimalfall noch vor dem Konsumenten, was als nächstes bestellt wird. Wozu kann man das brauchen? Ganz einfach, wir können unsere Webseiten auf die entsprechenden Produktgruppen ausrichten, unseren Einkauf veranlassen das Lager entsprechend zu bestücken und letztendlich die Versandzeiten weiter verkürzen.

2. Wie weit ist der Handel in Sachen KI? Stehen wir noch ganz am Anfang oder ist bereits Fortschritt erkennbar? Setzen sich die Handelsunternehmen zumindest mit dem Thema auseinander?

Dr. Dominique Ziegelmayer: Gerade die Marktführer im Online-Bereich zeigen erste interessante Anwendungen auf. Neben Bots und Prognosesystemen ist da zum Beispiel die Personalisierung und die Betrugsprävention zu nennen. Hier sind maschinelle Lernverfahren schlicht nicht mehr wegzudenken. Über alle Marktteilnehmer hinweg würde ich jedoch behaupten, dass wir die Möglichkeiten der KI bei weitem noch nicht ausnutzen.

3. Wo hat Künstliche Intelligenz in Zukunft größere Bedeutung? Im Online- oder Offlinehandel?

Dr. Dominique Ziegelmayer: Für maschinelle Lernverfahren benötigen wir zwei Dinge: Technologie und Daten. Da der Online-Bereich hier offensichtlich besser aufgestellt ist, spreche ich ihm eine gewisse Vorreiterrolle zu. Ich denke jedoch, dass Online- und Offlinehandel zunehmend zusammenwachsen und wir damit eine einheitliche Datenbasis für unsere Algorithmen erhalten werden. Die Vorteile eines solchen holistischen Blicks auf den Kunden sehen wir mit Trusted Enterprise bereits heute, denn nur durch die Kombination von Online- und Offline-Daten kann unsere KI für unsere Kunden treffend entscheiden, wann wir einen Konsumenten um Feedback bitten und an welche Systeme und Abteilungen wir dieses weiterleiten.

4. Hand aufs Herz: Wie groß wird – realistisch/konservativ gesehen – die Durchdringung von KI im Handel in zwei, fünf und zehn Jahren sein?

Dr. Dominique Ziegelmayer: Wenn man sich die rasante Entwicklung der letzten Jahre ansieht, glaube ich, dass es bereits in wenigen Jahren kaum mehr einen Wirtschaftsbereich gibt, der auf KI verzichten kann. Die Datenmengen wachsen mit einer rasanten Geschwindigkeit und das befeuert die Technik doppelt: Zum Einen bilden diese den Ausgangspunkt für maschinelles lernen, zum Anderen machen Sie eine intelligente Datenselektion notwendig. Denn niemand möchte morgen noch hunderte Dokumente prüfen, wenn nur 2-3 relevant für eine Entscheidung sind. Diese Entwicklung wird auch nicht vor dem Handel haltmachen und so gehe ich von einer starken Durchdringung in den nächsten 5-10 Jahren aus.

5. Welche Rolle wird KI im B2B-Handel spielen? Wird der Einfluss hier vielleicht noch viel größer sein, weil Kundenbeziehungen länger und intensiver, und gleichzeitig Investitionen größer sind?

Dr. Dominique Ziegelmayer: Gerade auf Grund der intensiven und persönlichen Kundenbeziehungen im B2B-Bereich, wird die Rolle der KI vermutlich geringer sein als in einem Massengeschäft. Insgesamt denke ich aber, dass es auf die Anwendungsfälle und weniger das Kundensegment ankommt.

(Quelle: PM der Trusted Shops GmbH vom 14.02.2017)

10. plentymarkets Online-Händler-Kongress

Am 17.03.2017 ist es wieder soweit und die plentymarkets GmbH öffnet die Pforten des historischen Kongress Palais in Kassel für Partner, Kunden und Besucher aus ganz Europa, um dem E-Commerce bei einem unvergesslichen Kongress die Ehre zu erweisen – der traditionelle Jahresauftakt der Branche beim plentymarkets Online-Händler-Kongress feiert in diesem Jahr seinen 10. Jahrestag und wird erneut für Jedermann etwas zu bieten haben. Nicht nur in Sachen Fachvorträge, Workshops und Networking, sondern auch für das Entertainment wird zum Jubiläum bestens gesorgt sein, sodass auch dieser Kongress eine kurzweilige und gehaltvolle Veranstaltung verspricht.

Der E-Commerce – unendliche Weiten.

Die Reise durch das Universum des E-Commerce wird von zahlreichen Branchenexperten begleitet, die in spannenden Vorträgen und praxisorientierten Workshops zeigen, wie sich der Online-Handel von morgen mit plentymarkets beherrschen lässt. Mit dabei sind u. a. Adrian Hotz, Marcus Diekmann, Jon Christoph Berndt oder Henning Heesen. Sie präsentieren die wichtigsten E-Commerce-Themen und -Trends, die der Online-Händler von morgen nicht verpassen sollte. Dabei eignen sich alle Vorträge sowohl für erfahrene Händler und plentymarkets Nutzer wie auch für Neueinsteiger und Durchstarter. Neben der Vorstellung brandneuer Features des E-Commerce-ERPs liefert plentymarkets praxisnahe Antworten auf Fragen zu Omni- & Multi-Channel, die Einbindung des stationären Handels mit plentyPOS, Plugin-Entwicklung und vielem mehr.

Jetzt Tickets buchen!

Eines der Highlights wird die Vorstellung des neuen Shop-Templates Ceres sein. Dieses Template wurde als Plugin mit den neusten Technologien entwickelt und erfüllt alle Standards die ein ansprechender, SEO-optimierter, nutzerfreundlicher und blitzschneller Shop 2017 braucht, sodass nicht nur Händler und Kunden, sondern auch Google diesen Shop lieben werden.

Außerdem erhalten alle Besucher im kongressinternen Messebereich von rund 60 namhaften Ausstellern, darunter Firmen wie PayPal, Rakuten, trustedshops oder DHL und vielen weiteren Agenturen und Dienstleistern, wertvolle Ideen und Angebote für ihr Business und knüpfen spielend leicht neue Kontakte. Auch plentymarkets selbst ist natürlich mit einem großen Stand vertreten, die plentyCrew beantwortet live und vor Ort Fragen und berät Kunden und Interessenten zum gelungenen Einsatz des E-Commerce-ERP plentymarkets.

Mehr Informationen zu Speakern und Vorträgen sowie den vorläufigen Timetable gibt’s im Programm.

Neu dabei: Parallelveranstaltung plentyCodeCamp „im Zeichen der Plugins“

Bei plentymarkets dreht sich in naher Zukunft alles um Plugins. Plugins stehen für Individualität, Anpassbarkeit, Flexibilität und unendliche Möglichkeiten im E-Commerce. Das Unternehmen hatte bereits im letzten Jahr bekannt gegeben, seine Software für Plugins aufzubrechen und so auch Fremdentwicklungen zuzulassen und ganz einfach an das E-Commerce-ERP anbinden zu lassen. Wer als Online-Händler keine eigenen Plugins entwickeln oder entwickeln lassen möchte, wird in Zukunft im kommenden Plugin-Marktplatz plentyMarketplace eine riesige Auswahl an Plugins finden, die für individuelle Anpassungen im Backend, Frontend oder als Erweiterung benötigt werden. Das plentyCodeCamp geht nach den plentyDays 2016 zum 10. Online-Händler-Kongress in die zweite Runde und bietet Entwicklern und Plugin-Interessierten die beste Gelegenheit, das gesamte Know-How rund um plentymarkets Plugins direkt aus erster Hand abzuholen. Das Spektrum reicht von Shop-Plugins über Payment- und Backend-Plugins bis zur Anbindung ganzer Marktplätze und Fulfillment-Dienstleister mit dieser Technologie. Von den Grundlagen über die verwendete Technik bis zu Best Practice-Beispielen und Live-Coding Sessions ist für Jedermann – egal mit welchem Wissensstand – etwas dabei.

Inspirieren lassen, Lernen, Networken, Schlemmen – und Feiern!

Zum Kongress-Ausklang wird wie in jedem Jahr der begehrte plentyAward verliehen. Dieser Award kürt nach Expertenauswahl und Community-Voting die 3 besten plentymarkets-Shops in Sachen Usability, Performance und Design.

Doch nicht nur die Gewinner des Awards finden am Abend genug Grund zum Feiern. Wer nach der geballten Ladung E-Commerce-Wissen noch nicht genug hat, ist nach dem Kongress herzlich zur Aftershowparty in der Weinkirche Kassel eingeladen, um für 2017 noch einmal die Korken knallen zu lassen. Party-Gäste genießen hier intergalaktisch gute Drinks und Leckereien, schmieden zusammen fantastische Zukunftspläne und lassen sich von atmosphärischer Musik und Lichtshow durch eine unterhaltsame und gesellige Feier begleiten.

Hinweis: Der Eintritt zur Party ist nur mit separat erhältlichem Party-Ticket möglich. Das Party-Ticket ist nur in Verbindung mit einem Kongressticket buchbar und kostet 29,- Euro. Party-Tickets sind limitiert auf 500 Stück und nur erhältlich solange der Vorrat reicht.

Jetzt Tickets buchen!

Continuous Delivery Teil 2 – Ansible Tipps

Im ersten Teil dieser Blogserie haben wir den allgemeinen Entwicklungsworkflow bei shoptimax beleuchtet – in diesem Teil soll es um konkrete Tipps zum Deployment mit Ansible gehen.

Gitlab CI und Ansible kombinieren

Wie bereits beschrieben nutzen wir für automatisiertes Deployment unserer Projekte aus GIT heraus Gitlab CI. Je nach GIT- Branch (bei uns sind das normalerweise „develop“, „stage“ und „master“) löst Gitlab CI unterschiedliche Aktionen aus, welche in „.gitlab-ci.yml“-Dateien in den jeweiligen Projekten definiert sind.
In der Regel werden Änderungen in den „develop“-Branches direkt per Gitlab Runner auf interne Testserver deployed. Optional können hier (und/oder bei einem Git-Push in weitere Branches) Code-Style Prüfungen oder z.B. Codeception-Tests durchgeführt werden, die dann in einem Gitlab-internen Docker-Container automatisch gestartet werden.

Änderungen an „stage“- oder „master“-Branches hingegen werden in der Regel auf externe Server ausgespielt, sei es ein geteilter Staging-Server von shoptimax oder direkt ein Kunden-System. Hier kommt dann unser Ansible-Repository mit unterschiedlichen sog. „Playbooks“ ins Spiel.

Dazu wird im ersten Deployment-Step (welcher im Docker-Container abläuft) unser internes Ansible-GIT-Repository gecloned. Dieses wird am Ende des Durchlaufs in einem sog. Gitlab CI-Artefakt gespeichert, welches in weiteren Deployment-Steps dann ebenfalls zur Verfügung steht. Damit können nacheinander die unterschiedlichen Playbooks in den verschiedenen „Stages“ des Deployments aufgerufen werden. In einer „scripts“-Sektion der .gitlab-ci.yml wird also z.B. folgendes definiert:

- git clone --depth 1 --branch master git@repo:repo_group/ansible_deployment.git ansible

Für das zu erstellende Artefakt wird weiterhin festgelegt, welche Verzeichnisse darin gespeichert werden sollen und wie lange es auf dem Gitlab-Server vorgehalten wird, z.B.

artifacts:
    paths:
    - build
    - ansible
    - deploy_scripts
    expire_in: 5 days

Diese Artefakte können vor Ablauf dieser Zeitspanne übrigens auch über die Gitlab-Oberfläche per Browser heruntergeladen werden.

In der .gitlab-ci.yml wird also definiert, wo das Ansible-Verzeichnis liegen soll und an welchen Stellen im Prozess Ansible Playbooks aufgerufen werden:

variables:
  SHOP_BUILD_DIR: "/builds/oxid/$CI_PROJECT_NAME"
deploy_stage:
  stage: deploy
  environment: deploy_stage
  tags:
    - docker
  script:
- cd $SHOP_BUILD_DIR/ansible/
- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 custom_source_folder=/../temp shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} ..." -vv

Timestamp-Datei für unabhängige Playbooks

Um eine gemeinsame Referenz für die unterschiedlichen Playbooks zu haben, die ja meist in verschiedenen Build-„Stages“ ablaufen (z.B. lädt das erste Playbook ein *.tar.gz hoch und packt es auf dem Server in Verzeichnis X aus, das zweite Playbook legt dann Symlinks auf dieses Verzeichnis an usw.), wird ein gemeinsamer Timestamp verwendet (z.B. auch für die Verzeichnis-Namen der Deployments). Ein solcher Timestamp wird bereits beim Clone des Ansible-Repositories erzeugt und in einer txt-Datei gespeichert:

- date +%Y-%m-%d_%H-%M-%S > ansible/timestamp.txt

In den Playbooks wird jeweils geprüft, ob es diese Datei gibt, falls ja wird der Timestamp ausgelesen und über diesen Timestamp dann das zugehörige Verzeichnis gesucht / weiter verarbeitet.
Gitlab CI cloned das Ansible Repository in einen projektspezifischen Docker-Container und speichert die Dateien im Build-Artefakt, inkl. der Timestamp-Datei.
Dadurch bleibt der Timestamp während des gesamten Deployment-Prozesses über die verschiedenen, zeitlich nacheinander ablaufenden „Stages“ quasi als „Referenz“ vorhanden und jedes Playbook operiert so auf demselben Verzeichnis.

Projektspezifische Kommandos und Symlinks in JSON-Dateien

Mit Ansible ist es sehr einfach, JSON-Dateien einzulesen und abzuarbeiten. Wir verwenden z.B. JSON-Dateien, um während eines Deployments individuelle Symlinks je nach Kundenprojekt anzulegen oder um auf dem Zielserver projektspezifische Kommandos (Shell oder auch PHP) beim Deployment auszuführen.
Z.B. kann hier ein Shell-Script aufgerufen werden, das eine Datenbank-Sicherung durchführt oder ein PHP-Script, welches das „tmp“-Verzeichnis des Shops leert, Datenbank-Views neu erzeugt oder bestimmte Module automatisch de-/aktiviert usw.
Damit müssen wir keine Fallunterscheidungen oder zusätzliche Variablen und Tasks in Ansible selbst definieren, sondern können in das Kundenprojekt einfach entsprechende JSON-Dateien in das GIT-Repository einchecken. Diese können sogar z.B. pro Git-Branch oder Zielsystem unterschiedlich sein, da die Pfade bzw. Dateinamen der JSON-Dateien im jeweiligen Deployment-Step in der „.gitlab-ci.yml“-Datei als Kommandozeilen-Parameter an das Ansible Playbook übergeben werden können.

- ansible-playbook -s ./deploy.yml --extra-vars "target=customer1 shop_docroot=${SHOP_DOCROOT_STAGE} shop_deploy_dir=${SHOP_DEPLOY_DIR_STAGE} cust_htaccess_file=.htaccess_prelive cust_config_file=config.inc.prelive.php custom_commands_path=/../src/configs/commands.json custom_symlinks_path=/../src/configs/symlinks.json" -vv

So kann es z.B. eine „commands_live.json“ und eine „command_stage.json“ im Projekt geben, in welchen jeweils unterschiedliche Shell- oder PHP-Kommandos definiert sind.

Um z.B. eine JSON-Datei mit einem Array von Kommandos einzulesen, verwenden wir im Ansible-Playbook folgendes:

commands_path: "{{ custom_commands_path | default('/files/cmds.json') }}"
commands_json: "{{ lookup('file','{{ inventory_dir }}{{ commands_path }}') | from_json }}"

Die Variable „custom_commands_path“ (Pfad zur JSON-Datei) kann per Kommandozeilen-Parameter projekt-spezifisch übergeben werden, der aufgerufene Jinja2-Filter „from_json“ liest das JSON aus der Datei in eine Ansible-Variable ein.

Das erhaltene JSON kann dann in einer Schleife („with_items“, s.u.) abgearbeitet werden, die erkannten Kommandos werden dann ausgeführt. Hier ein Beispiel für eine solche JSON-Datei:

{
  "commands":[
    {"path":"/application/views/flow/", "ctype":"shell", "cmd":"ls -altr", "stage":"prerelease", "host":"master01" },
    {"path":"", "ctype":"php", "cmd":"oxid cache:clear" }
 ]
}

Zudem kann man definieren, ob man ein Kommando „prerelease“, also vor dem eigentlichen „Aktivieren“ des Deployments (z.B. ein Backup erstellen) oder aber erst hinterher (z.B. den Cache löschen) ausführen möchte. Die Variable „host“ schränkt die Aktion optional z.B. bei einem Multi-App-Server System auf einen bestimmten Host ein.

Hier ein Ansible-Task, welcher „post-release“ Shell-Kommandos ausführt:

- name: Additional Release Shell commands
  shell: "{{ item.cmd }}"
  args:
    chdir: "{{ release_dir }}/{{ release_subfolder }}{{ item.path }}"
  with_items: "{{ commands_json.commands }}"
  register: command_result
  when:
    - item.ctype != 'php'
    - ((item.stage is defined) and (item.stage != 'prerelease')) or (item.stage is not defined)
    - ((item.host is defined) and (item.host == ansible_nodename or item.host == '')) or (item.host is not defined)

Patchen von .htaccess-Dateien

Beim Release eines Live-Shops will man in manchen Fällen den Shop kurzzeitig für Kunden „sperren“, damit die Agentur und/oder der Shopbetreiber den Shop testen, Testbestellungen ausführen usw. können. Dazu verwendet man in der Regel einen Eintrag in der „.htaccess“-Datei im Shop-Verzeichnis, welche den Zugriff auf die Website / den Shop z.B. nur für bestimmte IPs erlaubt und andere Benutzer auf einen sog. Baustellen-/Offline-Seite weiterleitet oder einen Passwort-Schutz ergänzt.

Unsere Ansible-Playbooks können optional in einem ersten Deployment-Schritt den Inhalt einer frei definierbaren Datei in die .htaccess-Datei des Shops einfügen, welche z.B. eine bestimmte IP-Freigabe enthält. Dann kann, nach Freigabe bzw. Aktivierung des neuen Deployments über das Gitlab CI Backend die Agentur bzw. der Shopbetreiber den Shop testen, um im Erfolgsfall schliesslich ebenfalls über einen Button im Gitlab-CI Backend das letzte Playbook zu starten („publish“). Dadurch wird der zusätzliche Eintrag wieder aus der .htaccess-Datei entfernt. Im Gitlab CI Backend sieht das z.B. so aus:

Die vier Haken im Bild sind die Build-„Stages“, die in der „.gitlab-ci.yml“-Datei definiert sind.
In Stage 1 wird der Shop in einem internen Docker-Container „zusammengebaut“ und ein Artefakt inkl. Ansible-Playbooks erstellt, ab Stage 2 wird Ansible aufgerufen („deploy“ – „release“ – „publish“).
In Stage 2 wird das neue Release via Ansible auf den Server hochgeladen und ein Eintrag in die .htaccess-Datei eingefügt.
In Stage 3 wird der Shop-Symlink auf das neue Deployment-Verzeichnis gesetzt und in Stage 4 wird dann schliesslich der .htaccess-Eintrag wieder entfernt und der Shop ist damit wieder frei zugänglich.

Das Einfügen in die .htaccess-Datei sieht im Playbook wie folgt aus:

- name: Add custom content to .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    #insertbefore: BOF
    insertbefore: "#ANSIBLE_PLACEHOLDER#"
    block: |
          {{ htaccess_include }}
    marker: "# {mark} ANSIBLE BLOCK"
  when:
    - shop_htaccess_final.stat.exists == True
    - (custom_htaccess_include_rel_path is defined) and (htaccess_include != '')

Die Variable „htaccess_include“ enthält den Inhalt der zu inkludierenden Datei, sofern vorhanden. Der Pfad zur Include-Datei kann wieder auf der Kommandozeile übergeben werden:

- ansible-playbook -s ./deploy.yml --extra-vars "... custom_htaccess_include_rel_path=/../src/configs/htaccess.inc"

Entfernt wird der zusätzliche Inhalt am Ende wieder mit folgender Task-Definition:

- name: Remove included content from .htaccess file
  blockinfile:
    dest: "{{ release_dir }}/{{ release_subfolder }}.htaccess"
    marker: "# {mark} ANSIBLE BLOCK"
    content: ""
  when:
    - shop_htaccess_patched.stat.exists == True

Wir verwenden einen Marker („#ANSIBLE_PLACEHOLDER#„) in den .htaccess-Dateien, vor welchem die Datei dann inkludiert wird. Details dazu finden sich in der Doku zum Ansible „blockinfile“-Modul.

Das war es auch schon wieder mit unserem kleinen Ansible-Exkurs, in der nächsten und letzten Folge dieser Deployment-Serie schauen wir dann Gitlab CI genauer unter die Haube!

Update PHPMailer für ältere OXID Versionen

Hintergrund

Zum Ende des vorangegangenen Jahres wurde eine Sicherheitslücke der PHPMailer-Bibliothek bekannt gegeben. Da diese auch im OXID eShop eingesetzt wird, wurde in einem ausführlichen Beitrag seitens OXID auch eine kurze Anleitung zum Update des PHPMailers auf Version 5.2.21 veröffentlicht.
Es wird darauf hingewiesen, dass durch das OXID eShop framework die Basisinstallation trotz dieser Sicherheitslücke absolut sicher ist. Einzig durch externe Frontend-Module, welche die PHPMailer- Bibliothek direkt ansprechen, besteht ein eventuelles Sicherheitsrisiko. Um diese Möglichkeit komplett auszuschließen, wird mitgeteilt, dass die Klassen class.phpmailer.php und class.smtp.php durch die aktuellste Version ausgetauscht werden sollen.
(Quelle: https://oxidforge.org/en/phpmailer-5-2-21-remote-code-execution-oxid-eshop-is-safe.html)

Update für ältere OXID eShop Versionen (< 4.9.8)

Bei älteren Installationen bis zur Version 4.9.7 reicht der Austausch der beiden Klassen jedoch nicht aus. Für den Fall, dass der Mailversand über SMTP erfolgt, sind zusätzliche Anpassungen am Code notwendig. Bis zur Version 4.9.8 wurde in den OXID Core-Klassen oxEmail sowie auch oxDb jeweils nur die PHPMailer-Klasse eingebunden.

oxemail.php:

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;

oxdb.php:

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;

Bei älteren Versionen des PHPMailers ist dies auch ausreichend, da die Klasse SMTP bei Aufruf der Funktion SmtpSend() in der PHPMailer-Klasse inkludiert wird:
require_once $this->PluginDir . ‚class.smtp.php‘;
In der aktuellsten PHPMailer-Bibliothek werden jedoch die einzelnen Klassen (darunter auch SMTP) nicht mehr innerhalb von class.phpmailer.php‘, sondern über eine eigene autoloader-Klasse initialisiert (Quelle: https://github.com/PHPMailer/PHPMailer/wiki/Tutorial).
Um die Funktionalität von PHPMailer bei älteren OXID eShops komplett zu gewährleisten, ist daher eine weitere Anpassung notwendig. Zusätzlich zur beschriebenen Aktualisierung, muss in den beiden OXID Core-Klassen noch class.smtp.php eingebunden werden. Der folgende Code zeigt, wie die aktualisierte Klasse SMTP in OXID, Version 4.9.7, verwendet werden kann. Für weit ältere Installationen ist es nötig, sich an der schon bestehenden Einbindung der PHPMailer-Klasse zu orientieren und diese für class.smtp.php zu adaptieren.

Klasse oxEmail (v4.9.7):

require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.phpmailer.php“;
require oxRegistry::getConfig()->getConfigParam(’sCoreDir‘) . „/phpmailer/class.smtp.php“;

Klasse oxDb (v4.9.7):

include_once getShopBasePath() . ‚core/phpmailer/class.phpmailer.php‘;
include_once getShopBasePath() . ‚core/phpmailer/class.smtp.php‘;

 

Streitschlichtung: Neue Infopflichten für alle Online-Händler ab 1. Februar

Ab 1. Februar kommen neue Infopflichten auf alle Online-Händler zu. Erneut geht es dabei um das Thema Streitschlichtung. Martin Rätze, Rechtsexperte bei Trusted Shops, erläutert, auf welche Neuerungen sich Händler einstellen müssen.

Ab dem 1. Februar 2017 müssen Online-Händler gemäß § 36 Abs. 1 VSBG Verbraucher in ihren AGB und anderweitig auf der Webseite leicht zugänglich, klar und verständlich darüber informieren,

1. inwieweit sie bereit oder verpflichtet sind, an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle teilzunehmen, und
2. über die jeweilig zuständige Verbraucherschlichtungsstelle, wenn sie sich zur Teilnahme an Streitbeilegungsverfahren vor einer Verbraucherschlichtungsstelle verpflichtet haben oder gesetzlich verpflichtet sind.

Für welche Händler gelten die Pflichten?

Grundsätzlich sind alle Händler, die Produkte oder Dienstleistungen auch an Verbraucher anbieten, dazu verpflichtet, die o.g. Informationspflichten zu erfüllen.

Für Unternehmen, die zum 31. Dezember des Vorjahres zehn oder weniger Beschäftigte hatten, gilt die Informationspflicht nach § 36 Abs. 1 Nr. 1 VSBG nicht. Kleine Unternehmen sollen dadurch privilegiert werden. Gezählt wird allerdings pro Kopf, Teilzeitkräfte werden also auch als Beschäftigte berücksichtigt.

Achtung: Unternehmen mit 10 oder weniger Beschäftigten zum 31. Dezember des Vorjahres sind nur von der Informationspflicht aus § 36 Abs. 1 Nr. 1 VSBG befreit. Die Informationspflichten aus § 37 VSBG, die nach Entstehung einer Streitigkeit zu erfüllen sind, gelten für alle Unternehmer, also auch für kleine Betriebe.

Entgegen einer Entscheidung des LG Dresden gelten diese Pflichten auch für Händler, die ihre Angebote auf Amazon oder Ebay oder anderen Plattformen anbieten. Auch dort muss der Hinweis auf die OS-Plattform sowie die weiteren Informationen nach dem VSBG erfüllt werden.

Wo und wie muss informiert werden?

Nach dem Gesetzeswortlaut in § 36 Abs. 1 VSBG müssen die Informationen leicht zugänglich, klar und verständlich sein.

Gemäß § 36 Abs. 2 VSBG müssen Händler, soweit sie eine Webseite unterhalten, auf ihrer Webseite die Informationen zur Verfügung stellen und soweit sie AGB verwenden, die Informationen in ebendiesen angeben.

Es bietet sich daher an, diese Informationen sowohl im Impressum des Online-Shops als auch in den AGB bereitzuhalten.

Das OLG München (Urt. v. 22.9.2016, 29 U 2498/16) hat klargestellt, dass der Link auf die OS-Plattform nicht nur sichtbar, sondern auch klickbar sein muss, um den wettbewerbsrechtlichen Vorschriften zu entsprechen.

Entwicklung seit dem 9. Januar 2016

Seit dem 9. Januar 2016 gilt bereits die ODR-Verordnung. Seit diesem Tag sind Händler, die Waren oder Dienstleistungen an Verbraucher anbieten, verpflichtet, in ihrem Online-Shop folgenden Link auf die OS-Plattform leicht zugänglich bereitzustellen:

http://ec.europa.eu/consumers/odr

Diese Pflicht gilt zwar seit dem 9. Januar 2016, die OS-Plattform ging aber erst am 15. Februar 2016 online. Gleichwohl wurden Händler, die den Link in dieser Zeit nicht bereithielten, abgemahnt und teilweise zur Unterlassung verurteilt.

Am 1. April 2016 trat das Verbraucherstreitbeilegungsgesetz in Kraft und die oben erwähnte zuständige Schlichtungsstelle für Deutschland wurde zugelassen. Dadurch konnte die OS-Plattform in Deutschland erstmalig genutzt werden und gemäß Artikel 14 Abs. 2 der ODR-Verordnung mussten bestimmte Händler zusätzlich einen Hinweis auf die Existenz der OS-Plattform und die Möglichkeit ihr Nutzung zur Streitbeilegung geben. Dies gilt jedoch nur insoweit, als der Händler sich verpflichtet hat oder verpflichtet ist, eine Streitbeilegungsstelle zu nutzen (z.B. für Energieversorger). Für die allermeisten Händler änderte sich zu diesem Zeitpunkt jedoch nichts.

Die Pflicht aus der ODR-Verordnung gilt auch noch weiterhin, also zusätzlich zu den Pflichten aus dem Verbraucherstreitbeilegungsgesetz.

Wie hoch sind die Kosten des Verfahrens?

Die Allgemeine Verbraucherschlichtungsstelle erhebt von den an einem Verfahren beteiligten Händlern ein Entgelt in Abhängigkeit von der Höhe des Streitwertes. Diese Kosten entstehen, sobald sich der Händler dazu bereit erklärt hat, an dem Streitbeilegungsverfahren teilzunehmen. Die Kosten staffeln sich wie folgt:

  • 50 Euro bei Streitwerten bis einschließlich 100 Euro
  • 75 Euro bei Streitwerten von 100,01 Euro bis einschließlich 200 Euro
  • 150 Euro bei Streitwerten von 200,01 Euro bis einschließlich 500 Euro
  • 300 Euro bei Streitwerten 500,01 Euro bis einschließlich 2.000 Euro
  • 380 Euro bei Streitwerten von 2000,01 Euro bis einschließlich 5.000 Euro
  • 600 Euro bei Streitwerten von über 5.000 Euro

Diese Kosten sind allerdings nicht zwingend, sondern die Verbraucherschlichtungsstelle verfügt bei der Erhebung über einen gewissen Spielraum. Wenn nach dem Vortrag des Händlers über die Sachlage die Schlichtungsstelle die Durchführung eines Verfahrens ablehnt, kann sie auch von der Erhebung von Kosten absehen. Für den Verbraucher ist das Verfahren grundsätzlich kostenlos. Beantragt er das Verfahren jedoch missbräuchlich, so kann ihm eine Missbrauchsgebühr in Höhe von 30 Euro auferlegt werden.

Des Weiteren werden die Verfahrenskosten gesenkt, wenn der Händler den Anspruch des Verbrauchers sofort vollständig anerkennt. Unter diesen Umständen werden Entgelte nur noch wie folgt erhoben:

  • 40 Euro bei Streitwerten bis 100 Euro
  • 50 Euro bei Streitwerten von 100,01 Euro bis 200 Euro
  • 75 Euro bei Streitwerten über 200 Euro

Die kostenlosen Rechtstexte von Trusted Shops berücksichtigen die neuen Pflichten jetzt schon.

http://shop.trustedshops.com/de/rechtstexte/

7. E-Commerce Geschäftsklimaindex: Händlerstimmung kühlt leicht ab

Nach den hohen Werten des 6. plentymarkets E-Commerce Geschäftsklimaindexes kühlt sich die Händlerstimmung zum Jahresanfang wieder ab. Mit 71,84 Punkten liegt der 7. Index jedoch weiterhin deutlich im positiven Bereich zwischen 50 und 100 Punkten (*). Einen ähnlichen Rückgang zeigte auch der 3. Index aus dem Frühjahr 2016. Es lässt sich hier also ein saisonal bedingter Rückgang vermuten.

Die Ergebnisse des 7. Geschäftsklimaindex auf einen Blick (© 2017 plentymarkets GmbH)

Diese Abschwächung der Stimmung geht dabei vor allem auf eine schlechtere Bewertung der nächsten 6 Monate zurück. Dies lässt sich darauf zurückführen, dass beim 6. Index vom Herbst das Weihnachtsgeschäft die Einschätzung der Händler für die nächsten 6 Monate stark beeinflusste. Dieser positive Effekt fällt nun weg und die Stimmung ist daher entsprechend niedriger. Die Einschätzung der aktuellen Lage ging hingegen nur leicht zurück.

Insgesamt liegt der Index zum Start 2017 minimal unter den 72,03 Punkten vom Januar 2016. Es lässt sich also weiterhin sagen, dass die Händler dem Jahr 2017 optimistisch entgegen blicken.

Die überwiegende Mehrheit der Teilnehmer (64,46%) beschäftigt auch im 7. Index 1 bis 10 Mitarbeiter. Am stärksten waren unter den Umfrageteilnehmern wieder die Branchen Kleidung/Schuhe/Accessoires (17,54%), Heim- und Haushaltswaren (10,88%) sowie Heimwerken/Werkzeuge/Gartengeräte (9,82%) vertreten.

Einen ausführlichen Bericht zu den Ergebnissen finden Sie unter:

https://www.plentymarkets.eu/news/whitepaper/

plentymarkets bedankt sich herzlich bei allen, die an der Befragung teilgenommen haben. Gemeinsam mit shopanbieter.de wird der plentymarkets E-Commerce Geschäftsklimaindex alle drei Monate erhoben, um damit ein verlässliches Stimmungsbarometer zur künftigen Marktentwicklung im E-Commerce zu etablieren. Der 7. plentymarkets E-Commerce Geschäftsklimaindex wurde zudem von Newsletter2Go gesponsert.

So funktioniert der plentymarkets Geschäftsklimaindex

Der plentymarkets E-Commerce Geschäftsklimaindex entspricht üblichen Berechnungen zur Konjunkturerwartung: Die Teilnehmer bewerten ihre aktuelle Situation und ihre Geschäftslage in den nächsten sechs Monaten mit „gut“, „befriedigend“ oder „schlecht“. Der Index wird anschließend aus den jeweiligen Salden der „guten“ und „schlechten“ Angaben errechnet und anschließend auf einen Bereich von 0 – 100 normiert. Dabei gilt: Werte von 0 bis 50 zeigen an, dass mehr Händler die Lage negativ einschätzen als positiv. Im Bereich 50 – 100 dementsprechend umgekehrt: mehr Händler sehen die Lage positiv als negativ. Der Wert 50 zeigt an, dass zwischen den beiden Positionen ein absolutes Gleichgewicht herrscht.

Kundenbewertungen: So werden Shops wirklich bewertet

Manche Händler scheuen sich aus Angst vor negativen Meinungen Bewertungen zu sammeln. Doch eine aktuelle Auswertung von Trusted Shops belegt, dass die überwiegende Mehrheit der Kunden stets die Bestnote vergibt. Die Zahlen geben Aufschluss darüber, wann bewertet wird und wie einzelne Branchen abschneiden. Simon Richartz, Bewertungsexperte bei Trusted Shops, zeigt, warum es sich lohnt, Kunden um ihre Meinung zu bitten. Denn 81 Prozent aller Kunden vergeben fünf von fünf Sternen, 13 Prozent immerhin vier Sterne. Als Schulnoten entspricht dies „sehr gut“ und „gut“.

trusted-shops-shopbewertungen

Es ist menschlich, dass einem als Händler eine negative Bewertung eher in Erinnerung bleibt als viele positive. Die Zahlen sprechen jedoch eine eindeutige Sprache: Negative Bewertungen sind sehr selten. So vergeben lediglich ein Prozent aller Kunden einen Stern, ein weiteres Prozent bewertet mit zwei Sternen. „Kritische Rezensionen schaden einem Online-Shop nicht, denn ausschließlich positive Bewertungsprofile werden von den Verbrauchern unter Umständen als unglaubwürdig wahrgenommen“, erklärt Simon Richartz.

Montagmorgen ist Bewertungszeit

Die Online Shops erhalten die meisten Beurteilungen um 10 Uhr am Montagmorgen, hingegen in der Nacht gehen die wenigsten Bewertungen ein. Das Wochenende ist tendenziell schwächer als die Werktage und insbesondere der Samstag ist eher bewertungsschwach.

16,7 Tage bis zur Bewertung

Im Schnitt liegen 16,7 Tage zwischen der Bestellung und der Abgabe einer Bewertung. „Der Grund dafür liegt an den unterschiedlichen Lieferzeiten. Ein Buch braucht nicht so lange wie ein individuell gezimmertes Möbelstück aus Italien“, so Richartz. Idealerweise sollte eine Bewertungsemail den Kunden einen bis drei Tage nachdem er die Ware erhalten hat erreichen.

Genussmittel bringen positive Rezensionen

Je nachdem, was verkauft wird, steigen oder sinken die Chancen auf positive Kundenbewertungen. Am besten bewertet ist die Branche „Genussmittel“ mit durchschnittlich 4,86 von 5 Sternen, dicht gefolgt von „Medikamenten“. Am wenigsten positiv schneiden im Vergleich die Branchen „Floristik“ mit 4,59 und „Bekleidung“ mit 4,54 von 5 Sternen ab.

Die Unterschiede erklären sich mit der Erwartungshaltung der Käufer. Wer sich beispielsweise eine Schachtel Pralinen oder ein bestimmtes Medikament bestellt, weiß in der Regel schon vor dem Kauf, was genau er oder sie benötigt. Entsprechend groß ist dann die Zufriedenheit mit der Ware. Blumen hingegen können beim Versand schnell Schaden nehmen und Kleidung muss anprobiert werden. So kommen kritische Bewertungen zustande.

Mobiles Shoppen bleibt der Hit

Der Trend zum mobile shopping ist ungebrochen. Dies spiegelt sich auch in der Bewertungsabgabe. So bewerten nur noch 68 Prozent aller Kunden am Desktop, 16 Prozent hingegen am Tablet und 18 Prozent am Smartphone.

Fazit: Bewertungen sammeln lohnt sich

Es ist sinnvoll Bewertungen zu sammeln, denn die meisten fallen positiv aus und vereinzelte kritische Stimmen verleihen dem Profil ein authentisches Erscheinungsbild. Wichtig ist, den optimalen Zeitpunkt in Bezug auf die eigene Kundschaft für eine Bewertungsemail herauszufinden. Außerdem sollte ein Online-Shop responsive sein, um auch auf mobilen Geräten zum Kauf einzuladen.

Wie ist die Händlerstimmung zum Jahresbeginn?

plentymarkets startet die Umfrage zum 7. E-Commerce Geschäftsklimaindex mit Verlosung

plenty-news

Mit dem 7. plentymarkets E-Commerce Geschäftsklimaindex führt plentymarkets in Kooperation mit Newsletter2Go und shopanbieter.de die Analyse zur Selbsteinschätzung kleiner und mittelgroßer Unternehmen weiter: Wie lief das Weihnachtsgeschäft 2016 und wie ist die Händlerstimmung zum Start des Jahres 2017?

Machen Sie mit und helfen Sie bei dieser Analyse:

https://de.research.net/r/7-plentymarkets-E-Commerce-Geschaeftsklimaindex

Im 6. plentymarkets E-Commerce Geschäftsklimaindex hatte sich die Stimmung gegenüber dem Sommer wieder deutlich verbessert, und auch im Vergleich zum Herbst 2015 konnte die Stimmung leicht zulegen. Die Händler empfanden dabei sowohl ihre aktuelle Situation als besser und schätzten auch die nächsten 6 Monate mit Blick auf das Weihnachtsgeschäft optimistischer ein. Es stellt sich nun also die spannende Frage: wie lief das Weihnachtsgeschäft und kann sich die gute Stimmung im neuen Jahr halten?

Als Dank verlosen plentymarkets und Newsletter2Go unter allen Teilnehmern der Befragung zum 7. plentymarkets E-Commerce Geschäftsklimaindex zwei Gewinne: ein iPad Mini (289,- €) und eine Newsletter2Go Premium-Newsletter-Vorlage mit 1-Klick- Produktübernahme (649,- €) im Wert von insgesamt 938,- €. Die Aktion endet am 13.01.2016.

Die Ergebnisse der vorangegangenen Indizes können Sie hier nachlesen:

https://www.plentymarkets.eu/news/whitepaper/

Der plentymarkets E-Commerce Geschäftsklimaindex wird alle drei Monate erhoben. Die Befragung ist einfach gehalten und thematisiert kurz und knapp die zukunftige Geschäftsentwicklung.

Continuous Delivery mit Docker, Gitlab CI und Ansible

Im letzten Jahr haben wir bei shoptimax den Entwicklungs- und Deployment-Workflow stark optimiert, um Projekte möglichst effektiv umsetzen, automatisiert testen und Fehler vermeiden zu können, die z.B. bei manuellen Uploads oder Änderungen direkt auf dem Server auftreten können. Mit einem passenden Continuous Delivery Workflow kann man erreichen, dass Änderungen zeitnah und zuverlässig ausgespielt werden können und dass auf einem Server immer ein genau definierter Zustand herrscht. Nicht zuletzt werden dadurch auch die Entwickler entlastet, da sie sich nicht mehr um das Hochladen von Änderungen, Abgleichen unterschiedlicher Datei-Versionen usw. kümmern müssen und sie durch automatisierte Tests und Validierungen frühzeitig Feedback bekommen, sollte es Probleme im Zusammenspiel der Software geben.

Alle neuen Projekte werden seit einigen Monaten bereits mit automatisiertem Deployment und nach dem Grundsatz „Continuous Delivery“ umgesetzt, ältere bzw. größere laufende Projekte stellen wir nach und nach um.

Entwicklungs-Workflow

Grundsätzlich gilt: jeder Entwickler sollte primär in seiner lokalen Umgebung entwickeln können, wozu Docker eingesetzt wird. Der Entwickler arbeitet, testet und debugged lokal auf seinem eigenen Rechner, „committed“ und „pusht“ seine Arbeit anschliessend in unsere GIT-Versionsverwaltung, für welche wir einen internen Gitlab-Server nutzen. Im Docker-Container der Entwickler sind zudem Tools wie Blackfire.io oder XHProf sowie Xdebug verfübar.

Sobald mit GIT in den sogenannten „develop“-Branch gepusht wird, übernimmt unser Gitlab-Server das automatische Deployment auf ein internes Test-System, auf welchem dann Projektleiter oder andere Beteiligte (Grafiker usw.) den aktuellen Stand begutachten können.

Pusht ein Entwickler in den sog. „stage“-Branch, wird der Stand, nach optionalem Durchlaufen von Tests usw., auf einen externen Entwicklungsserver gespielt, z.B. auf einen Kunden-Staging-Server.

Ein Release-Manager kann schliesslich noch in den sog. „master“-Branch pushen, dieser wird dann automatisch auf den Live-Server ausgerollt, allerdings wird hier ein Feature von Gitlab CI genutzt, welches es ermöglicht, neue Deployments über die Gitlab-Oberfläche manuell per Button zu „aktivieren“ – dazu reicht ein simples

when:
– manual

in der Datei „.gitlab-ci.yml“.

So kann der genaue Zeitpunkt bestimmt werden, wann der neue Stand online geht und es können vorher z.B. noch Kontrollen durchgeführt werden. Der vorherige Stand wird auf dem Server belassen, so ist ein blitzschnelles „Rollback“ über die Gitlab-Oberfläche oder die Shell möglich, sollte es doch einmal Probleme mit der neuen Version geben.

Build und Testing

In allen drei Fällen (develop, stage und master Branch) können optional vorab in einem automatisch von Gitlab gestarteten Docker-Container z.B. Akzeptanz-Tests usw. mit Codeception durchgeführt oder Coding-Standards mittels PHP Codesniffer und ähnlicher Tools geprüft werden etc.
Ausserdem können mit einem auf „ioly“ bzw. „OXID Modulconnector“ basierenden Installer im Shop benötigte Module aus anderen GIT-Repositories oder auch von Drittanbietern automatisch installiert und aktiviert werden.
Schlägt einer der automatisierten Tests fehl, wird das Deployment gestoppt. Sind die Tests erfolgreich, wird der komplette, getestete Shop im Docker-Container als *.tar.gz gepackt.

Ausrollen mit Ansible

Im nächsten Step wird innerhalb des Docker-Containers unser Ansible-Deployment Repository aus GIT geclont.

Ansible ist eine Server-Orchestrierungs/Konfigurations-Software, womit man von einem mit Ansible ausgestatteten Rechner beliebig viele „entfernte“ Rechner/Server administrieren kann. Dazu ist auf den Remote-Rechnern keinerlei Client- oder Server-Komponente nötig, es muss lediglich ein Public Key hinterlegt werden. Die Ansible Befehle definiert man in sog. „Playbooks“, die einfach im YAML-Format geschrieben werden können.

Unser Ansible-Playbook kann nun den kompletten Shop auf beliebige Server hochladen/verteilen und diverse zusätzliche Tasks ausführen, z.B. Symlinks anlegen (die in einer JSON-Datei definiert werden können) sowie Shell- oder PHP-Befehle ausführen (ebenfalls in JSON beliebig definierbar, z.B. Tmp-Verzeichnis leeren, Datenbank-Views neu erzeugen, Module aktivieren usw.).
Abschliessend kann von Ansible automatisch oder auch manuell per Button der Symlink auf das Haupt-Shopverzeichnis geändert und so der neue Stand live geschaltet werden. Wie schon erwähnt ist auch ein schnelles Rollback kein Problem, da der vorherige Stand (sowie einige ältere Stände) noch auf dem Server vorgehalten werden.

In weiteren Blog-Beiträgen werden wir sowohl Gitlabl CI näher vorstellen als auch einige Ansible-Features näher beleuchten. Teil 2 zum Thema „Ansible“ jetzt hier lesen!

shoptimax wünscht frohe Weihnachten und einen guten Rutsch

Auch in diesem Jahr gestaltete sich die Vorweihnachtszeit bei shoptimax äußerst ereignisreich. Zunächst stand auf der Tagesordnung, ein passendes und einfallsreiches Weihnachtspräsent für unsere Kunden, Partner und Lieferanten zu finden. Christian Trunk, hauseigener Grafiker bei shoptimax, hatte schließlich die zündende Idee: eine unserer Spezialitäten sind doch Schnittstellen!  Noch etwas quer gedacht und schon lag das Ergebnis auf dem Tisch – eine Schnittstelle zum Anfassen, in Form wunderschön natürlicher Holzschneidebrettchen mit Brandaufdruck. Ein herzlicher Dank gilt an dieser Stelle der Firma Holz Frank aus Hersbruck, die diese Idee in Rekordzeit für shoptimax umsetzte.

smx-schnittstelle smx-weihnachtsbaum

Mit Lebkuchen, Stollen und Lebkuchenkonfekt bestückt, eingepackt in Geschenkfolie  und gut gepolsterte Kartons, sollten sich alsbald gut 50 Päckchen auf den Weg zu ihren Empfänger machen. Pünktlich zur Fertigstellung der eigenen Geschenkidee, trafen auch schon die ersten Geschenkpäckchen bei shoptimax ein und konnten ihren Platz unter dem Weihnachtsbaum einnehmen. Dort warten sie auch in diesem Jahr auf ihre Rolle in der alljährlichen shoptimax-Tombola. Eine große Überraschung gab es übrigens von unserem Partner Plentymarkets: ein echter Weihnachtsbaum! Das Team bedankt sich bei herzlich bei allen, die an uns gedacht und so reichlich beschenkt haben!

Die Weihnachtstombola ist vorbereitet.

Die Weihnachtstombola ist vorbereitet.

Nächster Halt: Weihnachtskarten

Die Geschenkidee war also gefunden, der Baum pünktlich aufgestellt. Nahezu zeitgleich dazu machten sich Grafik und PR gemeinsam daran, die diesjährigen Weihnachtsgrüße zu gestalten. Und auch hier stand Individualität an erster Stelle. Ein kleines Rätsel auf der Vorderseite der weihnachtlichen Grüße soll an den – doch manchmal auch hektischen – Feiertagen ein wenig für Entspannung sorgen.

Das Weihnachtskartenmotiv der shoptimax GmbH im Jahr 2016.

Das Weihnachtskartenmotiv der shoptimax GmbH im Jahr 2016.

Nun konnten sich die Teammitglieder mit ihrer Unterschrift auf den über 250 Karten den Wünschen zum Weihnachtsfest und zum Jahresausklang anschließen. Bis wenige Momente vor der Weihnachtsfeier Mitte Dezember herrschte in der Weihnachtspoststelle der shoptimax GmbH so noch reges Treiben.

Zeit für Besinnlichkeit

Am Abend des 15. Dezember waren schließlich alle Päckchen und Weihnachtskarten auf ihrem Weg und es konnte der gemütlich Teil der Vorweihnachtszeit eingeläutet werden: die shoptimax-Weihnachtsfeier. Diese stand ebenfalls ganz im Zeichen der vorausgegangenen Individualität bei Geschenken und Weihnachtsgrüßen. Da das stark wachsende Team nicht nur fachlich breit aufgestellt ist, sondern zudem aus verschiedenen Ländern rund um den Globus stammt – nicht zuletzt von Russland bis China – keimte die Idee auf, auch internationale Spezialitäten auf den Tisch zu bringen. Das Team kochte und backte bis die Ofen glühten und so fanden allerlei Köstlichkeiten an diesem Abend ihren Weg zu shoptimax. Im Herzen des Großraumbüros versammelte sich das Team schließlich an weihnachtlich gestalteten Tafeln und genoss die mitgebrachten Speisen bis spät in den Abend.

smx-weihnachtsfeier-2016

In diesem Sinne wünscht shoptimax allen Kunden, Partnern, Lieferanten und Freunden ein erholsames Weihnachtsfest und einen schönen Jahresausklang. Wir freuen uns darauf, auch im nächsten Jahr die immer neuen Rätsel des E-Commerce zu lösen.