maesn
Nach Rolle

Vier Teams, eine Integration, vier verschiedene Fragen daran

Die Entwicklung fragt, ob sich das ohne einen Client je System ausliefern lässt. Der Vertrieb fragt, ob die Antwort auf „unterstützt ihr unseres“ Ja lautet. Der Support fragt, welche Anfrage für welchen Kunden fehlgeschlagen ist. Die Finanzabteilung fragt, was die Bücher sagen. Darunter liegt bei allen vieren dieselbe Verbindung.

Diese Software-Teams vertrauen uns
HubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicapHubSpotTipaltiPaywiseRallyQredNordhealthFindityFintoClockinHEROHolviLanes & PlanesAgicap
Nach Rolle

Beginnen Sie bei dem Team, dessen Woche sich dadurch ändert

Vier Seiten, eine je Rolle, und jede zeigt auf die Funktionen und Abläufe, denen diese Rolle wirklich begegnet.

Was jedes Team fragt

Eine Verbindung darunter, vier verschiedene Fragen daran

Das TeamWas es von der Anbindung verlangtWas es beantwortet
Produkt & EntwicklungKönnen wir das ausliefern, ohne einen Client je System zu schreiben?Common Data Model
Go-to-MarketLautet die Antwort Ja, wenn ein Interessent sein System nennt?Die angebundenen Systeme
Customer SuccessWelche Anfrage ist für welchen Kunden wann fehlgeschlagen?Unified Logging & Monitoring
FinanzteamsWas sagen die Bücher, ohne auf einen Export zu warten?Der MCP-Server
Eine Funktion je Zeile, nicht die ganze Liste. Jede Team-Seite trägt den Rest dessen, dem sie begegnet, und die Frage in der mittleren Spalte ist die, die dieses Team zuerst stellt, nicht die einzige, die es hat.

Die Fragen lassen sich nicht ineinander übersetzen, und deshalb kann eine Seite nicht alle vier beantworten. Was sich zwischen ihnen nicht ändert, ist die Verbindung: der Kunde meldet sich einmal an, und dasselbe Objektmodell bedient die Entwicklung, die dagegen baut, die Antwort, die der Vertrieb im Gespräch gibt, und die Anfrage, die der Support danach nachschlägt.

Wie diese Seiten zusammenpassen

Eine Team-Seite ist der Leser, ein Use Case ist der Ablauf

Auf dieser Seite kreuzen sich drei Achsen, und jede beantwortet eine andere Frage. Ein Use Case ist ein Ablauf von Anfang bis Ende, derselbe, wen auch immer er interessiert. Eine Branchenseite ist das Unternehmen, das Sie sind. Eine Team-Seite ist die Aufgabe, die Sie darin erledigen, und sie reicht die Mechanik an die anderen beiden weiter, statt sie zu wiederholen.

Deshalb braucht derselbe Leser oft zwei davon: eine Plattform für das Bauhandwerk und eine für Kreditorenbuchhaltung stehen in verschiedenen Branchen, und ihre Entwickler stellen genau dieselbe Frage danach, wie viele Clients sie schreiben müssen. Gemeinsam ist ihnen das Team, nicht der Markt.

FAQ nach Rolle

Häufige Fragen

Warum sind diese Seiten nach Team geschnitten und nicht nach Funktion?

Weil dieselbe Anbindung aus vier verschiedenen Gründen gekauft wird, und die Gründe lassen sich nicht ineinander übersetzen. Die Entwicklung will wissen, was nicht zweimal gebaut wird, der Vertrieb will wissen, ob ein genanntes System unterstützt ist, der Support will wissen, welche Anfrage für einen Kunden fehlgeschlagen ist, und die Finanzabteilung will eine Zahl, ohne auf einen Export zu warten. Die Feature-Seiten beantworten, was eine Sache ist. Diese vier beantworten, was sie Ihnen wert ist.

Worin unterscheidet sich eine Team-Seite von einer Use-Case-Seite?

Eine Use-Case-Seite erklärt einen Ablauf von Anfang bis Ende, vom Lesen bis zum Schreiben, und es ist derselbe Ablauf, wen im Unternehmen er auch interessiert. Eine Team-Seite geht vom Leser aus und zeigt auf die Abläufe und Funktionen, denen dieser Leser begegnet. Die Mechanik steht auf den Use-Case-Seiten und wird weitergereicht statt wiederholt.

Und worin unterscheidet sie sich von einer Branchenseite?

Eine Branchenseite spricht das Unternehmen an, das Sie sind, eine Team-Seite die Aufgabe, die Sie darin erledigen. Eine SaaS für das Bauhandwerk und eine Plattform für Kreditorenbuchhaltung sind verschiedene Branchen, deren Entwickler dieselbe Frage nach Clients je System stellen. Deshalb gibt es beide Achsen, und keine ersetzt die andere.

Sind alle vier Seiten veröffentlicht?

Noch nicht, und die Liste verschweigt das nicht. Alle vier sind hier verlinkt, in der Navigation und im Fuß, weil eine geplante Seite trotzdem die kanonische Adresse ist. Einen Link bis zum Start zu verstecken heißt, ihn später nachzutragen, und genau so gehen Links verloren.

Welches Team sollte welche Seite zuerst lesen?

Wer gerade prüft. In der Praxis trägt die Entwicklungsseite die technischen Einzelheiten zu Datenmodell, Anmeldung und Sandboxes, und deshalb beginnt eine Prüfung meist dort, auch wenn das Budget woanders liegt.

Einmal bauen, auf der Unified API.

Sehen Sie, wie eine Integration für jedes Team für Ihre Integration funktioniert, oder steigen Sie in die technische Referenz ein.