Deal Playbook — xtoura × Busflow

Purpose: Single internal prep document for the partner conversation. Read this the night before. Covers meeting strategy, objection handling, negotiation tactics, and founder decisions — in the order you need them. Partner type: Potential strategic partner (not a cofounder). Currently focused on the xtoura PIM relaunch. Partner motivation: They want an improved Kuschick booking form for the relaunch. We will not provide this. Our goal: Decline the freelance ask elegantly, gather intelligence, plant seeds for future Busflow integration, and preserve the relationship.

---

1. Meeting Strategy

Your Posture: Listen, Decline Gracefully, Gather Intel

The partner will likely ask you to build or improve a Kuschick booking form. You will say no — but the way you say no determines whether this relationship has a future.

The frame: You are not rejecting them — you are being honest about your focus. Busflow consumes all your capacity. Building a one-off form would delay the very product that could serve them properly in the future.

Why this matters: If you decline coldly, the partner writes you off. If you decline warmly and ask intelligent questions about their needs, you leave the door open and gather exactly the operator pain-point data you need for Busflow's roadmap.

Primary Objective

Walk away with three things:

1. Intelligence — relaunch timeline, Kuschick pain points, operator requirements for booking forms, and which operators need booking capability most.
2. Relationship intact — the partner feels heard, respected, and clear on why you said no.
3. Busflow seed planted — the partner knows you are building exactly what they need, just not on their timeline. When Busflow ships, they should think of you first.

Three Things to Learn

Question	Why It Matters	How to Ask It
Which operators need the widget?	Identifies your first pilot candidates and tells you if the demand is real or theoretical.	"Which of your clients are asking for online booking? Do you have a specific operator in mind for this?"
How do operators feel about payment commissions?	Determines if per-transaction pricing is viable or an adoption trap.	"When your operators accept online payments — credit card, PayPal — how do they feel about the processing fees? Is that something they push back on?"
Does the partner plan to monetize the widget?	Reveals their business model and whether your commission stacks on top of theirs.	"When you offer the booking widget to your website clients — do you see that as included in your website service, or as a separate product with its own pricing?"

---

2. Scenario Scripts

Most Likely Scenario: "We want you to build an improved Kuschick booking form"

This is what you expect. They want a basic form for the relaunch. Your job: say no without closing the door.

Your response flow:

1. Acknowledge genuinely. "I understand — that makes total sense for the relaunch. You need booking capability and the current Kuschick form is not cutting it."
2. Ask about the pain. "Before I respond — walk me through what exactly is not working. What do operators complain about? What would the improved form need to do?"
3. Listen and take notes. Every pain point they describe is a Busflow requirement you validate for free. This is gold.
4. Decline with honesty and respect. "I have to be straight with you — I cannot take this on right now. All my development capacity goes into Busflow. Building a one-off form would delay the platform, and I do not think that serves either of us well."
5. Plant the seed. "The thing is — the booking engine I am building inside Busflow handles exactly what you are describing. It is not ready for your relaunch timeline, but when it ships, your operators and websites would be the natural first integration. I would love to revisit this when the timing aligns."
6. Close warm. "Let me know how the relaunch goes. If there is anything I can help think through architecturally — how the booking form should integrate, what data flows make sense — I am happy to be a sounding board."

If they push back or seem disappointed:

"I get it, and I am sorry I can not help right now. But I would rather be honest than take on something I can not deliver well. When Busflow's widget is ready, you will have a product that does more than a custom form ever could — and I want you to be the first partner to use it."

If They Open With: "We want to integrate a booking widget into our PIM / websites"

This is your best opening — they want to upsell their website clients. Stay in discovery mode:

Your response flow:

1. Explore the need. "That makes a lot of sense. Which clients are you thinking about first? Are these operators who currently have no online booking, or operators who have one but it's not working well?"
2. Let them describe the problem. Every detail they share about bad booking forms, missing functionality, or operator frustration is an argument for Busflow that they made, not you.
3. Introduce Busflow naturally. "You know that this is exactly what we are building with Busflow — an embeddable booking widget that handles the full checkout: availability, pricing, payment, confirmation, digital tickets. The widget sits on the website you build, and the operator gets a complete booking flow."
4. Propose the pilot. "How about this: pick one operator. I deploy the widget on their website. We test it for 30 days and see what happens. No cost, no commitment, just a real-world test."

