Dieses Dokument ist passwortgeschützt. · This document is password-protected.
Erweiterung der bestehenden Aeschbach-Treuekarte für Apple Wallet & Google Wallet — ohne Kassenintegration.
Die Aeschbach Chocolatier AG betreibt heute ein bewährtes physisches Treueprogramm: Kundinnen und Kunden laden Guthaben auf ihre Karte, sammeln bei Einkäufen Punkte und erhalten bei 1'000 Punkten eine Gutschrift von CHF 30.–. Die Karte existiert bisher ausschliesslich in physischer Form.
Ziel dieses Projekts ist es, diese Treuekarte um eine digitale Variante für Apple Wallet (iPhone) und Google Wallet (Android) zu erweitern. Kundinnen und Kunden sollen ihre Karte selbstständig per Link oder QR-Code aufs Smartphone laden – mit stets aktuellem Guthaben, Punktestand und Platz für Aktionen und Mitteilungen.
Zentrale Rahmenbedingung: Eine Anbindung an die Kasse ist nicht möglich. Die Lösung muss daher vollständig ohne Kassenintegration funktionieren. Diese Vorgabe prägt die empfohlene technische Lösung massgeblich (siehe Kapitel 02).
Physische Karte bleibt erhalten: Die bestehende Plastikkarte funktioniert unverändert weiter. Die digitale Karte ist eine zusätzliche, gleichwertige Option – kein Ersatz und kein Zwang für die Kundschaft.
Weil keine Kassenintegration möglich ist, können Guthaben und Punkte nicht automatisch aus dem Verkaufsvorgang übernommen werden. Unsere Empfehlung ist deshalb eine eigenständige Wallet-Plattform mit einem einfachen Mitarbeiter-Portal – komplett unabhängig vom Kassensystem und dadurch sofort umsetzbar.
Der Kern der Empfehlung: Statt auf eine (nicht mögliche) Kassenanbindung zu warten, verwalten Sie Guthaben und Punkte über ein schlankes Web-Portal – bedienbar auf Tablet, Smartphone oder PC an der Theke. Jede Änderung wird in Sekunden auf die digitale Karte der Kundin gepusht.
Ehrliche Einordnung zum Aufwand an der Theke: Ohne Kassenanbindung muss die Erfassung von Punkten/Guthaben manuell erfolgen. Das ist bei Aeschbach heute bereits der Fall. Sobald das Kassensystem künftig eine Schnittstelle bietet, lässt sich dieser Schritt automatisieren (siehe Kapitel «Zukünftige Erweiterungen»).
Die erste Version (V1) bildet das gesamte heutige Treueprogramm digital ab und ist auf beiden Plattformen produktiv einsetzbar.
Native digitale Kundenkarte für iPhone und Android, im Aeschbach-Look gestaltet.
Kunden laden ihre Karte selbstständig aufs Smartphone – ohne App-Installation.
Anzeige von Kundennummer, aktuellem Guthaben und Punktestand direkt auf dem Pass.
Abbildung der bestehenden Regel: 1'000 Punkte ergeben CHF 30.– Gutschrift.
Neues Guthaben oder ein neuer Punktestand erscheint automatisch auf der Karte.
Feld für Mitteilungen und Aktionen – direkt auf der Rückseite des Passes.
Karte suchen/scannen, Guthaben und Punkte anpassen – einfach und schnell.
Geschützter Login fürs Portal; Kundendaten auf Servern in der Schweiz/EU.
Kein App-Store nötig: Wallet-Pässe sind Teil von iOS und Android. Es gibt keine App-Installation, keine App-Store-Freigaben und keine App-Updates – das senkt Aufwand und Hürde für die Kundschaft erheblich.
Die Umsetzung erfolgt in fünf Phasen. Nach heutigem Kenntnisstand rechnen wir mit einer Gesamtdauer von rund 7–9 Wochen ab Projektstart, abhängig von Feedback-Zyklen und der Bereitstellung von Inhalten (Logo, Kartendesign, Kundendaten).
| Phase | Inhalt | Dauer |
|---|---|---|
| 1. Setup | Apple Developer Program, Google Wallet, Zertifikate, Projektinfrastruktur | ~1 Woche |
| 2. Wallet-Backend | Pass-Generierung Apple & Google, Push-Updates, Datenmodell | ~2.5 Wochen |
| 3. Portal & Onboarding | Mitarbeiter-Portal und Kunden-Onboarding-Seite (Link/QR) | ~2.5 Wochen |
| 4. Design & Test | Kartendesign im Aeschbach-Look, Tests auf realen iOS- und Android-Geräten | ~1 Woche |
| 5. Go-Live | Deployment, Übergabe, kurze Einführung fürs Team | ~0.5 Woche |
Frühzeitig starten: Die Freischaltung des Apple Developer Program und die Einrichtung der Google-Wallet-Herausgeberberechtigung können ein paar Tage in Anspruch nehmen. Wir stossen diese Schritte direkt zu Projektbeginn an, damit sie den Zeitplan nicht verzögern.
Die folgenden Positionen beschreiben den Leistungsumfang der V1. Auf konkrete Preisangaben verzichten wir in dieser Fassung bewusst – siehe Hinweis unten.
| Position – Leistungsumfang V1 |
|---|
| Setup & Konfiguration (Apple, Google, Zertifikate) |
| Wallet-Pass-Backend (Apple & Google, Push) |
| Datenanbindung bzw. Datenmodell (je nach Szenario) |
| Kunden-Onboarding (Link/QR, Kartenbezug) |
| Mitarbeiter-Portal (Guthaben/Punkte, Push) |
| Design & Branding (Aeschbach-Look) |
| Tests auf realen Geräten (iOS & Android) |
| Deployment & Projektleitung |
Hinweis zur Preisgestaltung: Eine seriöse Kalkulation der einmaligen Entwicklungskosten ist erst möglich, wenn die drei offenen Fragen in Kapitel 08 beantwortet sind – insbesondere, ob Ihr bestehendes Kartensystem direkt angebunden werden kann oder eine eigenständige Datenhaltung nötig ist. Der Aufwand unterscheidet sich je nach Szenario erheblich. Sobald alle Informationen vorliegen, erhalten Sie eine aktualisierte Offerte mit verbindlichen Preisen (Fixpreis, exkl. MwSt.).
Neben der einmaligen Entwicklung fallen laufende Kosten für Plattform-Lizenzen, Hosting und Wartung an. Diese halten wir bewusst schlank.
| Position | Anbieter / Details | Kosten |
|---|---|---|
| Apple Developer Program | Pflicht für Apple Wallet | ~CHF 90.–/Jahr |
| Google Wallet API | Herausgeberkonto | kostenlos |
| Push-Benachrichtigungen | Apple APNs / Google – im Konto enthalten | kostenlos |
| Hosting (Backend, DB, Pass-Auslieferung) | Server Schweiz/EU | abhängig vom Szenario |
Für Betrieb, Updates (z. B. bei neuen iOS-/Android-Versionen) und Support bieten wir drei Modelle an – frei wählbar:
| Modell | Leistung |
|---|---|
| Nach Aufwand | Support und Anpassungen auf Abruf, stundenweise verrechnet |
| Wartung Basis | Monitoring, Sicherheits- & Kompatibilitäts-Updates, E-Mail-Support |
| Wartung Plus | Basis + priorisierter Support + kleines Stundenkontingent/Monat |
Hinweis: Hosting- und Wartungspreise beziffern wir in der finalen Offerte, sobald das technische Szenario feststeht (siehe Kapitel 08). Die externen Lizenzkosten (Apple/Google) bleiben in jedem Fall minimal, die laufenden Fixkosten halten wir bewusst schlank.
Die V1 ist so aufgebaut, dass sie sich später gezielt ausbauen lässt. Mögliche Erweiterungen – jederzeit einzeln beauftragbar:
| Erweiterung |
|---|
| Automatischer Punkte-/Guthaben-Import (falls Kasse künftig Schnittstelle bietet) |
| Marketing-Push-Kampagnen (gezielte Aktionen an alle Karteninhaber) |
| Standort-Benachrichtigung (Karte erscheint am Sperrbildschirm beim Laden) |
| Kunden-Self-Service-Portal (Transaktionen & Guthaben einsehen) |
| Online-Registrierung neuer Kunden (digitale Ablösung des Papierformulars) |
| Statistik-Dashboard (Nutzung, aktive Karten, Punkte-Auswertung) |
Drei Fragen, die vor der finalen Offerte zu beantworten sind:
1. Kartensystem: In welchem System werden Guthaben und Punktestände heute verwaltet, und bietet dieses System eine Schnittstelle (API) oder eine Export-Möglichkeit? Falls ja, bleibt Ihr bestehendes System die führende Datenquelle («Source of Truth») und wir binden es lediglich an – ohne doppelte Datenhaltung. Hilfreich ist zudem die Anzahl aktiver Kundenkarten.
2. Kassen-Scanner: Wird die Kundenkarte heute an der Kasse gescannt, und mit welcher Scanner-Hardware? Für das Lesen von Codes ab Smartphone-Display wird ein 2D-Imager benötigt (klassische 1D-Laserscanner können dies nicht zuverlässig).
3. Code-Format: Welcher Code-Typ ist auf der Karte aufgedruckt (z. B. EAN-13, Code 128, QR) und wie sind die Kartennummern aufgebaut? Apple Wallet unterstützt kein EAN-13 – in diesem Fall würde die Kartennummer auf dem digitalen Pass als QR-Code hinterlegt, sofern der Kassen-Scanner QR lesen kann.
Sobald diese drei Punkte geklärt sind, passen wir die Offerte an das zutreffende Szenario an und unterbreiten Ihnen eine aktualisierte, verbindliche Fassung.
Gerne besprechen wir die offenen Punkte und passen die Offerte auf Ihre Bedürfnisse an. Wir freuen uns auf die Zusammenarbeit mit der Aeschbach Chocolatier AG.
Extending the existing Aeschbach loyalty card to Apple Wallet & Google Wallet — no POS integration required.
Aeschbach Chocolatier AG runs a well-established physical loyalty programme: customers top up credit on their card, collect points with every purchase and receive a credit of CHF 30.– at 1,000 points. To date, the card exists in physical form only.
The goal of this project is to extend the loyalty card with a digital version for Apple Wallet (iPhone) and Google Wallet (Android). Customers add the card to their smartphone themselves via a link or QR code – always showing the current credit balance, points total and space for promotions and messages.
Key constraint: A connection to the point of sale is not possible. The solution must therefore work entirely without POS integration. This requirement significantly shapes the recommended technical solution (see chapter 02).
The physical card stays: The existing plastic card continues to work unchanged. The digital card is an additional, equivalent option – not a replacement and never an obligation for customers.
Because no POS integration is possible, credit and points cannot be captured automatically from the sales transaction. Our recommendation is therefore a standalone wallet platform with a simple staff portal – fully independent of the POS system and thus ready to implement right away.
The core of the recommendation: Instead of waiting for a (currently impossible) POS connection, you manage credit and points through a lean web portal – usable on a tablet, smartphone or PC at the counter. Every change is pushed to the customer's digital card within seconds.
An honest note on counter workload: Without a POS connection, points and credit must be recorded manually. This is already the case at Aeschbach today. As soon as the POS system offers an interface in the future, this step can be automated (see chapter «Future extensions»).
The first version (V1) fully covers today's loyalty programme in digital form and is production-ready on both platforms.
Native digital loyalty card for iPhone and Android, designed in the Aeschbach look.
Customers add their card to their smartphone themselves – no app installation.
Customer number, current credit balance and points total shown directly on the pass.
Carries over the existing rule: 1,000 points earn a CHF 30.– credit.
A new credit balance or points total appears on the card automatically.
A field for messages and promotions – right on the back of the pass.
Look up/scan a card, adjust credit and points – simple and fast.
Protected login for the portal; customer data hosted on servers in Switzerland/EU.
No app store needed: Wallet passes are part of iOS and Android. There is no app installation, no app-store approval and no app updates – which significantly lowers both effort and the barrier for customers.
Implementation proceeds in five phases. Based on what we know today, we expect a total duration of around 7–9 weeks from project start, depending on feedback cycles and the provision of content (logo, card design, customer data).
| Phase | Scope | Duration |
|---|---|---|
| 1. Setup | Apple Developer Program, Google Wallet, certificates, project infrastructure | ~1 week |
| 2. Wallet backend | Pass generation for Apple & Google, push updates, data model | ~2.5 weeks |
| 3. Portal & onboarding | Staff portal and customer onboarding page (link/QR) | ~2.5 weeks |
| 4. Design & testing | Card design in the Aeschbach look, tests on real iOS and Android devices | ~1 week |
| 5. Go-live | Deployment, handover, short introduction for the team | ~0.5 week |
Start early: Activating the Apple Developer Program and setting up the Google Wallet issuer account can take a few days. We kick off these steps right at project start so they do not delay the schedule.
The following positions describe the scope of V1. We deliberately refrain from stating concrete prices in this version – see the note below.
| Position – V1 scope |
|---|
| Setup & configuration (Apple, Google, certificates) |
| Wallet pass backend (Apple & Google, push) |
| Data integration or data model (depending on scenario) |
| Customer onboarding (link/QR, card download) |
| Staff portal (credit/points, push) |
| Design & branding (Aeschbach look) |
| Tests on real devices (iOS & Android) |
| Deployment & project management |
Note on pricing: A reliable calculation of the one-time development costs is only possible once the three open questions in chapter 08 have been answered – in particular, whether your existing card system can be connected directly or whether standalone data management is required. The effort differs substantially between these scenarios. As soon as all information is available, you will receive an updated proposal with binding prices (fixed price, excl. VAT).
In addition to the one-time development, running costs apply for platform licences, hosting and maintenance. We deliberately keep these lean.
| Position | Provider / details | Cost |
|---|---|---|
| Apple Developer Program | Required for Apple Wallet | ~CHF 90.–/year |
| Google Wallet API | Issuer account | free |
| Push notifications | Apple APNs / Google – included in the accounts | free |
| Hosting (backend, DB, pass delivery) | Servers in Switzerland/EU | depends on scenario |
For operations, updates (e.g. for new iOS/Android versions) and support we offer three models – freely selectable:
| Model | Scope |
|---|---|
| Time & material | Support and changes on demand, billed by the hour |
| Maintenance Basic | Monitoring, security & compatibility updates, e-mail support |
| Maintenance Plus | Basic + prioritised support + a small monthly hour contingent |
Note: We will quote hosting and maintenance prices in the final proposal, once the technical scenario is settled (see chapter 08). The external licence costs (Apple/Google) remain minimal in any case, and we deliberately keep the running fixed costs lean.
V1 is built so that it can be extended step by step later on. Possible extensions – each can be commissioned individually at any time:
| Extension |
|---|
| Automatic points/credit import (if the POS offers an interface in the future) |
| Marketing push campaigns (targeted promotions to all cardholders) |
| Location notification (card appears on the lock screen near the store) |
| Customer self-service portal (view transactions & credit) |
| Online registration of new customers (digital replacement of the paper form) |
| Statistics dashboard (usage, active cards, points analysis) |
Three questions to be answered before the final proposal:
1. Card system: In which system are credit balances and points managed today, and does this system offer an interface (API) or an export option? If so, your existing system remains the leading data source («source of truth») and we simply connect to it – with no duplicate data management. The number of active loyalty cards would also be helpful.
2. POS scanner: Is the loyalty card scanned at the till today, and with which scanner hardware? Reading codes from a smartphone display requires a 2D imager (classic 1D laser scanners cannot do this reliably).
3. Code format: Which code type is printed on the card (e.g. EAN-13, Code 128, QR) and how are the card numbers structured? Apple Wallet does not support EAN-13 – in that case the card number would be shown as a QR code on the digital pass, provided the POS scanner can read QR.
As soon as these three points are clarified, we will adapt the proposal to the applicable scenario and provide you with an updated, binding version.
We are happy to discuss the open points and tailor the proposal to your needs. We look forward to working with Aeschbach Chocolatier AG.