Meeting Playbook — Booking Widget Conversation

Context: The partner is relaunching the xtoura system and needs a booking widget for their PIM / operator websites. This playbook prepares for the meeting where the scope, roles, and commercial model get discussed. Primary partner motivation: Upsell their website clients with booking capability — operators who either have terrible booking forms or no booking system at all.

---

1. Meeting Strategy

Your Posture: Listen First, Pitch Second

You already know what you want (Busflow widget). You do not yet know what they want — concretely. The meeting is a discovery conversation disguised as a partnership discussion. Your job in the first 15 minutes is to ask questions and let them talk.

Why this matters: If you open with a Busflow pitch, the developer in the room will immediately position against it (threat to his scope). If you open by asking what they need, the partner describes the problem, and you offer the solution. The developer hears "help" instead of "replacement."

Primary Objective

Walk away with two things:

1. A concrete next step — ideally a pilot with one operator ("Give me one website, I deploy the widget, we measure for 30 days").
2. Answers to the money questions — how do operators feel about commissions? Does the partner plan to take a cut? What pricing model do they envision?

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 Playbooks

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 "Technical Co-Founder" positioning — exactly the vision for this partnership.

---

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	"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. Meeting 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).