If They Open With: "We would like to hire you to build the booking widget"

This is Scenario 2. Do not reject it immediately. Instead, redirect through questions:

Your response flow:

1. Acknowledge. "I understand the idea. You need a booking widget, and you know I can build one."
2. Ask a scoping question that reveals complexity. "Let me ask — when you say booking widget, what scope do you have in mind? Just the form and the submit button? Or also payment processing, availability checks, confirmation emails, PDF tickets?"
3. Wait for the answer. They will either describe a simple form (which is not what operators actually need) or a full checkout flow (which is too complex for a freelance project).
4. Bridge to Busflow. "Here is my honest assessment: a booking widget that actually works — with real payment processing, Klarna, Apple Pay, SEPA, real-time availability, and digital tickets — is not a 3-week freelance project. It is a product. And that product is what I am already building with Busflow. So the question is not whether I can build it from scratch for you. The question is whether it makes more sense to use what already exists in Busflow and save 6 months of development."
5. Reframe the value. "If I build it as a freelance project, you get a widget. If you use Busflow, you get a widget plus an operational backend that grows over time — passenger management, digital tickets, dispatch. And your operators get a platform, not a one-off."

If they push back on the redirect: "I get it, and I am not trying to sell you something. But I would not be honest with you if I said 'let me build a booking widget from scratch' when I already have one under development. That would be bad use of your money and my time. Let me show you what the widget does, and then you decide."

If They Open With: "Let us build something together / a joint product"

This is Scenario 3. Ride their framing, but fill it with Scenario 1 substance:

Your response flow:

1. Enthusiasm. "I love that idea. That is actually how I see this partnership working — you bring the websites, the PIM, the operator relationships. I bring the booking engine, the payments, the ticketing."
2. Define the division. "The cleanest way to do this is a clear split: your PIM and websites handle product presentation and content. Busflow handles the eCommerce layer — checkout, payment processing, order confirmation, digital tickets. Two systems, one seamless experience for the operator."
3. Name it. "We could frame this as your digital offering — 'xtoura Digital' or whatever you want to call it. Your websites plus Busflow's eCommerce engine. You sell the package, we deliver the commerce layer."
4. Set the architecture boundary (casually). "Technically, the integration is simple: your website embeds the widget via a script tag or URL. Your PIM feeds the product data. The systems talk via API, but they do not share a codebase. Clean boundaries, no merge conflicts. Your developer works on the PIM, I work on the widget, nobody blocks each other."

This is the "potential strategic partner" positioning — exactly the long-term vision for this relationship.

---

3. The Money Conversation

This is the hardest part of the meeting. Handle it in three phases.

Phase 1: Probe Their Model First

Ask before you present anything. Your goal is to understand how they think about money in this context.

Script:

"Before we talk about pricing — I am curious: when you build websites for operators today, and the operator gets bookings through the website, does the operator pay you anything per booking? Or is it a flat website fee?"

Why this works: It reveals whether the partner already takes a transaction-based cut. If yes, your commission model is familiar territory. If no, you know you are introducing a new concept.

Follow-up:

"And when the operators accept online payments — credit card, PayPal — how do they handle the processing fees? Is that something they accept, or is there pushback?"

Why this works: This is the commission acceptance probe. The answer tells you if operators view percentages as normal cost of doing business or as hostile.

Phase 2: Present Your Model

Only after you understand their expectations. Tailor the framing to what you heard.

If they already take a per-booking cut:

"Our model is similar to what you already do, actually. Busflow charges a small commission on each booking that goes through the widget. That commission covers the full eCommerce infrastructure — payment processing, fraud protection, digital tickets, the whole thing. We keep it simple: one rate, everything included."

If they do NOT take a per-booking cut (flat website fee model):

