über das Projekt
Das Produkt des Kunden ist SaaS im B2B-Bereich, das im Abonnementgebührenformat arbeitet. Der Benutzer registriert sich, übergibt die Autorisierung, füllt sein Konto auf und nutzt den Dienst.
Unsere Aufgabe ist es, dem Kunden zu helfen, Analysen zu "sammeln". Zu diesem Zweck mussten Call-Center-Prozesse erstellt, CRM implementiert und End-to-End-Analysen anhand von Schlüsselindikatoren „zusammengeführt“ werden.
Prozessstruktur
Bevor Sie Analysen durchführen, müssen Sie eine Landschaft für die Erfassung vorbereiten: Strukturieren Sie Verkaufsprozesse und richten Sie Integrationen mit Services ein. Wir haben verschiedene Probleme in den Prozessen gefunden:
- Die Manager wurden durch unnötige Phasen des Verkaufstrichters abgelenkt, und ihre Arbeit wurde in keiner Weise überwacht.
- Verkaufsberichte wurden jeden Tag manuell vom Admin-Panel heruntergeladen.
- Es gab nur wenige Conversion-Ereignisse zum Sammeln von Analysen.
Als nächstes haben wir eine Karte mit der Struktur der Interaktion aller Systeme erstellt.
Es zeigt, welcher Logik die Ereignisse folgen sollten und in welchen Phasen der Analyst vorgeht. Wir nehmen die Hauptdaten aus CRM und korrelieren sie mit Daten zu Werbung und Conversions. Zusammenstellen in myBI, Rendern in Power BI.
Verkaufstrichter
Kundenverkäufe wurden in Enybox CRM durchgeführt und zur einfacheren Integration an amoCRM übertragen. Wir haben es geschafft, die Verkaufslogik in drei Trichter zu sammeln.
Drei aufeinanderfolgende Trichter
Der erste Trichter ist die Beratung. Ich musste den Kunden dazu bringen, sich auf der Plattform zu registrieren. Der zweite Trichter fixiert die ersten Zahlungen. Dann bestätigte der Benutzer seine Registrierung. Und wir haben wiederum den Moment der Zahlung und jede neue Auffüllung gefeiert.
Wie Analytics funktionieren sollte
| Erste "Ereignisse" | Letzte "Ereignisse" |
|---|---|
| Feedback-Formular | Feedback-Formular |
| Registrierung im Dienst | Registrierung im Dienst |
| Erste Einzahlung | |
| Testen (optional mit einer kleinen Nachfüllung) | |
| Wiederholte Aufladungen | |
| Verweigerung der Verwendung (Aufwärmen durch das OP) |
Damit das Analysesystem normal funktioniert, müssen Sie alle Ereignisse erfassen = Konvertierungsaktionen markieren. Ereignisse sind bereits in das Analysesystem eingegangen, aber anfangs gab es nur zwei Arten von Ereignissen, was für Berichte nicht ausreicht.
Daten anzeigen
Beispiel-Dashboard
Nach dem Sammeln von Daten zu Conversions musste ein Bericht daraus erstellt werden. Das Hauptwerkzeug zur Datenvisualisierung ist Microsoft Power BI.
Zum Zeitpunkt der Konvertierung wurde auf der Website eine separate ID generiert, um Werbesysteme und CRM zu synchronisieren. Mit dieser ID haben wir die Daten von Ausgaben und Einnahmen verknüpft. Also haben wir die Daten korreliert und konnten Berichte darüber erstellen.
Einheitsökonomie. Aufbewahrung
Das fortlaufende Aufbewahrungsdiagramm des Dienstes von 1 bis 12 Monaten Aufbewahrung
zeigt, wie viele Benutzer an der Anwendung beteiligt sind und wie oft sie zu ihr zurückkehren. Aufgrund der Tatsache, dass der Service in Form von Nachschub funktioniert, musste ich diesen Indikator in fortlaufende Aufbewahrung ändern. Es zeigt dasselbe wie Aufbewahrung, impliziert jedoch, dass der Benutzer den Dienst die ganze Zeit, in der er das Konto nicht aufgefüllt hat, auch verwendet hat.
Umstellung auf die erste Einzahlung
Die Umstellung war stark abhängig von der Anzahl der Neukunden und dem Beginn ihrer Zahlungen. In den ersten 9 Monaten haben wir jeden Monat etwa 430 neue Registrierungen und 90 Zahlungen von neuen Benutzern erhalten. Die Umstellung auf Kauf im Monat der Registrierung betrug nach Angaben für 12 Monate 20%.
Neben Standardindikatoren
Es war möglich, Analysen auf Knopfdruck des Kunden sowohl zum Zeitpunkt eines einfachen Übergangs zur Website als auch zum Zeitpunkt der Registrierung und weiterer Zahlungen zu sehen. Wir haben Daten gesammelt, um die meisten Conversion-Ketten zu finden: Der
Benutzer sah die Anzeige → ging auf die Website → nach einer Weile kam und suchte im Kontext → registriert, aber nicht bezahlt → mit einem Brief aufgewärmt → bot eine Probefahrt an → getestet → das OP „gab die erste Zahlung“ → 3 Jahre stabile Zahlungen.
Etwas ist schief gelaufen
Ganz am Anfang haben die Initiatoren des Projekts den Start auf den Herbst verschoben (sie haben sich im Frühjahr beworben). Solche "Lücken" in der Arbeit traten mehr als einmal auf. Aber wir haben nicht darüber nachgedacht und es für selbstverständlich gehalten. Die Hauptprobleme waren Kommunikation und Bürokratie in den Prozessen unserer Kunden. So können Sie den gesamten Arbeitszeitraum eines Projekts darstellen:
Langsame Entwicklung
Die Entwicklungslücken waren auf die Struktur der Arbeit des Kunden zurückzuführen. Wir haben mit dem Team des Kunden zusammengearbeitet und einige der Aufgaben konnten aufgrund der hohen Sicherheit der Prozesse nur auf seiner Seite ausgeführt werden.
Verpasste zwei Sprints - verlor einen Monat
Alle Manager und Entwickler auf ihrer Seite arbeiteten in zweiwöchigen Iterationen. Aber sie haben unser Projekt immer an letzter Stelle gesetzt und oft fielen unsere Aufgaben nicht in den "Sprint".
Schlechte Kommunikation und mangelndes Fachwissen
Während des Projekts hat sich der Manager (Stakeholder) des Kunden fünf Mal geändert. Wahrscheinlich weiß jeder, dass das Gefühl, wenn das Projekt, an dem Sie arbeiten, plötzlich für den Kunden nicht mehr interessant ist. Aber auch das kann gelöst werden.
Es war schwieriger, mit der Inkompetenz der Stakeholder umzugehen. Einer von ihnen war ein großartiger Manager, der sein Produkt gut kannte. Aber er verstand nicht einmal die Grundprinzipien des Aufbaus von Verkaufsprozessen. Wir haben mehrere Besprechungen verbracht, um ihn davon zu überzeugen, die Bühne mit dem Status "Wie geht es Ihnen?" Aus dem Verkaufstrichter zu entfernen.
Stellen Sie sich einen Verkaufstrichter wie das Bild oben vor. In einer der Phasen müssen Manager herausfinden, "wie es dem Kunden geht". Was wird Ihrer Meinung nach mit der Conversion-Analyse dieses Trichters passieren?
Manager werden vom Kunden herausfinden, wie es Ihnen geht, anstatt ihn durch den Trichter zu bewegen. Der Status ist nicht trivial. Es ist nicht klar, wann man es ausdrückt: nach dem ersten Kontakt oder nach der Qualifikation. Infolgedessen "springen" Deals entlang des Trichters hin und her oder stehen einfach statt sequentieller Bewegung.
Während des Verkaufsprozesses ist es unmöglich, Zwischenstufen festzulegen, in denen sich Geschäfte ansammeln. Andernfalls werden alle Analysen zu einem Chaos, und Manager verlieren viele Kontakte.
Fakapas von unserer Seite
Die Systembandbreite haben wir nicht berücksichtigt. Für ein Plattformereignis zu Spitzenzeiten haben wir bis zu 10 Anfragen an amoCRM gesendet, um die Logik von Geschäftsprozessen auszuführen.
100.000 Ereignisse pro Tag * 10 Anfragen an amoCRM = 1.000.000 Anfragen pro Tag
1.000.000 Anfragen pro Tag / 10 Anfragen pro Sekunde (AMO-Limit) = 100.000 Sekunden = ± 27 Stunden
Ergebnis: Die Synchronisation wird niemals enden
. als "Pass" die Grenze der Anforderungen an das System. Aber im Laufe der Entwicklung des Projekts haben sich die Anforderungen und Funktionen erhöht und wir sind an die Grenzen gestoßen.
Wir haben das falsche Werkzeug gewählt. AmoCRM ist physisch nicht für die Bearbeitung einer großen Anzahl von Anforderungen geeignet.Der Fehler war auch, dass wir alles auf GO entwickelt haben und ein Spezialist dafür verantwortlich war. Als er ging, gab es einen Berg von Legacy-Code, den niemand verstehen konnte. Leider oder zum Glück war dies nicht notwendig.
Alles ist wieder kaputt
Dieser Fall ist ein weiteres Beispiel für ein Projekt, das in Genehmigungen und einem Haufen unnötiger Verwaltung begraben wurde.
Uns fehlte technisches Fachwissen. Für den Kunden - Stabilität im Management und Wunsch, das Projekt zum Abschluss zu bringen.
Aber das ist Erfahrung. Dank ihm sehen solche Aufgaben jetzt so trivial wie möglich aus, und wir haben bereits in einem anderen Projekt eine ähnliche Lösung reproduziert.
Wie ein Fehler hätte vermieden werden können
Um solche Fälle in Zukunft nicht zu wiederholen, haben wir die Aspekte hervorgehoben, die bei der Arbeit mit Unternehmenskunden zu beachten sind.
- : ; . , .
- . — . — . . .
- . KPI — .
- Denken Sie voraus. Selbst bei der Entwicklung eines MVP müssen Sie die Engpässe berücksichtigen, die in Zukunft auftreten können. Das Projekt wird ständig erweitert und es ist wichtig, eine Struktur bereitzustellen, um nicht den gesamten Code von Grund auf neu zu schreiben.
Der Autor des Artikels ist Fyodor Anisimov, LAND PRO-Vermarkter.