Surface 5: Independent Booking Form (Satzart)
Goal Conflict: Medium to High | Synergy: Low
| Dimension | Assessment |
|---|---|
| Goal Conflict | Medium to High |
| Synergy | Low (currently) |
| Busflow Touchpoint | Booking Widget (Commerce context), Public API |
| Risk | Direct overlap with Busflow's core conversion engine |
Analysis
Satzart currently provides a well-functioning, independent booking form (Buchungsmaske) specifically designed for Kuschick. This form is already live for their customers and is intended to remain in use in the future.
The Open Question: How does this work with Busflow?
Short-Term Approach
- If the operator migrates to Busflow, the existing Satzart booking form must be able to push bookings into Busflow instead of Kuschick.
- Busflow's API-first architecture explicitly supports this: The Satzart form can act as a custom headless frontend, submitting reservation data to Busflow's booking endpoints via API.
- This ensures the partner's goal (providing a well-functioning booking mask) is met without disrupting the operator's transition.
Long-Term Convergence
- Busflow provides a highly optimized, embeddable booking widget out of the box. Maintaining a custom, independent booking form creates ongoing maintenance overhead for the partner.
- The partner can continue offering their custom form as a premium, highly tailored solution using the Busflow API, while Busflow's native widget serves as the standard, zero-maintenance alternative.
Verdict: Coexist via API integration. Allow the partner to keep their independent booking form live by routing the Kuschick payload to Busflow's API. Do not force them to replace it, but position the native Busflow widget as the default path forward for new operators.
Partner Motivation & Timeline Misalignment
Recent conversations reveal that the partner is not in a rush to replace or migrate the Kuschick integration. Their timeline for a "Kuschick Booking" transition is tentatively set for late 2026.
- The true motive: The partner likely wants to secure near-term "freelancing" (custom agency) work by building custom Kuschick integrations first, treating a Busflow integration as a secondary "step two" phase.
- The feature misconception: The partner justifies this delay by citing specific operator requirements (e.g., "operators need to block seats or mark them as reserved") and assumes Busflow "doesn't want to know about that" or cannot handle this complexity.
- Strategic Response: Do not fight their timeline or their desire for freelance revenue. Instead, proactively demonstrate that Busflow natively handles complex dispatch requirements (like seat blocking, capacity management, and reservations) out of the box, making their custom freelance work unnecessary for the operator, while still allowing the partner to charge for the website/frontend integration.