"For the booking widget, we use a commission model — Busflow takes a small percentage on each booking. The reason is fairness: operators who book more, pay more. Operators who book less, pay less. No upfront cost, no fixed fee. The widget pays for itself through the bookings it generates."

If operators resist commissions on principle:

"We hear that. Some operators are used to paying a flat annual license and keeping 100% of each transaction. Here is the difference: with a license model, you pay whether you book zero or ten thousand. With our model, the cost scales with success. An operator who books ten trips a month pays almost nothing. An operator who books a thousand trips is earning enough that the commission is a rounding error."

Phase 3: Handle the "What Does It Cost After R&D?" Question

This will come up. Your answer needs to be honest and structured.

Script:

"Right now, the widget is in active development — we are in the R&D phase, funded partly through the Forschungszulage. During this phase, there is no cost. The product is not commercially ready yet."

"When it ships — and the timeline aligns with your relaunch — the model works like this: a small commission per booking, which includes all payment processing. The exact rate is something we will define as we get closer to launch, but it will be competitive with what operators already pay for payment processing alone."

"And here is the important part: the transition from 'free during R&D' to 'commercial' is not a surprise. We plan it together. When the widget is ready and you are deploying it on operator websites, we define the rate together. You have input."

Why this works:

• It is honest about the product state (R&D, not ready yet).
• It avoids the trap of "free forever" expectations.
• It gives the partner agency ("we define it together").
• It defers the exact number without being evasive — you are not hiding the price, you are acknowledging it does not exist yet.

The Minimum Commission Floor

Your fear is valid: if the partner sets the total package price too low, your commission gets squeezed. Protect this by separating the widget pricing from the partner's website pricing.

Principle: The partner charges operators for websites. Busflow charges operators for the booking widget. These are two separate invoices — or at minimum, two separate line items. The partner does not set Busflow's price.

Script (if they suggest bundling):

"I think bundling makes sense from a marketing perspective — you offer the full package. But the widget pricing should stay separate, even if it appears as one package to the operator. You set the website price, we set the widget price. That way, you are not subsidizing our infrastructure and we are not squeezing your margins."

---

4. Developer Management

The internal developer will be in the room. Your strategy has three layers.

Layer 1: Make Him Feel Relieved, Not Threatened

Frame the widget as scope he does NOT have to build. Every feature you describe is work he does not need to do. Payment integration, PCI compliance, Apple Pay, Klarna, PDF generation, digital tickets — all of this stays off his plate.

Script (addressed to the room, not directly to him):

"The nice thing about using the Busflow widget is that the PIM relaunch stays clean. [Developer] focuses on the PIM and the content layer. The booking widget is a separate system that integrates via URL or iframe. No shared codebase, no additional scope on the relaunch."

Layer 2: Counter "I Can Build This"

If the developer claims he can build the widget within the PIM relaunch:

Do not challenge his ability. Challenge the scope.

"That is definitely an option. Can I ask — when you say you would build it, are you thinking a simple booking form, or the full checkout with payment processing? Because the payment side alone — PCI compliance, multi-PSP integration, Klarna, Apple Pay, 3D Secure, refund handling — that is probably 3–4 months of dedicated work. And I would hate to see that delay the PIM relaunch."

What this does: It forces the developer to either admit the scope is huge (which argues for Busflow) or claim it is easy (which undermines his credibility when the partner pushes on specifics). Either way, the relaunch delay risk argues against piling more scope onto his plate.

Layer 3: Counter "Let Us Build It Together"

If the developer proposes a joint codebase:

"I am fully on board with working together. The best way to do that, in my experience, is clean API boundaries. Your PIM sends product data to the widget via API. The widget handles the checkout and sends booking confirmations back. Two systems, one experience. We each own our own deployments and release cycles. That way, a change I make to the checkout does not break your PIM, and vice versa."

What this does: It agrees with the spirit ("work together") while rejecting the implementation ("shared codebase"). The developer gets collaboration without Busflow getting entangled in his code.

---

5. Objection Handling Matrix

