Kuschick Adapter Offer Notes
Internal notes only: This is not an offer text. Use these points as raw material when drafting the actual Satzart offer.
Recommended Framing
- Position as Kuschick Booking API Foundation.
- Sell a focused first phase, not a fully productized Busflow adapter.
- Bill roughly 2.5 weeks.
- Internally build with Busflow reuse in mind, but do not promise Busflow product capabilities to Satzart.
- Emphasize price/value: Satzart receives a usable Kuschick booking-flow foundation without carrying the full cost of a long-term integration product.
Core Value for Satzart
- A documented API layer in front of Kuschick for the booking form.
- Less direct Kuschick complexity in the xtoura/Satzart frontend.
- Faster form startup through cached/preloaded starting data.
- Cleaner error handling than calling Kuschick directly from their implementation.
- OpenAPI/Swagger documentation for their developers.
- Foundation can later be extended if the first operator/use case proves value.
Scope to Include
- Kuschick API/protocol verification for the agreed first use case.
- Operator-specific Kuschick credentials/configuration.
- API key access for the Satzart/xtoura integration.
- Kuschick booking-flow endpoints:
- form initialization / starting data;
- availability-related data where needed;
- address field requirements;
- payment options;
- CRM options if needed by the form;
- seat request/selection support as far as needed for the first form;
quote/validate;confirmwrite to Kuschick.
- Basic cache/preload behavior for form starting data.
- Basic polling model for background refresh if cache is stale.
- Structured provider errors and correlation IDs.
- Swagger/OpenAPI documentation.
- No durable PII storage where avoidable.
Scope to Exclude / Keep Separate
- No Busflow migration/staging pipeline.
- No direct writes into Busflow domain tables.
- No two-way sync.
- No Buchungs-/Abrechnungs-Sync between Kuschick and Busflow.
- No admin/debug UI for Satzart.
- No full support cockpit.
- No OAuth/JWT partner ecosystem.
- No SSE/WebSocket live updates in phase 1.
- No on-the-fly Busflow price calculation.
- No guarantee that every Kuschick edge case or every Satz-Typ is covered.
- No general xtoura travel-content API.
- No customer account, catalog request or voucher flows unless explicitly added later.
Important Caveats to Mention Carefully
- Kuschick behavior must be verified against a real or testable endpoint.
- The provided PDF indicates XML-over-HTTP, not guaranteed SOAP/WSDL.
- Final booking submission depends on Kuschick availability and response behavior.
- If Kuschick accepts a request but times out or responds ambiguously, the outcome may require manual clarification.
- For Satzart MVP, if Kuschick is offline during final booking, the wrapper should return an error rather than silently queueing a booking.
- Advanced offline booking acceptance is a Busflow product capability, not part of this phase.
Commercial Logic
- Price-sensitive customer: keep offer small and concrete.
- Avoid a large "enterprise integration" proposal that raises expectations.
- The paid phase funds the research and foundation that Busflow can reuse.
- Better to overdeliver internally on architecture than overpromise externally in the offer.
- Follow-up phases can be sold once the first integration proves value.
Possible Follow-Up Phases
- Hardening after real operator testing.
- Additional Kuschick Satz-Typen.
- Better cache intelligence and refresh rules.
- More complete seat-plan handling.
- Provider outcome reconciliation.
- Busflow migration/staging integration.
- Busflow-owned offline booking queue.
- Integrator/debug cockpit.
- Broader adapter productization for other legacy systems.
Suggested Offer Language Direction
- Use wording like "foundation", "first integration phase", "for agreed first booking-flow use case".
- Avoid wording like "complete Kuschick integration", "full migration", "two-way sync", "all edge cases", "replacement of Kuschick".
- Make extension points visible without making them part of the fixed scope.