Software fürs Autohaus

// Das Problem

Die Serviceabteilungen einer Händlergruppe schreiben Befunde auf Papier, und Kunden lehnen empfohlene Arbeiten ab, die sie nicht sehen können, während Berater Freigaben am Telefon nachjagen.

// Was wir bauen würden

Eine Technikerapp für Mehrpunktbefundungen mit Fotos und kurzen Videos, ein Link für die Kundin, um Arbeiten zu sehen, freizugeben und online zu bezahlen, und eine Beratertafel mit dem Status jedes Auftrags, angebunden an das Dealer-Management-System.

// Was drin ist

// Tech-Stack

• React Native
• Next.js
• PostgreSQL
• Anbindung an CDK oder Reynolds DMS
• Stripe
• AWS

// Das Problem

Ein stark ausgelastetes Autohaus verpasst Anrufe zu Terminen, Auftragsstatus und Rückrufen, und jeder verpasste Anruf ist eine Kundin, die vielleicht woanders bucht.

// Was wir bauen würden

Ein Agent, der Chat, SMS und über einen Sprachdienst auch Anrufe annimmt: er legt Termine im Planer an, gibt den Auftragsstatus aus dem DMS und prüft offene Rückrufe über die FIN, und alles Übrige geht an einen Berater. Er läuft auf einem Spitzenmodell über dessen API, das Gespräche gut beherrscht und am schnellsten startet; gesendet wird nur, was eine Antwort braucht.

// Was drin ist

// Tech-Stack

• API eines Spitzenmodells
• Twilio Voice Gateway
• Python
• Next.js
• APIs von DMS und Planer
• DigitalOcean

// Das Problem

Ein Netz aus Händlern, freien Werkstätten und einer Fahrzeugauktion hält jeweils einen Teil der Historie eines Fahrzeugs, und Streit über Kilometerstände und nicht angegebene Reparaturen landet auf irgendeinem Schreibtisch.

// Was wir bauen würden

Ein privates Register mit Zugangsberechtigung, in dem Händler, Werkstätten und die Auktion Kilometerstände, Services und Reparaturen zur FIN erfassen, sobald sie anfallen, sodass die Historie eines Fahrzeugs ein Satz Einträge ist, den kein Mitglied still ändern kann. Ein kommerzieller Historienbericht deckt Ihren Bedarf vielleicht schon, und eine gemeinsame Datenbank genügt, wenn alle einem Mitglied vertrauen; wir sagen Ihnen, was zutrifft.

// Was drin ist

// Tech-Stack

• Hyperledger Fabric (privat, mit Zugangsberechtigung)
• Node.js
• Next.js
• PostgreSQL
• AWS

// Das Problem

Ein regionales Ladenetz steuert seine Stationen über ein Anbieterportal, das Fahrer nie sehen, also können sie nicht erkennen, welche Säulen frei sind, und die Zahlung scheitert im schlechtesten Moment.

// Was wir bauen würden

Eine Fahrer-App für iOS und Android, um einen Ladevorgang zu finden, zu starten und zu bezahlen, mit aktuellem Säulenstatus, und ein Backoffice im Web, das über OCPP mit den Stationen spricht, für Status, Preise, Fernstarts und Störungsmeldungen.

// Was drin ist

// Tech-Stack

• React Native
• Next.js
• OCPP 1.6 und 2.0.1
• OCPI
• PostgreSQL
• Stripe

// Das Problem

Eine Autohausgruppe tippt Werkstattaufträge, Teilebestellungen und Garantieanträge zwischen ihrem Dealer-Management-System, ihren Teilelieferanten und dem Garantieportal des Herstellers neu ab.

// Was wir bauen würden

Eine Integrationsdrehscheibe, die Werkstattaufträge, Teilebestellungen und Garantieanträge zwischen Ihrem Dealer-Management-System und den Systemen ringsum bewegt, jeden Datensatz vor dem Versand prüft und Ihrem Serviceteam zeigt, was durchging und was ein Mensch ansehen muss.

// Was drin ist

// Tech-Stack

• Node.js
• PostgreSQL
• REST
• OpenAPI
• DigitalOcean

// Das Problem

Die Online-Terminbuchung eines Autohauses braucht auf dem Handy ein Dutzend Bildschirme, und viele Kunden geben auf und rufen an.

// Was wir bauen würden

Eine Neugestaltung der Buchung für Web und Mobil, mit echten Kunden getestet: Fahrzeug, Arbeiten und Termin mit wenigen Tippern wählen, den Kostenvoranschlag sehen und Erinnerungen und Statusmeldungen erhalten, solange das Auto in der Werkstatt ist.

// Was drin ist

// Tech-Stack

• Figma
• Next.js
• React Native
• PostgreSQL
• DigitalOcean