#	Objection	Response
1	"We just want a simple booking form, not a platform."	"Totally fair. The widget works standalone — you embed it, it handles the checkout. The platform behind it is invisible to the operator. They see a booking form. We handle the complexity."
2	"Our freelancer can build a booking form."	"A form, yes. But payment processing, real-time availability, Klarna, Apple Pay, digital tickets, refund handling, SEPA direct debit — that is not a form, that is a product. And it is already being built."
3	"What if Busflow fails or you stop development?"	"The widget is an embed — if Busflow disappears, you remove the script tag and replace it with something else. You are not locked in architecturally. But to be transparent: Busflow is funded, actively developed, and this is my full-time focus."
4	"Why can't we just use Bookingkit / Regiondo / etc.?"	"You can. But those are generic booking tools for tourism activities. They do not understand bus tourism — group bookings, seat plans, pickup stops, ancillary services, multi-day itineraries. Busflow is built specifically for this industry."
5	"We don't want to depend on your system."	"You do not depend on it — you integrate with it. The widget is an embed on your website. If you ever want to switch, you replace the embed. There is no data lock-in, no contract lock-in, and your PIM stays completely independent."
6	"What about data privacy / GDPR?"	"Busflow processes booking data on behalf of the operator (data processor). We sign a standard DPA (Auftragsverarbeitungsvertrag). The operator remains the data controller. Your PIM and our widget exchange only product data (tour dates, prices) — no personal data flows between systems."
7	"The commission model is too expensive."	"Let us compare: the commission covers everything — payment processing, widget hosting, checkout UX, digital tickets, fraud protection. Without the widget, the operator pays nothing for online booking — but also gets no online bookings. The question is whether the incremental revenue exceeds the commission. On a €1,200 bus trip, a 4% commission is €48. If the widget generates even one extra booking per month that would not have happened otherwise, it pays for itself."
8	"Can we pay a flat fee instead of commission?"	"We can discuss that as a future option. For the launch phase, the commission model makes more sense because it is zero risk for the operator — they only pay when they earn. A flat fee means paying whether the widget books zero or a hundred trips."
9	"We need the widget for the relaunch deadline."	"When is the deadline? Let us work backwards from there. The widget does not need every feature on day one — we start with the core checkout (select trip, enter details, pay, confirm) and add features iteratively. If the timeline is tight, we prioritize."
10	"What if our developer needs to change something in the widget?"	"The widget is a Busflow product — we own and maintain it. Your developer does not need to touch it. If you need a customization (colors, layout, fields), we handle that through configuration, not code changes. Your developer stays focused on the PIM."
11	"We want the widget to be branded as xtoura, not Busflow."	"We support white-labeling. The widget carries the operator's branding — their colors, their logo. Whether it says 'Powered by Busflow' or not is a detail we can discuss. The operator experience is what matters."
12	"Busflow doesn't support complex operator needs like blocking seats or reservations."	"Actually, we absolutely do. Busflow is built precisely for bus operators — this means our native dispatch system handles seat plans, capacity blocking, and tentative reservations out of the box. You don't have to custom-build this complex logic as freelance work for every operator; Busflow provides it as a standard platform feature."
13	"This sounds great, but we need to think about it."	"Absolutely. How about this: I send you a one-page overview of the widget — what it does, how the integration works, and a proposed timeline. And let us pick one operator to test it with. A real pilot says more than another meeting."

---

6. Negotiation Tactics

Leverage Points (What We Hold)

Lever	Value	When to Play
App IP ownership (§ 69b UrhG)	The partner likely does not know we own the xtoura-app code. This is our strongest card.	Only if the partner becomes hostile or demands unreasonable concessions. Never open with this.
Commission generosity (80% over 5 years)	Extremely generous by industry standards. The partner will not find a better deal elsewhere.	Open with this. It demonstrates commitment and sets the tone.
Busflow's technical superiority	The xtoura-app surfaces data from legacy ERPs. Busflow owns the data natively and builds the operational layer these systems lack.	Use when the partner questions why operators need Busflow at all.
Willingness to walk away	Busflow's roadmap does not depend on this partnership. The partnership accelerates go-to-market, but is not a prerequisite.	Never state this explicitly. Let it show through calmness and fair dealing.

