Software für Telekom

// Das Problem

Ein regionaler Internetanbieter plant Installationen und Reparaturen per Telefon, und Techniker melden per SMS zurück, also weiß das Büro nie, wo ein Auftrag steht oder welches Modem in welches Haus ging.

// Was wir bauen würden

Eine Disponiertafel fürs Büro und eine App für iOS und Android für Techniker, angebunden an die Abrechnungs- und Provisionierungssysteme, sodass ein Auftrag ohne Anruf vergeben, erledigt und freigeschaltet wird.

// Was drin ist

// Tech-Stack

• Next.js
• React Native
• PostgreSQL mit PostGIS
• Schnittstellen zu Abrechnung und Provisionierung
• AWS

// Das Problem

Das Serviceteam eines Netzbetreibers beantwortet den ganzen Tag dieselben Fragen zu Rechnungen, Störungen und Umzügen, und Kunden warten, während die schwierigen Fälle in derselben Warteschlange liegen.

// Was wir bauen würden

Ein Service-Agent im Website-Chat und in der App, der aus den eigenen Hilfeinhalten des Netzbetreibers antwortet, Störungen prüft und eine Rechnung erklärt, nachdem sich der Kunde angemeldet hat, und mit angehängtem Gespräch an einen Menschen übergibt. Er nutzt ein Spitzenmodell über dessen API: der schnellste Anfang für ein Produkt mit hohem Aufkommen, bei dem die Inhalte öffentlich sind und Kontoabfragen über Werkzeuge laufen, die Sie kontrollieren.

// Was drin ist

// Tech-Stack

• API eines Spitzenmodells
• Next.js
• PostgreSQL mit pgvector
• Schnittstellen zu CRM und Abrechnung
• AWS

// Das Problem

Eine einzelne Störung erzeugt Hunderte Alarme im ganzen Netz, und das Betriebszentrum verbringt die erste Stunde damit, die Ursache von Hand zu finden.

// Was wir bauen würden

Ein eigenes Modell, auf der eigenen Alarmhistorie und den Störungstickets des Netzbetreibers trainiert, das zusammengehörige Alarme bündelt, die wahrscheinliche Ursache und die betroffenen Kunden vorschlägt und dem Betriebsteam zeigt, warum, betrieben im eigenen Cloud-Konto des Netzbetreibers.

// Was drin ist

// Tech-Stack

• PyTorch
• Kafka
• Python
• Next.js
• AWS

// Das Problem

Mehrere regionale Netzbetreiber tauschen Großhandels- und Roamingnutzung als Monatsdateien, und jeden Monat weichen ihre Summen ab, und der Streit wird per E-Mail beigelegt.

// Was wir bauen würden

Ein privates Register mit Zugangsberechtigung, von dem die Netzbetreiber je einen Knoten betreiben, in dem Nutzungsdaten und vereinbarte Tarife beim Austausch erfasst werden, mit einem Portal, das jedem Netzbetreiber dieselben Summen zeigt und Differenzen markiert, solange sie noch klein sind.

// Was drin ist

// Tech-Stack

• Next.js
• PostgreSQL
• Hyperledger Besu (privat, mit Zugangsberechtigung)
• S3-kompatibler Speicher
• AWS

// Das Problem

Ein regionaler Internetanbieter nimmt Aufträge im Abrechnungssystem an, schickt sie per E-Mail zur Bereitstellung an das Netzteam und aktualisiert den Kundendatensatz von Hand, wenn der Dienst läuft.

// Was wir bauen würden

Eine Integration, die neue Aufträge von der Abrechnung an die Bereitstellung übergibt, jeden Schritt bis zur Inbetriebnahme verfolgt, die Abrechnung am richtigen Tag startet und dem Kundenservice den Stand jedes Auftrags zeigt, mit den TM Forum Open APIs, wo Ihre Systeme sie unterstützen.

// Was drin ist

// Tech-Stack

• Node.js
• PostgreSQL
• TM Forum Open APIs
• OpenAPI
• DigitalOcean

// Das Problem

Das Kundenportal eines kleinen Anbieters basiert auf einem Framework, das nicht mehr gepflegt wird; Zahlungen schlagen ab und zu fehl, niemand traut sich an ein Update, und Kunden rufen lieber an.

// Was wir bauen würden

Eine Rettung, die das Portal am Laufen hält, während es ersetzt wird: zuerst ein schriftliches Gutachten, die Zahlungsfehler sofort behoben, dann ein Neubau Maske für Maske auf gepflegter Technik mit Tests, wobei die Kundenkonten unverändert übernommen werden.

// Was drin ist

// Tech-Stack

• Next.js
• PostgreSQL
• TypeScript
• Playwright
• DigitalOcean