Concession Ladder (What We Can Give)

Give these in order — stop as soon as the partner is satisfied:

1. Commission structure (already decided — lead with this)
2. Extensive app maintenance rights to ex-employee (free)
3. First-mover framing ("You are our launch partner")
4. Co-branded marketing materials
5. 12-month right of first refusal for operators in their network
6. App IP transfer (only as part of a signed partnership agreement with real commitments)

Red Lines (What We Never Give)

• ❌ Geographic or segment exclusivity
• ❌ Busflow feature restrictions ("don't build a passenger portal")
• ❌ Dedicated xtoura PIM connector as a contractual obligation
• ❌ Revenue share on Busflow's own direct-sales operators
• ❌ App IP transfer without quid pro quo

Conversation Sequencing

1. Open with the Website synergy. This is the easiest win — zero conflict, immediate value. "We make your websites sell."
2. Introduce the commission structure. 80% over 5 years. Let the partner do the math on their operator base. This should generate enthusiasm.
3. Address the PIM lightly. "Your PIM feeds the marketing content; Busflow handles the transactions. Two systems, two truths, both win."
4. The app conversation — defer if possible. If the partner raises it, acknowledge the overlap honestly: "You're right, there's overlap. That's why we want to make your app better by integrating Busflow data into it." Point to the Integration Strategy in 4-surface-app.md.
5. The IP card — hold in reserve. Only play this if the partner becomes adversarial or demands unreasonable terms. Frame as: "We believe in this product enough that we're willing to give it a dedicated team. Let's structure this properly."

---

7. Risk Matrix

Risk	Probability	Impact	Mitigation
Partner perceives Busflow as competition	High (short-term)	High	Lead with Website synergy (undeniable win-win). Defer app conversation.
"Difficult IT guy" blocks PIM integration	Medium	Low	Email-as-API bypasses IT entirely. Busflow does not depend on integration.
Partner demands Busflow integrate with xtoura-app	Medium	Medium	Refuse politely: "We integrate at the data layer (API), not at the UI layer."
Ex-employee handoff fails	Medium	Medium	Structure handoff with maintenance SLA and clear timeline. Document everything.
Partner tries to negotiate exclusivity	Low	High	Non-negotiable: Busflow serves all operators. Partner gets preferred pricing, not exclusivity.
Partner walks away entirely	Low	Medium	Acceptable outcome per stated preference: "I would rather not partner than compromise."

---

8. Founder Decisions (Resolved)

1. Revenue Share Model — Commission on Yearly Revenue

Decision: No per-transaction revenue share via Mollie. Instead, the partner earns up to 80% of yearly revenue over 5 years as commission for operators they bring in.

Strategic implication: This is a relationship-level commission, not a widget-level cut. It means:

• The partner earns regardless of how the booking happens (widget, portal, phone) — this removes any incentive for the partner to block Busflow's direct channels
• The 5-year term creates long-term alignment without perpetual obligations
• The "up to 80%" language leaves room for tiered rates (e.g., 80% year 1, decreasing to 40% by year 5) — negotiate the gradient

Talking point for the partner: "You earn a commission on every operator you bring, for five years. Whether the booking comes through your website, the app, or Busflow's own portal — you get paid. That's better than a per-click widget deal."

2. App Timeline — No Rush; Coexist Until Direct Competition

Decision: Wallet Passes ship relatively quickly (but xtoura-app does not have this feature — no conflict). Branded Passenger Portal gets built incrementally, starting with small widgets rather than a full portal. We wait until Busflow reaches genuine parity with the xtoura-app's passenger features before forcing the conversation.

Strategic implication: This buys 12–18 months of natural coexistence. During this time:

• xtoura-app continues serving passengers with its current features
• Busflow's widgets/portal grow organically
• Operators gradually discover that Busflow's portal delivers more depth (live GPS, wallet passes, self-service) than the xtoura-app can
• The sunset conversation happens when it is already obvious, not when it is premature and scary

Talking point for the partner: "We're building our passenger features step by step. Your app keeps serving passengers today. When our portal is ready, operators will compare and choose. We're not in a rush."

3. App Ownership — Quid Pro Quo

Decision: German law (§ 69b UrhG) assigns ownership of employee-created software to the employer by default. The partner may not realize that the xtoura-app's IP belongs to us. We are willing to grant the ex-employee extensive maintenance and development rights "for free" — but a full IP ownership transfer requires something in return.

Strategic implication: This is a negotiation lever, not a gift:

• Scenario A (cooperative partner): We transfer IP ownership as part of a broader partnership agreement that includes the commission structure, Busflow distribution commitment, and integration cooperation
• Scenario B (difficult partner): We retain IP ownership and grant a perpetual license to the ex-employee for maintenance. The partner gets functionality continuity but no IP control
• Scenario C (no agreement): We retain full ownership. This is the default legal position, not a threat — it simply means no deal was reached on this point

Red line: Do not transfer IP without receiving a concrete commitment (commission agreement signed, minimum operator referrals, or Busflow integration cooperation).

4. Exclusivity — Framing Without Commitment

Decision: No real exclusivity. We can frame as exclusivity because Busflow is not actively selling yet — the partner gets a de facto head start without a contractual lock-in.

Strategic implication: This is a time-limited perception play:

• "You are our first and only sales partner" is true today and feels exclusive without being contractually binding
• If the partner pushes for a written exclusive, offer a time-limited first-mover clause (e.g., "12-month exclusive distribution in your existing operator network") that expires naturally
• The commission structure (80% revenue share) is already a strong incentive — exclusivity is unnecessary when the economics are this generous

Concession toolkit (in order of preference):

1. "First-mover advantage" language (no contract change needed)
2. 12-month right of first refusal for operators in their existing network
3. Co-branded marketing materials ("Powered by Busflow, delivered by [Partner]")
4. Never: geographic or segment exclusivity that limits Busflow's ability to sell directly

5. xtoura PIM Integration — Platform Neutrality

Decision: Platform neutrality. Busflow exposes generic APIs; the partner's IT builds the integration on their side. No dedicated xtoura connector.

Exception: If building a quick connector (< 1 week) unlocks a concrete business outcome (e.g., 10+ operators onboarded faster), consider it as a tactical investment, not an architectural commitment.

Strategic implication: This protects Busflow from coupling to a system that is, by our own assessment, "purely engineered" and a liability. If the partner's IT refuses to build the integration, Busflow's Email-as-API and manual CSV import remain viable alternatives.

Talking point for the partner: "We built Busflow API-first so anyone can integrate — your PIM, other systems, whatever. We don't play favorites with connectors. Your IT team builds the bridge; our documentation makes it easy."

---

9. Exit Checklist

Regardless of how the meeting goes, try to walk away with answers to these:

• [ ] Which operators need the widget? Names, not abstractions.
• [ ] What is the relaunch timeline? When does the PIM go live?
• [ ] How do operators feel about payment commissions? Acceptance signal.
• [ ] Does the partner plan to monetize the widget? Their revenue model.
• [ ] Is there a concrete next step? Pilot, follow-up meeting, or document to send.
• [ ] What is the developer's stance? Supportive, neutral, or hostile?

If You Get a Pilot: Ideal Outcome

• One operator, one website.
• You deploy the Busflow widget.
• 30-day test period.
• You share booking numbers with the partner via a simple dashboard view.
• After 30 days: review meeting with real data.

If You Get "We Need to Think About It": Acceptable Outcome

• Send a one-page overview within 24 hours.
• Propose a follow-up meeting within 2 weeks.
• Include one concrete ask: "Can you share which operator you would want to test with?"
• This keeps the conversation alive and gives them something to react to, not just think about.

If You Get a Hard No: Fallback

• Understand why. Is it the pricing? The product readiness? The developer's pushback?
• Leave the door open: "No problem. When the widget is live, I will send you a demo link. If you change your mind, we can always revisit."
• Do not burn the relationship. The partnership has value beyond the booking widget (operator introductions, website embed, future Busflow distribution).