Stream 1 BD Kickoff — Muhammad Yacoubi — April 14, 2026

Person

• Name: Muhammad Yacoubi
• Role: Senior Director BD, Kerten Hospitality; de facto Stream 1 champion
• Background: Moroccan; focused on Morocco and MENA; been with Kerten ~12 months in full-time capacity; previously an advisor/opener
• Position: One level below Ramin (CBDO); most influential BD operator after Ramin

Key Topics Discussed

Proposal structure:

• Three information categories: (1) files/documents, (2) unmapped processes, (3) cross-departmental data
• Proposal = creative part + execution part
• Anthony Douce and Marlo as key creative contributors
• Document chain: market data → RFP → concept proposal → commercial terms + financial projections

Lead sourcing:

• Pipeline scouting is ~50% network-based / fortuitous — not systematic
• Brokers, consultants, and owners reach out directly as the main channels
• No formal intelligence system; Muhammad manually monitors news and LinkedIn

Process mapping intent:

• The team acknowledged no formal process map exists
• Goal of interviews: map current state before designing the AI system

Coordination:

• Weekly meeting: Mondays 4pm Dubai time
• WhatsApp "BD AI task force" group for rapid communication
• SharePoint managed by Douglas (Broad Vision IT partner)

Decisions Made

• Interview schedule agreed upon — all BD team members to be interviewed across the week of April 14
• Muhammad to serve as internal champion and facilitate access to stakeholders
• Meeting cadence: weekly Monday 4pm progress review

Observations

• The 50% fortuitous pipeline is the core intelligence hub problem — Muhammad's admission that half of leads come from chance meetings or inbound requests is the clearest articulation of why a structured intelligence system is needed
• Anthony and Marlo as creative anchors — Muhammad positions Anthony (Chief Experience Officer) as the creative vision holder; Marlo (CEO) as the organizational force behind it
• The interview plan was strategic — Muhammad helped shape who to speak to: Lily (creative), Karolina (revenue), Tara (legal), the BD executives (execution), and Anthony (direction)
• Muhammad is a builder, not just an approver — unlike Ramin who reviews, Muhammad is actively in proposals, especially for Morocco and MENA
• SharePoint is the central document repository — but access and organization is managed through Broad Vision (Douglas), not internally governed

Stream 3: AI Foundations Kickoff — April 14, 2026

Attendees

• Mina Anziani — COO, Kerten Hospitality
• Aman Malhotra — CFO, Kerten Hospitality
• Theo Breward, Maria Haddad, Shaheer Ahmed — Vela Advisory

Context

Stream 3 is separate from Stream 1 (proposal generation). It covers organization-wide AI foundations: tooling, policy, and training for all Kerten employees — not just BD. Mina and Aman are the primary client stakeholders for this stream.

Key Topics Discussed

Three-tier AI application model (Theo's framing):

1. Task-level productivity — summarizing emails, faster document drafting, cognitive load reduction (Stream 3 scope)
2. Process-level — optimizing the BD proposal workflow (Stream 1 scope)
3. Business model level — doing something previously impossible with AI ("moonshot" / Stream 2)

Survey results shared:

• 2/3 of Kerten employees are active AI users; 1/3 use daily
• 75% want more AI tools
• Only 25% satisfied with current AI usage level
• Top concern: confidential data exposure (no policy currently in place)
• Employee matrix: 41% enthusiastic but low-skill; 33% enthusiastic and skilled (future champions); 17% low-skill and cautious

OECD AI Maturity Framework:

• Kerten currently at Stage 0 (informal, uncontrolled use — "shadow AI")
• Stage 1 = approved baseline (one enterprise tool, basic policy and training)
• Target: Stage 1, with some employees moving toward Stage 2 (shared prompt libraries, AI champions)
• EU AI Act: mandates basic training if company provides AI tools to employees

Three implementation dimensions agreed:

1. Tooling — select and deploy the enterprise AI tool (Claude being recommended)
2. Policy — write AI use policy specific to hospitality and Kerten's geographies
3. Training — activate all employees with two basic training sessions; identify internal AI champions

Decisions Made

• Mina and Aman to gather hospitality industry best practices before reconnecting Monday April 20
• Vela to package tool comparison, best practices, and budget overview for April 20 follow-up meeting
• No employee-wide survey required beyond what's already done; Marlo requested executive-level approach

Observations

• Mina already had a budget pre-allocated for AI tooling — implementation is not blocked by budget; it's blocked by tool selection and governance
• Shadow AI is already happening — employees are feeding Kerten's confidential data to public AI tools with no controls; this is the immediate risk
• Finance has zero AI champions per survey — Aman acknowledged this; CFO function is the least AI-ready
• Operations is out of Stream 3 scope for now — Mina noted it's a "vast" topic spanning corporate office and 55+ hotel properties; it requires its own dedicated stream
• The "corporate office vs. hotel properties" vocabulary is the standard differentiation Kerten uses for organizational layers
• Stream 3 and Stream 1 are parallel — Stream 3 sets foundations for everyone; Stream 1 builds a specific AI system for BD. Both are in flight simultaneously

Vela Internal Check-in — April 14, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

First Vela internal check-in of the engagement. Theo explains the Vela venture studio model and frames the project scope. Two streams in flight simultaneously: Stream 1 (BD proposal builder) and Stream 3 (AI foundations). Two-week objective is to map all data, systems, and processes before building.

Key Topics

Vela model:

• 80/20 rule for AI automation: focus on the 20% of tasks that consume 80% of time
• Engagement model: map first, then design, then build
• Two-week sprint to understand before proposing technical solutions

Stream scope:

• Stream 1.1: Proposal generation automation for BD team
• Stream 1.2: Intelligence hub / lead sourcing
• Stream 3: Company-wide AI foundations (tooling, policy, training)

Meeting transcript handling:

• All meeting transcripts to be shared with all attendees by email after each session
• Transcripts are the raw knowledge base — to be used for process mapping and system design

CRM context:

• A CRM is being built in parallel (separate stream); Vela must be aware of it to avoid duplication

Observations

• Both proposal builder (1.1) and intelligence platform (1.2) are in scope — they were framed as connected but distinct products from the first day
• Transcript-to-database pipeline was discussed — potential to hook unstructured conversation data into a structured database; this is essentially what this knowledge base is doing
• The two-week mapping sprint was the right call — the chaos and disconnects discovered in interviews validated this approach

Business Development Executive — Alicia — April 15, 2026

Person

• Name: Alicia (last name not mentioned in transcript)
• Role: Business Development Executive, Kerten Hospitality
• Tenure: 2.5 years at the company
• Position in proposal process: End-to-end owner of proposal creation for her assigned markets — handles everything from brief intake to completed deck, including market research and first-draft financials
• Peer: Sara holds the same role; they split work by availability, no formal division

Inputs

• Project briefs arrive primarily via email — from external consultants (after NDA is signed) or routed internally through senior stakeholders (Anthony, Muhammad, Ramen, Hassan)
• Brief format is entirely unstructured — no template exists. What she receives is a freeform email with the stakeholder's brainstormed ideas or direction - Anthony's emails tend to be more specific (bolded titles that map directly to slides) - Muhammad provides a broader, vaguer overall direction
• Additional details sometimes come via Teams calls, phone, or in-person meetings, but email is the primary channel
• If she's assisting a colleague rather than leading the project, she receives information secondhand through them rather than from the original source
• Market/region determines who her primary input source is: - Morocco & Africa → Muhammad + Anthony - Europe → Ramen - Middle East → Hassan (recently started, limited involvement so far)

Her Process

Step 1 — Receive & interpret the brief

• Read the email/brief and determine: brand (The House, Cloud 7, Memi), project type (hotel / residence / branded residence / service apartment), and geography
• Determine whether the owner is visual or technical — inferred from conversations, consultant input, or research
• Determine whether Anthony's creative direction is needed or if she has enough autonomy to proceed

Step 2 — Wait for creative direction (if applicable)

• For Morocco/Africa projects or high-importance projects: must wait for Anthony to provide his vision before proceeding
• For Europe: largely autonomous

Step 3 — Source visuals

• Review teaser materials provided by the consultant or owner
• Source additional matching images from Pinterest, Google Images, or general web search
• Match images to the design theme, location feel, architecture, and target guest profile
• Deliberately avoids AI-generated images — considers them too artificial-looking (though open to reconsidering)

Step 4 — Build the presentation The proposal structure is fluid, but slides generally fall into three tiers:

• Manually ensures correct font, logo, footer position, and color palette for the relevant brand on every slide
• If a project requires something completely different (especially Anthony's), she finds a past proposal with a layout she likes and adapts it as a base

Step 5 — Financial projections (Europe)

1. Open CoStar → filter hotels by location, key count, classification → select 4–6 comp set properties
2. Pull ADR, occupancy, RevPAR data (broken down by month/year for seasonality)
3. If CoStar lacks data → use Lighthouse → if still insufficient → manual search on Expedia/Booking.com
4. Enter comp set ADR + occupancy into Excel financial template
5. Apply a surplus or discount % to reflect positioning difference between comp set and the proposed concept (e.g. "8% above comp set")
6. Template auto-calculates projections from these inputs
7. Share first draft with Ramen (or relevant stakeholder) for feedback

Step 6 — Review & iterate

• Share completed draft with whoever gave the brief
• Revise based on their comments
• No formal approval stages or documented sign-off process

Tools Used

• CoStar — primary market data platform (STR data: ADR, occupancy, RevPAR, seasonality)
• Lighthouse — backup market data platform
• Expedia / Booking.com — last-resort manual comp set research
• Excel financial projection template — being updated/finalized at time of interview
• PowerPoint — presentation building (implied throughout)
• Pinterest / Google Images — visual sourcing
• ChatGPT (occasionally) — keyword brainstorming for slide copy
• Email / Teams — all communication and brief delivery

Outputs & Handoffs

• Completed proposal presentation deck (PowerPoint)
• First-draft financial projections for Europe (shared back to Ramen/brief-giver via email for comments)
• Final proposal sent back to the person who initiated the project (no standard delivery format or channel mentioned)

Approvals & Back-and-Forths

• No formal approval process or documented sign-off stages
• Review loop is entirely bilateral: Alicia ↔ brief-giver (Ramen, Anthony, or Muhammad)
• Main bottleneck: waiting for Anthony's creative direction — he travels frequently, delays can be 2–4 days
• Revision cycles exist but no standard number mentioned — implied to be driven by stakeholder feedback

Time & Volume

• Full proposal (new joiner): 2–3 days
• Full proposal (Alicia, experienced): faster — no exact number given, varies by familiarity with market
• Image sourcing alone: 1–2 hours per proposal
• Financial projections (familiar market): ~3 hours
• Most time-consuming component: the creative/visual presentation work, definitively — more so than financials

Pain Points & Frustrations

• "No two proposals are the same" — every engagement is essentially bespoke, making standardization very difficult
• Brand guidelines for The House, Cloud 7, and Memi are not formally documented anywhere — Lily (Creative Director) was working on them but they were never completed or shared. Everything lives in people's heads
• Brief format is entirely freeform — no template, no structure, quality and specificity of input depends entirely on who is sending it
• Image sourcing is brutal: "The amount of pictures we use on a day-to-day, it's really insane" — tried a central image library once, abandoned it because every project needs new, project-specific visuals
• When copying a slide from another brand's template, every element (font, logo, footer, colors) must be manually corrected — no automation
• Anthony's dependency creates hard stops: "he's always on the road, it can take up to two, three days, sometimes four"
• No pre-built templates for recurring slide types like timelines or graphs — has to structure these from scratch each time

Observations

• Alicia is a full-stack BD operator — she owns creative design, visual sourcing, market research, and financial modelling simultaneously. That's an unusually broad scope for one person
• Anthony is a single point of failure for Morocco/Africa creative direction — if he's unavailable, proposals in those markets stall completely
• All brand knowledge is tribal — it exists only in the experience of people who've been there long enough. A new joiner has no document to reference
• Brief quality is stakeholder-dependent — Anthony gives structured, slide-specific direction; Muhammad gives broad impressionistic direction. Alicia adapts her entire creative approach based on who sent the brief
• Lily (Creative Director) appears to be an important but peripheral figure — she created the fixed technical slides and attempted brand guidelines, but her work hasn't fed into a usable system yet
• The financial Excel template is still being finalized — current process is in a transition state; the old template was described as "complex"
• CoStar is load-bearing — if CoStar doesn't cover a market, the research process degrades significantly and becomes manual and time-consuming

Director of Revenue & Distribution — Karolina Krol — April 15, 2026

Person

• Name: Karolina Krol (last name from email: kkrol@kertenhospitality.com)
• Role: Director of Revenue & Distribution, Kerten Hospitality
• Position in proposal process: Supporting role — not in BD, but provides financial market data (ADR + occupancy) that underpins the financial projections in proposals
• Note: She is also responsible for delivering on the numbers at hotel opening — meaning inaccurate early projections become her operational problem later

Inputs

• Triggered by BD: BD team reaches out with a new project concept and asks for market data
• What she needs: Location, concept classification (star rating, key count, amenities) — enough to identify a relevant comp set
• Alternatively, she could be cc'd on Anthony's briefing emails — all she needs is location and positioning intent
• In practice, she only gets called in by ~5 projects this year (through April) — well below ideal involvement level

Her Process

When CoStar (STR) data is available — 90% of proposals:

1. Identify 4+ participating hotels in the market that match the concept
2. Select comp set (constraints: minimum 4 hotels; no single owner >70% share of inventory)
3. Pull past 12 months occupancy and ADR
4. Position the new property relative to the comp set (10–15% above/below, based on intended positioning)
5. Send formatted summary to BD team

When CoStar data is unavailable (Middle East/Africa niche markets) — 10% of proposals:

1. Open Lighthouse (live rate benchmarking — shows public OTA rates for next 12–15 months)
2. Select competitors manually, run report showing daily rates per property
3. Manually estimate breakfast cost (checks Booking.com for one vs. two person supplement)
4. Apply ~20–50% haircut to public rates to estimate net ADR (accounting for corporate, group, and channel discounts)
5. Cross-reference with ChatGPT for occupancy estimates in those markets (Google historical data as fallback)
6. Deliver estimated range to BD team

Key rule: CoStar data is always net — pure room value, no taxes, service charges, or breakfast. This is the number BD uses directly. Lighthouse data is gross and requires back-calculation.

Tools Used

• CoStar (formerly STR) — primary platform; date-specific, confidential performance data (ADR, occupancy, demand)
• Lighthouse — fallback; live public rate benchmarking only; requires manual calculations to convert to net ADR
• Booking.com — supplement checking to estimate breakfast cost
• ChatGPT — occupancy estimation in markets with no STR/Lighthouse data
• Excel — manual calculation template for Lighthouse data (no standardized template; she builds her own each time)

Outputs & Handoffs

• Past 12 months ADR and occupancy summary in a user-friendly format
• Sometimes delivers a positioning recommendation alongside the data (e.g. "aim 10% above comp set")
• Delivered to BD via email; occasionally reviewed on a call with Amin or Ramin before final use

Approvals & Back-and-Forths

• Amin (Director of BD) requires her sign-off in principle, but BD frequently skips this due to time pressure
• Formal approval threshold (her suggestion): >100–150 rooms or strategically important owner/destination
• Informal threshold in practice: if BD has time, they call her; if not, they log into CoStar themselves
• She rarely sees the final proposal — "I'll probably find out after two years" whether the numbers she gave were used or adjusted
• When BD sends her numbers for review: she accepts them most of the time; approximately twice in 6 months has she made significant changes

Time & Volume

• CoStar workflow: ~1 to 1.5 hours per project
• Lighthouse workflow: ~2 to 2.5 hours per project (adds ~1 hour for manual rate analysis)
• Realistic capacity: ~1 hour per day dedicated to BD support
• Actual volume: ~5 projects in the first 4 months of 2026 — far fewer than what the BD team is producing

Pain Points & Frustrations

• "Sometimes I don't really see [the request]. I need to decide what is urgent. And they sometimes need the information right now and I'm not able to do that. I will need 24 probably, ideally 48 hours to reply."
• BD either forgets to involve her or is too time-pressured — she has no visibility into the pipeline
• The ideal workflow (BD sends → she pulls → BD updates) exists verbally but is never followed consistently
• Lighthouse process is manual and approximate: "It's a lot of cloudy judgment. It's never right or wrong until we actually get to the first year of operation."
• Occupancy estimation without CoStar is particularly unreliable — she cannot derive it from Lighthouse alone
• No standardized Lighthouse output template — she builds her calculation each time from scratch

Observations

• The 24–48 hour delay is structural, not behavioral — Karolina manages revenue for 7 operational hotels solo; it is physically impossible for her to be responsive on-demand to an open-ended number of BD requests
• Karolina is the downstream accountability holder — she will be responsible for delivering the numbers that BD's early-stage proposals commit to. This is a strong reason for her involvement, which is currently not reflected in the process
• CoStar is a 2-number extraction for BD — Karolina's insight is the same as Sara's: ADR and occupancy are the load-bearing numbers; everything else in the financial model is judgment
• The comp set problem in emerging markets is a hard constraint — Egypt, Alula, niche Africa destinations don't meet CoStar's 4-hotel minimum. Lighthouse is a workaround, not a solution
• Her proposed automation is already specific — she wants a notification system that auto-flags every new pitch with a 24-hour comment window. For small projects, this is optional. For >100 rooms, approval is required. This is a well-defined workflow that maps directly to a system feature
• The "optional but visible" model she proposed — wanting to see all data without being a mandatory bottleneck — is a practical governance design that reconciles BD speed with her accountability

Creative Director — Liliya (Lily) Gateva — April 15, 2026

Person

• Name: Liliya Gateva (Lily)
• Role: Creative Director, Kerten Hospitality
• Background: Master's degree in interior design — this is the core of her speed and expertise
• Position in proposal process: On-demand design resource, not in the standard proposal flow. She's pulled in when proposals require custom or complex design, when the BD team is overwhelmed, or when a proposal is high-importance
• Note: There was previously a dedicated interiors architect on the team — that role no longer exists; all interior design knowledge now sits with Lily

Inputs

Lily receives proposal requests in three scenarios, ranging from best to worst:

1. Draft PPT with text — BD has already built a deck with correct fonts, and marked where images are needed. Closest to ideal.
2. Text only, no deck — BD sends text and she builds everything including images from scratch
3. Text in an email — Anthony's typical mode: pours his thoughts into an email and expects Lily to turn it into a presentation. Lily is used to this working style with him specifically

• She will not start working until she has text — no point engaging before that
• For major proposals, BD may pre-warn her ("we'll send you something Wednesday") but involvement only starts once text exists
• Input quality and format depends entirely on who is sending it and how busy they are — no standard

Her Process

Step 1 — Determine design direction

• Identify the brand (The House, Cloud 7, Memi) — each has different fonts, colors, and base templates
• For Cloud 7: three sub-directions (seaside, urban, mountains) each with different accent color codes
• Factor in property importance/value — higher value shifts toward more minimal, polished aesthetic
• Factor in location — designs respect locality with a modern twist (e.g. Morocco: avoid dark blue, use softer geometry-based palettes; Rome: Renaissance illustrations in a contemporary style)
• Factor in owner/audience taste — intel comes from whoever has the owner relationship in BD; if unknown, it's a "hit or miss"
• For C-level-driven projects: a senior stakeholder (e.g. Anthony) may explicitly say to deviate from standard brand template

Step 2 — Source images

• Primary source: Pinterest — she maintains extensive boards per property; suggestions are auto-curated over time
• For highly conceptual projects (e.g. branded residences where nothing physical exists): ChatGPT for AI-generated images, Adobe Firefly for video
• Interior mood board slides are where her expertise is irreplaceable — she thinks in color connections, rule of three, visual guidance cues, textures

Step 3 — Build the deck

• Layout, image placement, visual hierarchy are her creative contribution
• Text content comes from BD (or Anthony) — she doesn't write it
• Slides that say "mood board" in the text are a signal for her to source and build a visual slide per listed area
• For interior/look-and-feel slides: she does these herself — graphic designer and BD team cannot handle them
• For general images and text formatting: she may delegate to the graphic designer or pass back to BD

Step 4 — Review loop

• Typically ~2 rounds of revision
• Text edits: passes PPT to BD to edit themselves
• Visual edits: deck stays with her until finalized
• Final approval: whoever is presenting (usually Anthony for important projects) must agree before it goes out

Tools Used

• Pitch — preferred presentation platform (online, cloud-based fonts, lockable elements, built-in brand templates, fast image handling); she uses this when she has 2 hours and needs speed
• PowerPoint — main company tool; she dislikes it (slow, no locking, huge file sizes)
• Pinterest — primary image sourcing, boards organized per property
• ChatGPT — AI image generation for conceptual/branded residence proposals
• Adobe Firefly — video generation (occasional)
• PDF — final delivery format (PPT files reach ~500MB; exported, compressed, and sent as PDF)

Outputs & Handoffs

• Partially or fully designed PPT
• Text-heavy portions passed back to BD team to edit
• Sent to Anthony (PDF + email feedback), Muhammad, or relevant BD team member depending on the proposal
• Final client-facing output is always a compressed PDF

Approvals & Back-and-Forths

• ~2 rounds of review in normal cases; more if the concept wasn't nailed on the first pass
• Anthony's feedback method: reviews PDF, writes comments in an email ("slide 3, change X to Y")
• BD team: edits PPT directly and passes back
• Final sign-off by whoever will be presenting — they must personally agree with and be able to defend the content
• Country director is always in the loop (Muhammad for Morocco, others by region)

Time & Volume

• Lily is extremely fast: "it takes me literally like a few hours" — entirely due to interior design expertise
• Busy period benchmark: 2 branded residence proposals + 2–3 normal proposals per week
• Volume is unpredictable — she is the last to know how many are coming because she's reactive

Pain Points & Frustrations

• "The guidelines and the templates have no connection" — existing brand guidelines are heavily outdated; The House Hotel guidelines don't reflect any current designs; Cloud 7 update planned for end of May but not confirmed
• Graphic designer cannot handle interior slides — passes them back every time; the design knowledge required is post-graduate level, not something easily transferred
• BD team moves slide elements deliberately: "It's entirely on purpose. Not accident. If you can, you do." — no locking mechanism in PowerPoint
• BD team uses AI for text, always producing M-dashes: "I'm confident none of the people in this company know how to use an M dash" — Lily has to clean this up
• Templates are not governed — team picks whichever template they like regardless of brand/geography fit; Lily only discovers misuse after the fact ("they used it for five more decks. I didn't know")
• Too many people per deck: brief originator → country director → BD → Lily = 4 people touching one document
• Dislikes PowerPoint deeply; prefers Pitch but company is unlikely to switch

Observations

• Lily is a single point of failure for interior design direction — the previous dedicated interiors architect is gone; this expertise now lives entirely with one person who is also the Creative Director doing other work
• Brand identity and actual practice are formally disconnected — Lily confirmed it herself. The guidelines are a reference artifact, not a working tool
• Kerten's "no cookie-cutter" brand philosophy is operationally self-defeating — it's a stated brand value that makes standardization genuinely difficult, not just a process failure
• Pitch platform directly solves several pain points PPT cannot — cloud fonts (no installation needed), lockable elements, built-in brand templates. Worth investigating seriously
• Anthony's feedback loop is functional but entirely informal — PDF + email comments work for him, but creates no traceable record or structured revision history
• The BD team's template reuse behavior is a governance gap, not a skills gap — they know what they're doing; there's just no system to enforce correct usage
• Lily has no formal intake or SLA — she is engaged reactively, with no visibility into the proposal pipeline until something lands in her inbox

Development Executive — Sara Granieri — April 15, 2026

Person

• Name: Sara Granieri
• Role: Business Development Executive, Kerten Hospitality
• Position in proposal process: End-to-end owner of proposal creation for European markets — handles concepts, visuals, branding, financials, and commercial terms
• Peer: Alicia holds the same role; they split work by availability and region

Inputs

• 60% consultant-sourced — comes with a PDF teaser document containing project details, market analysis, and comp set data. Most useful input type.
• 40% direct contact — owners/investors who reach out directly with less initial data, requiring more upfront research
• Volume split varies by region: Italy is more direct-contact; rest of Europe more consultant-based
• Creative direction from Anthony arrives by email for 20–30% of proposals (only the most important ones) — the rest she handles on her own judgment
• Financial approval: calls with Ramin (for Europe) or Aman; adds 1–2 days due to availability

Her Process

Step 1 — Identify the base proposal

• Find a past proposal with similar concept or location from the SharePoint library
• Copy-paste the entire presentation as a working base — "that's the actual template we have"
• Mix and match specific slides from other proposals as needed

Step 2 — Structure the sections

• Determine whether the project is data-driven or visual/mood-board-driven (no standard formula)
• Adjust structure: some proposals are heavily text-based; others are mostly visuals
• Standard fixed slides (case studies, team, community experience): minimal effort, copy-paste with minor formatting adjustments; senior management may still request photo changes

Step 3 — Source visuals

• Goes to Pinterest — searches lifestyle hotel photos, iterates through imagery
• Has no formal design training: "I'm not a very aesthetic person, so I have no idea if this looks good next to this"
• Prefers existing real photos over AI-generated images (finds AI images too artificial)
• In one instance, used AI-generated images alongside real photos and marked them explicitly in the deck

Step 4 — Build the presentation

• Manually ensures correct font, logo, footer, and color palette per brand
• Color coding was originally by property type (blue = beachside, black = city, etc.) but Anthony gave feedback that black city templates were "boring" — no agreed new standard exists; Sara now uses red for city even though it doesn't match the original rule
• Presentation must not look templated — senior management pushes back when it feels copy-pasted

Step 5 — Financial projections

• Downloads CoStar report (15-tab Excel), extracts only 2 numbers: ADR and occupancy
• Applies own judgment to project whether property will outperform, match, or underperform the comp set
• Remaining inputs (F&B averages, staffing, operating costs) filled manually using past projects, AI (ChatGPT), or Glassdoor for salary benchmarks
• Financial model is blank — all gray fields populated manually; generates a 5-year P&L as output
• Output is screenshot/pasted as image into the proposal — not embedded as live data

Step 6 — Commercial terms

• Uses legal template with target/minimum/ask scenarios
• Choice of ask vs. target is judgment-based on market negotiation culture (Morocco = ask; Germany = target)
• Approved by Ramin — described as the fastest part of the process

Step 7 — Review loop

• Shares draft with brief-giver (Anthony, Muhammad, Ramin, or Hassan)
• Revisions are subjective and can drag on: "one could argue for two days on one single image"
• Financials review: goes on a call with Ramin or Aman to walk through assumptions

Tools Used

• CoStar — sole data platform used for financial projections (has Lighthouse access but never uses it)
• Excel financial projection template — blank, manually populated, auto-generates P&L output
• PowerPoint — presentation building
• SharePoint — proposal library organized by region → country/city/brand
• Pinterest — visual sourcing
• Claude plugin in PowerPoint — used once to integrate Anthony's feedback into the deck; produced one summary slide
• ChatGPT — salary benchmarking and F&B cost research
• Glassdoor — salary benchmarking (less frequently now)
• Email / Teams — all communication

Outputs & Handoffs

• Completed proposal deck (PowerPoint, sent as PDF)
• Financial projection model (reviewed on a call with Ramin or Aman)
• Delivered back to brief-giver via email

Approvals & Back-and-Forths

• No formal sign-off stages
• Presentation review: bilateral loop with brief-giver; highly subjective, driven by aesthetics
• Financial review: verbal call with Ramin/Aman; primarily about agreeing on the two CoStar numbers
• Financials process is smoother than presentation because it's data-based, not aesthetic

Time & Volume

• Full proposal (experienced): ~2 days end-to-end
• Financial projections alone: at least 4 hours (for unfamiliar market; more if research-intensive)
• Most time-consuming: visual/creative work — definitively more so than financials
• Busy periods: multiple active projects simultaneously, managing European markets

Pain Points & Frustrations

• "We don't have any templates. So I use that [past proposal] and then of course a lot of times it happens that I'm copying from a presentation that I didn't work on — and I didn't know that Cloud 7 changed into [new spec]. I had no idea. And so I'm sending out something that's not approved and not in line with our standards."
• Color and template standards are not agreed upon — Anthony's informal feedback overrides any existing rule without creating a new one
• Visuals are a nightmare without design skill: "Pinterest is a ton of different styles. I'm not a very aesthetic person. It's very hard for me."
• Management explicitly rejects proposals that "look like a template" — but has not provided an agreed alternative
• Presentation approval is slow and subjective; financials approval adds 1–2 day dependency on Ramin/Aman
• Claude plugin use was experimental — positive experience but only done once

Observations

• Sara is the second full-stack BD operator — same breadth as Alicia (creative, market research, financials, commercial terms), confirming this is not a one-person anomaly but the actual role definition
• CoStar is consistently described as a 2-number extraction exercise — 15 tabs, 2 numbers used. The rest of the financial model is judgment and research, not market data
• Senior management's aesthetic preferences override any standardization attempt — Anthony's feedback on the "boring black template" has actively broken the previous color-coding system, leaving nothing in its place
• The Claude plugin trial is a proof of concept — Sara independently discovered it, used it to process Anthony's feedback into a slide, and described it positively. This is the only unsolicited AI tool adoption observed across all interviews
• Financial approval via call (not document) — the review process is conversational, not documented. No paper trail or decision record exists
• Sara's comment on custom vs. template is the clearest articulation yet — "You're free to choose where to put images, how to shape the slide. The important thing is just the font and the content." This is the actual brief for the AI system

Vela Internal Check-in — April 15, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

Morning check-in before a busy interview day (Lily, Karolina, and concept proposal sessions). Covers stakeholder influence mapping, Ghassan's image generation request, and Stream 3 maturity model progress.

Key Topics

Stakeholder influence map:

• Marlo (CEO): most influential — can push the project through even if the whole organization disagrees; described as a "force of nature"
• Ramin (CBDO): global BD boss; high expectations; was burned by a bad AI experience (asked ChatGPT to build a deck and it failed); needs trust re-earned
• Muhammad: influential veteran; champion for the project; well-respected despite being newer to full-time role
• Michael O'Shea (owner): will be involved from Stream 2; his son Cathal is sniffing around all meetings
• Cathal O'Shea: accept his involvement politely; don't over-index

Ghassan's image request:

• Ghassan wants to create a new template for a Saudi e-gaming hotel proposal and doesn't like existing templates
• Theo gave him Midjourney and MiiM AI (Microsoft image model, US-only VPN required)
• This prompted a product idea: build an internal image library in coordination with Lily, allowing employees to add images that the AI tool picks from
• Theo tested giving Claude a folder of photos for website selection — Claude accurately categorized images and selected the best fit for context

Stream 3 progress:

• Maria created a 5-page skeleton deck for the AI maturity benchmark
• Framework: OECD Digital AI Maturity Model (Stage 0 → Stage 1 → Stage 2)
• Kerten is at Stage 0 (informal, uncontrolled use)
• Target: Stage 1 (approved tool, basic policy and training)
• 76% of organizations are already at Stage 1 or above — Kerten is behind
• EU AI Act mandates training for any company providing AI tools to employees
• Shadow AI risk: employees feeding confidential data to public tools

Process mapping intent:

• Shaheer starting to mentally model the AI systems needed
• Theo frames the proposal as having discrete sections (concept, experiences, financials, case studies) — each a separate automation challenge
• No formal process map exists at Kerten; the mapping effort itself is a deliverable with value

Observations

• The image library idea from this check-in became a system design element — the concept of employees curating a shared visual bank is directly relevant to the Pinterest/image sourcing component of the proposal system
• Ramin's AI trust deficit is a known risk — Vela needs to demonstrate concrete value early before Ramin becomes a blocker
• The "winning Marlo" goal is the primary success condition for the engagement — everything else is secondary

Chief Experience Officer — Antony Douce — April 16, 2026

Person

• Name: Antony Douce
• Role: Chief Experience Officer, Kerten Hospitality
• Position in proposal process: Strategic creative director for high-importance pitches — defines vision, positioning, and concept direction. Not involved in all proposals; pulled in selectively based on conversion potential and project complexity
• Note: He is almost always the one who presents proposals to owners — which is why he insists on content he wrote himself and can personally defend

Inputs

• Triggered by Muhammad or the BD team when a proposal requires his creative input or has high conversion potential
• Approximately 2–3 new pitches per week requiring his involvement
• Receives project details from the BD team — location, property type, RFP documents
• For important projects: conducts his own research independently before providing direction
• In some cases: physically visits the property as a "mystery guest" before meeting the owner

His Process

Step 1 — Assess conversion likelihood

• Evaluates how much effort to invest based on chance of winning: - High effort: Conversion projects (owner stuck, tired of self-management, willing to invest), cultural/art/bespoke projects that match Kerten's forte, boutique properties not competing with loyalty-heavy brands - Low effort: Greenfield RFPs where Marriott/Hilton are competing (Kerten rarely wins these on distribution/marketing scale alone)
• Middle East factor: "The decision is half sentimental, half business. People do business with you because they like you."

Step 2 — Research the destination and opportunity

• Gathers information through multiple channels (combined, minimum 3–4 hours): - Phone calls with industry contacts and friends-of-friends — the primary source for insider intelligence; irreplaceable by AI - ChatGPT — for information, ideas, and destination data (now finds it more useful than Google News) - Google News — for latest press on the owning company, destination trends - LinkedIn + company websites — to understand owner sensibility (art, sustainability, culture interests) - Booking.com / Expedia reviews — reads competitor review patterns to identify recurring pain points that can be leveraged in the pitch (deliberately avoids TripAdvisor: "it's bullshit") - Instagram, YouTube, travel, exhibitions — major source of visual inspiration; he scrolls extensively for hotel/restaurant/design ideas
• Also asks: What is the destination's "problematic"? (Low season, empty weekends, etc.) and how can the hotel concept compensate?
• For conversion projects: involves Karolina to analyze the existing hotel's performance vs. competition

Step 3 — Draft the vision and send to BD team

• Writes thoughts as an email draft
• Uses ChatGPT to edit and structure the email (not to generate ideas — to clean up his own writing)
• The email defines: vision, mission, focus areas, target audience, tone
• For visual-heavy projects or owners who are design-sensitive: explicitly asks the team to involve Lily (and sometimes Shannaz) to ensure the visual impact matches the message
• BD team is finance-driven, not aesthetically driven — he relies on creative team to translate his vision into imagery

Step 4 — Review the presentation

• BD team executes based on his email instructions
• He reviews the draft; two typical outcomes: - For complex or inspiring projects: provides all content himself; BD just handles visuals - For standard cases: gives directional notes — remove this, adjust that, fix the tone
• Core standard: removes generic ChatGPT-sounding text: "It's bullshit ChatGPT that means nothing. I only sell what I did myself and trust is good."
• Approximately 2 rounds of corrections; 1–3 days depending on urgency
• For some high-profile RFPs: pre-submits to consultant (JLL, Colliers, PWC) for informal feedback before final submission to owner

Tools Used

• Email — primary output channel for vision/instruction to BD team
• ChatGPT — editing and structuring his written drafts; also for destination research
• Google News — company/destination research
• LinkedIn — owner background research
• Booking.com / Expedia — competitor review analysis
• Instagram / YouTube — visual inspiration (offline habit, not part of formal workflow)
• Phone calls — most critical and irreplaceable tool

Outputs & Handoffs

• Instruction email to BD team (vision, mission, focus areas, tone, specific slide requests)
• In some cases: full content draft sent directly to BD for visual execution only
• Final presentation reviewed and approved by him before owner submission
• Occasionally presents proposals directly to owners

Approvals & Back-and-Forths

• Typically ~2 rounds of corrections
• Timeline: same day to 3 days depending on workload and proposal urgency ("the deadline is always yesterday")
• For conversion projects with consultants: additional pre-submission review loop (JLL, Colliers, PWC)
• Muhammad (or country directors) decides whether to involve Antony on a given project — he is not self-triggering

Time & Volume

• Research per high-importance proposal: minimum 3–4 hours (can extend significantly for complex projects)
• Email drafting: faster; ChatGPT polish adds small overhead
• Review cycles: 1–3 days per round; typically 2 rounds
• Volume: 2–3 pitches per week requiring his input
• Conversion ratio: ~20% of proposals are conversion projects; these receive disproportionate effort

Pain Points & Frustrations

• Research is the biggest time sink: "I find an article — I want to read the entire article — sometimes I find documentation on the destination or statistics — maybe 30–40 pages — and from those 40 pages I have only one or two small ideas."
• ChatGPT is useful for editing but not for creative strategy: "AI is always positive with whatever you propose. There's never a contradiction. They always say oh yes, it's a good idea."
• Quality degradation under load: "If I have too many at the same time that require a lot of research and creativity — the quality of the work that I would do would be affected."
• Cannot always go on-site before pitching: would ideally visit every property with high conversion potential — capacity doesn't allow it

Observations

• Antony is the single gatekeeper for creative quality — by his own and everyone else's account. All creative direction flows through him for important proposals. There is no backup
• His explicit automation wish is precise: synthesize Google reviews and destination statistics/documentation into a briefing. The research that currently takes 3–4 hours is largely document-reading with minimal information density. This is automatable
• Phone calls are not a workaround — they are the strategy — his best pitches (Nile cruise example) came from calling industry actors who gave insider intelligence unavailable in any database. This is not replaceable and should not be attempted
• The "bullshit ChatGPT" problem is the central quality risk for AI-generated proposals — Antony presents proposals himself and can only defend what he wrote. Any AI-generated text that sounds generic or hollow will be rejected at the review stage. The system must generate content that passes his authenticity filter
• "Brand guidelines not brand standards" is Kerten's core competitive differentiator — this is the explicit rationale for why every proposal is bespoke. It's not a process failure; it's a deliberate strategic position that makes standardization structurally difficult
• The mystery guest methodology — staying at a competitor hotel before the pitch — represents the ceiling of competitive intelligence. His suggestion to systematize online review analysis is a practical proxy for when site visits are impossible
• Proposal effort is explicitly tiered by conversion probability — this is an undocumented but consistently applied rule. The AI system should be designed to scale effort/automation level to match this triage logic

Digital Marketing Lead — Marina Peñate Le Bail — April 16, 2026

Person

• Name: Marina Peñate Le Bail
• Role: Digital Marketing Lead (functions as Marketing Manager / Brand Guardian), Kerten Hospitality
• Team: 3 people managing 12 brands and 55+ properties
• Position in proposal process: Brand compliance gatekeeper — enforces brand identity standards on BD proposals. Increasingly involved since Lily redirected BD requests to her. Had no visibility over BD outputs until recently
• Note: She was not involved in the original BD workflow at all — BD went directly to Lily. She is now being pulled in reactively and trying to establish a proper governance structure

Inputs

• BD sends an email with minimal information: "Thursday and say: for Monday we are meeting this owner, we need a proposal — that's it. I don't receive any more information."
• Sometimes just a project PDF — no brand specified, no concept direction, no context on what BD wants to communicate
• Receives ad hoc requests from Anthony, who contacts Lily directly on WhatsApp for bespoke graphic work
• No formal intake process, no questionnaire, no structured brief

Her Process

When involved (increasingly all new proposals):

1. Interprets the incoming request — determines which brand, concept direction, and key messages
2. Clarifies with BD what they want to say (adds a round of emails)
3. Writes core presentation direction and sends to Lily with imagery/inspiration instructions
4. Reviews the final deck for brand compliance (colors, fonts, logos, tone of voice)
5. Approves or flags corrections before the deck goes to the owner

What she does NOT do: Create decks from scratch, design slides, source all imagery. Her role should be approval, not production.

Tools Used

• PowerPoint — current standard (dislikes it; wants to move to modern tools but IT/board mandates Microsoft)
• External press drive — organized asset library with fonts, logos, property photos/renders per brand (created for press agencies); exists but BD doesn't use it
• Email / WhatsApp — all communication
• No dedicated approval or review workflow tool

Outputs & Handoffs

• Brand compliance feedback (verbal/email) to BD or Lily
• Sometimes writes the strategic narrative framing for Lily to execute visually
• In ideal scenario: a final sign-off before proposals are sent to owners

Approvals & Back-and-Forths

• No formal approval gate currently exists for most proposals
• Marina only sees proposals she is explicitly cc'd on or contacted for — which is not all of them
• Sara and Alicia's European proposals: she has zero visibility
• Her proposed governance: - All proposals should pass through her for a final compliance check - Special/bespoke proposals (above a threshold of importance) require formal approval - Routine proposals: approval should be fast and lightweight if templates are followed correctly

Time & Volume

• Receives proposals with no lead time (Thursday → Monday meeting is typical)
• No capacity to create every BD deck — "We are three persons managing 12 brands and 55+ properties"
• Current load is unsustainable: every new BD member (like Gasan) comes to her as the default contact

Pain Points & Frustrations

• "There was some decks given to BD like a free will — which creates problems in marketing because they took those decks and they are changing them — and not always going through us for approval — and mainly the guidelines are not respected: logo, fonts, etc."
• BD uses templates that are months or years out of date without knowing it
• Font problem: brand fonts are not installed on BD's computers, so PowerPoint silently substitutes wrong fonts and no one notices until she reviews it
• Anthony goes directly to Lily for bespoke requests without involving Marina — she finds out after the fact
• "Marina, I have a meeting Monday, I need a proposal" — no brand, no concept, no context. She has to reverse-engineer what's needed before she can start
• BD's decks are being sent to owners with wrong logos, misplaced elements, old brand guidelines: "I have this [collateral] from 2018"
• Has zero visibility over the European BD team's proposals — they don't involve her at all

Observations

• Marina is the brand identity enforcer with no enforcement mechanism — she is responsible for how all 12 brands are represented externally, but has no approval gate, no intake process, and no visibility over most proposals
• The asset library exists but is disconnected from the workflow — fonts, logos, property photos, renders: all organized, vetted, and accessible via an external drive. BD simply doesn't use it. The gap is not the existence of assets but the absence of a system that routes BD through them
• Hard constraints she articulated explicitly: font, logo, colors, core brand narrative, and tone of voice are non-negotiable for any proposal that carries a brand name. Everything else (layout, image style, emphasis) has flexibility
• Cloud 7 brand guidelines are changing — new identity by mid-May 2026, new website by June 19. Automation work involving Cloud 7 templates should be deferred or built to accommodate the rebrand. Start with Kerten and The House
• Her "fast proposal" framing is the most useful product positioning insight in all interviews — "You can respond faster than any competitor. Within 24 hours, an owner already has a proposal. That opens the conversation." She explicitly frames the first-pass automated proposal as a speed-to-conversation tool, not a final deliverable
• Pinterest is acceptable for internal proposals — she confirmed there are no copyright concerns for image usage in BD decks, which stay between Kerten and owners. This validates using Pinterest as an image source in the automation
• The intake questionnaire she proposed maps directly to system design — brand selection, project type (hotel/residence/service apartment), location, style/mood, number of rooms, financial slide requirement. This is the minimum viable input for automated proposal generation
• Two-tier proposal model she described: (1) fast automated deck for first-touch (brand-compliant, sent within 24 hours), (2) bespoke curated proposal when negotiations progress. This is a clear product architecture recommendation from a Kerten insider

Vela Internal Check-in — April 16, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

Post-interview debrief after sessions with Alicia, Sara, Lily, Marina, and Karolina. Key disconnects identified. Shaheer presents three-component system vision. Decision to show the client their current chaotic process before proposing the future state.

Key Topics

Process disconnects identified:

• Alicia and Sara said there are no brand guidelines or templates; Lily said guidelines exist but templates don't — both are partially true
• Karolina said she must be involved in all financial proposals; Alicia and Sara never mentioned her — they bypass her due to time pressure
• These disconnects reflect organic growth without formal process design

Karolina's sign-off:

• The CEO/COO directed that Karolina should be involved from the start; the BD team resists this
• Vela's proposed solution: automated notification to Karolina when a new deal is initiated, rather than mandatory blocking approval
• This is achievable without a full workflow system — just email routing

Shaheer's three-component system vision:

1. Creative/narrative — templates, images, mood boards; AI generates based on concept direction
2. Technical/hard data — commercial terms, financial projections; separate automated track
3. Process flow — routing, notifications, sign-off coordination; BPA layer

Standardized form as entry point:

• Shaheer proposes a SharePoint form replacing Anthony's initiation emails
• Form captures: concept/vision direction, deal size, location, owner type
• Form triggers: (1) initial draft generation, (2) notification to Karolina
• Theo agrees conceptually; wants it to feel as lightweight as an email

Key design principle (Shaheer): "The new processes must be cognitively less demanding than what they're currently doing — otherwise adoption fails."

Template debate:

• Shaheer: don't ask them to create fixed templates; they won't stick to them; generate bespoke structures from brand guidelines instead
• Theo clarified: "template" = PowerPoint with brand background, logo, fonts — not the proposal structure

API cost concern:

• Shaheer flagged that generative functions (image sourcing, text generation) will have substantial API costs
• Theo to discuss with the client: "you wanted an automated tool, you got it — this doesn't come for free"
• Decision: solve the problem first, optimize costs later

Decisions Made

• Show the client their current messy process first, then propose the future state
• Form-based initiation is the v1 approach; transcript-to-brief is a future stage
• "Template" = branding elements only; proposal structure is dynamically generated
• Maria to draft full process map by end of week
• Shaheer to map all data sources and identify gaps by Friday

Observations

• The Karolina bypass problem directly informed the financial agent design — the solution must include a structured touchpoint for her, not rely on BD's goodwill
• The cognitive load principle is now a hard design requirement — every step added must feel easier than what was there before
• Marina's role is confirmed as compliance gatekeeper, not production — she owns brand identity; Lily produces the visual work

Chief Business Development Officer — Ramin — April 17, 2026

Person

• Name: Ramin (last name not identified in transcript)
• Role: Chief Business Development Officer (CBDO), Kerten Hospitality
• Position in proposal process: Senior oversight — reviews all proposals and financial models before they go to Amin for final sign-off; gives creative direction approval for European region; manages cross-border BD teams
• Additional attendee: Ghassan Noursi (Country Director, newer team member — likely Saudi/Gulf region) — joined the session partway through and provided his own perspective
• Note: Ramin was in-person at the Kerten office; only Vela team was on video. Transcript speech recognition attributed both Ramin's and Maria Haddad's (Vela) voices to "Maria Haddad" — Gemini notes are more reliable than the transcript for this session

Inputs (Ramin — oversight role)

• Receives completed proposal drafts from BD team for review and quality control
• Receives financial models from BD executives (Sara, Alicia) for assumptions review and sign-off
• Manages inbound opportunities routed through regional country directors

Inputs (Ghassan Noursi — production role)

• Receives new project opportunities with often incomplete or unclear information from project owners
• Described receiving old or irrelevant project decks — information quality varies significantly
• Information handoffs between team members result in lost context (missed calls, summaries not shared)

Their Process

Ramin — Review and oversight:

1. Receives drafted proposals — reviews for formatting, typos, headers, footers, logo placement, brand compliance
2. Reviews financial models — scans for logical red flags (e.g., a restaurant opening with 6 covers running at a loss, misaligned ADR vs. market rate)
3. Currently spends ~30 minutes per deck on formatting fixes alone before even reviewing content
4. Coordinates cross-border collaboration — pulls BD executives from other markets (e.g., Alicia helping on India pitch) based on availability and capability
5. Manages access and confidentiality across regions — not all team members should see all project details (e.g., local fee agreements by country)
6. Final proposals go to Amin for ultimate sign-off on high-value deals

Ghassan Noursi — Country Director production:

1. Receives project opportunity — often incomplete; gathers information from multiple sources
2. Decides on concept direction and which internal teams to involve
3. Loops in technical services (Harsha) at least 60% of the time for feasibility, space maximization, back-of-house logistics
4. Involves legal for: NDAs, non-standard agreements, branded residences (franchise agreement review)
5. For questionnaire-type RFPs (e.g., Star Wars project in Saudi Arabia): extensive cross-collaboration to generate non-image content
6. Conducts market research: competitor amenities, demographics, what's standard for property class in that market
7. Applies own judgment to differentiate — prefers internal capability focus over mirroring competition

Tools Used

• Claude (personal $20 subscription) — Ramin has tested it, connected to PowerPoint and Excel; not yet connected to Outlook (awaiting enterprise approval)
• PowerPoint — primary proposal format; macro/master slide functionality underutilized
• Excel financial model — basic P&L template (not complex; an intern can populate it); primary use case for AI is benchmarking ratio population (manning costs, F&B averages by region)
• CoStar/STR — referenced for identifying contract renewal timing for proactive takeover pitches
• ChatGPT — used for sharpening language; prompted to "grill" content before submission
• Google Meets / Teams — remote collaboration

Outputs & Handoffs

• Ramin: reviewed and approved proposal decks → passed to Amin or sent to owner/consultant
• Ramin: approved financial model assumptions → BD team updates the model
• Ghassan: completed proposals → reviewed by Ramin, then Amin

Approvals & Back-and-Forths

• Ramin reviews financial models and presentations; Amin is the final approver
• Ramin's goal: reduce his review to ~15 minutes by getting a "3–4 key indicators" summary rather than tab-by-tab manual review
• Current bottleneck: Ramin spending 30 minutes per deck on formatting — "easily avoidable" but currently manual
• Multiple stakeholders (Lily, Karolina, Harsha, legal) pulled in on an ad hoc basis without a defined trigger or sequencing — "the more cooks you bring in, we're not going to cook"

Time & Volume

• Ramin review time per proposal: currently too long — targeting 15 minutes per review
• Ghassan: 80% of his time dedicated to proposal creation; currently managing 9 active proposals
• Opportunity cost: Ghassan cannot pursue a new deal in Ivory Coast because of existing proposal backlog — "another week will lose the deal"

Pain Points & Frustrations (Ramin)

• "I'm going tab by tab making sure... this is her formatting, this is wrong headers... it should be automated."
• Financial models: "A restaurant running at 125% loss. Why should you keep it? If we can get it to raise a flag and say 'here's the five red flags in your model, go straight to this.'"
• Language quality: generic, overwritten text is a recurring problem — wants proposals trained on Kerten's specific voice (not standard AI-sounding output)
• Formatting standards not enforced: logo in wrong position, fonts substituted, headers from wrong section — despite guidelines existing
• Too many stakeholder dependencies that all converge at the last minute

Pain Points & Frustrations (Ghassan)

• "We have 9 proposals requiring work. This limits capacity to pursue new deals."
• Proposals are a bottleneck to deal flow — "the goal is to have proposals quickly ready to enable immediate follow-up and faster deal closing"
• Information from owners is often incomplete, stale, or irrelevant — hard to start without a clear project picture
• Research for proposals (competitor amenities, demographics, market standards) is manual and time-consuming — takes time away from ideation
• Currently has no systematic way to capture/share post-meeting notes — information lost between calls

Observations

• Ramin is the only named CBDO across all interviews — he signs off on European financials (confirmed by Sara: "I usually do it with Ramen") and manages cross-border BD. His review bottleneck is a system-level problem affecting every BD executive
• The "central command of the deal" vision — Ramin's aspiration: a centralized system containing the financial model, images, content, and all relevant deal information, with role-based access controls. This is the most senior articulation of the platform vision
• Three proposal tiers explicitly named — (1) highly bespoke breakthrough, (2) 2–3 day standard proposals, (3) "bottle to the sea" automated outputs. Ramin confirmed this framing; Theo proposed it. This is a system design requirement
• Ramin's automation wish is formatting and language QC — not creative strategy. He already knows what a good proposal looks like; he just shouldn't spend time fixing double spaces and wrong footers
• Ghassan Noursi represents the new-joiner perspective — 80% of time on proposals, 9 active at once, no capacity for new business. This is the scaling problem Kerten faces as they grow
• Proactive takeover pitch use case — Ramin described using CoStar contract dates to identify hotels whose 15–20 year contracts are expiring, then building a targeted pitch using scraped competitor reviews to highlight known problems. This is a concrete intelligence hub use case with clear data sources
• Review aggregation with evidence — Ramin specifically wants AI-scraped review summaries to include source proof (screenshots, links) not just conclusions. He'll trust the analysis but needs the ability to verify before presenting to owners
• The transcript labeling problem is confirmed — Shaheer acknowledged mid-call that the transcript would be unreliable because both Ramin and Maria (Vela) were sharing the same microphone. The Gemini summary/notes section is the authoritative record for this session

Vela Internal Check-in — April 17, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

End-of-week synthesis. Process is "clearly not defined at all." Team aligns on automation strategy: Claude-native generative workflow rather than fixed templates. Role-based workflows per persona. Technical deep-dive scheduled for Monday.

Key Topics

Process mapping status:

• Process is confirmed as underdefined — no mandatory steps, no sequencing
• Mandatory vs. optional steps to be shown with solid vs. dotted lines in the process map
• Karolina is looped in only because BD lacks her specific market data skills — not because of a formal rule
• Marina's asset library exists but BD doesn't use it — gap is routing, not assets

Automation strategy shift:

• Earlier hypothesis: templated proposals with 2–4 archetypes
• New position: custom generative workflow — Claude reads the brief, follows brand guidelines, generates a bespoke proposal structure every time
• "Vanilla" content (case studies, team, community experience) is easiest to automate and accounts for significant time savings
• Complex custom image work is hardest — AI-generated images require iterative prompting; not practical in v1

Shaheer's role-based workflow design:

• One or two workflows per persona: - Anthony: vision/narrative capture - BD executives (Sara/Alicia/Ghassan): proposal assembly and execution - Karolina: financial data validation - Hassan/Ghassan: country director inputs
• Tool is not a "one-shot magic wand" — requires users to engage, challenge, and direct it

Three workflow types for proposal foundation:

1. Creative/concept workflow
2. Financial/market data workflow (CoStar → ADR, occupancy)
3. Project fundamentals workflow (location, size, brand)

Claude as the required tool:

• Theo is firm: solution must be built on Claude; no contingency plan
• Two Claude instances needed: (1) general company-wide Claude subscription for all employees; (2) dedicated paid API subscription for the proposal automation system

Feasibility concern:

• Theo warns against overpromising — AI has a "jagged frontier"; it can miss obvious things despite being powerful
• Shaheer to prepare a visual diagram of exact components, inputs, and outputs before presenting to client
• 1.5-hour technical deep-dive scheduled for Monday at 5pm

Decisions Made

• Custom generative workflow confirmed over templated approach
• Role-based workflow design agreed upon
• Maria to finalize process map (solid = mandatory, dotted = optional)
• Shaheer to build diagram of full technical solution for Monday
• Maria to email Muhammad about needing to speak with Harsha

Observations

• The shift from templated to generative is the most important design decision of the engagement — it changes the build scope significantly and aligns with Kerten's "no cookie-cutter" philosophy
• Role-based workflows prevent the cognitive overload of a single catch-all interface — Anthony's interface is different from Sara's, which is different from Karolina's
• The feasibility checkpoint (Monday) is critical — Theo's "jagged frontier" caution is appropriate; the team must confirm what's actually buildable before committing to the client

Vela Internal Check-in — April 20, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

Start of week 2. Team consolidates findings, confirms Claude recommendation, and sets the week's two objectives: (1) finalize the process map and (2) design the technical solution. Client decision on Claude is the critical dependency.

Key Topics

AI market discussion:

• Claude's design capabilities are now advanced enough to displace some marketing roles (Shaheer's view)
• Theo's counter: professional-grade robust outputs still require expert judgment; AI does 80%, experts do the remaining 20%
• Two-year horizon as the practical planning window for role stability

Claude decision as priority:

• The weekly 4pm BD meeting is the moment to push for Claude approval
• Mia (client contact on Stream 3) was evaluating hospitality competitors' AI tool choices
• Theo's position: don't wait for competitor data — Vela has enough justification for Claude already
• Two Claude needs: (1) enterprise subscription for all employees; (2) API/paid subscription for the proposal system

BD process improvement objective:

• Primary goal: free up BD time for creative thinking and differentiation
• The system wins proposals not by producing more — but by producing better
• Two contradictory client objectives identified: (1) high quality and differentiation, (2) mass production for "flooding the market" with teaser proposals
• Solution must handle both — same foundational system, different output modes

Shaheer's week 2 missions:

1. Secure all required data and proposals via SharePoint for analysis
2. Propose the technical solution design for the 5-week build

Survey amendment:

• Maria to update the existing BD survey to quantify time spent on key activities
• This will set measurable targets as requested by Cathal O'Shea

Weekly status tracker:

• Maria prepared a 3-slide update deck for the 4pm client meeting
• Format: progress per activity, next steps — remove "potential roadblocks" section
• Must include Stream 3 activities alongside Stream 1

Decisions Made

• Vela to recommend Claude regardless of competitor benchmark data — justification is strong enough
• Shaheer leads technical solution design this week
• Maria leads process map finalization this week
• Survey amendment to quantify time savings targets

Observations

• The "quality vs. quantity" tension is real and was later confirmed by Muhammad in the weekly review — the system must serve both use cases but not be designed for quantity at the expense of quality
• The 5-week build timeline starts from Claude approval — the dependency is clear and the urgency is real
• The survey data gap (time quantification) is a stakeholder management requirement from Cathal — it's not just internal analysis; it's client reporting

BD AI System — Weekly Progress Review — April 20, 2026

Attendees

• Muhammad Yacoubi — Senior Director BD, Kerten (Stream 1 champion)
• Cathal O'Shea — Owner's representative (Michael O'Shea's father's perspective)
• Theo Breward, Maria Haddad, Shaheer Ahmed — Vela Advisory

Key Topics Discussed

Process insights from week 1 interviews:

• No rigid process exists — de facto workflow only; people get involved based on relationships and availability
• Lily called in for image-finding, not just creative direction — organic role blur
• Three proposal archetypes confirmed: (1) complex/bespoke, (2) standard/consultant-driven, (3) automatic/teaser
• Proposal creation activities (design, finance, engineering) run in parallel, not sequentially

BD workflow phases agreed:

1. Initiation — senior person (Anthony, Muhammad, Ramin) defines concept after coffee chat / inbound / market trigger
2. Proposal Setup — handed to BD executive (Sara, Alicia, Ghassan) to structure
3. Proposal Creation — parallel tracks: concept/visuals, finance/market data, optional engineering/legal input

Quality vs. volume debate:

• Muhammad strongly emphasized: quality and differentiation are the priority, even for "automated" teasers
• The primary goal is not more proposals — it's freeing up time for creative thinking and scouting
• BD time currently: ~75–80% on proposal creation; target is to reduce this significantly

Intelligence hub definition:

• Distinct from CRM: CRM = contact management and reminders (calendar-based); Intelligence Hub = external web intelligence that surfaces opportunities and alerts
• Intelligence Hub must connect to CRM for context (to know what's already in pipeline, what contacts to avoid re-approaching)
• Muhammad wants: 30-minute interviews with Ramin, Marlo, Michael, Sara, and Aditya to scope the intelligence hub

CRM project:

• A parallel CRM project exists (led by Douglas / Broad Vision IT) — scope unknown
• Intelligence Hub must integrate with or work around it
• Muhammad to investigate CRM scope with Douglas

Technical ownership:

• Cathal O'Shea raised concern: solution must be "ownable" by Kerten long-term, not locked to Vela
• Broad Vision (Douglas) manages most IT — a meeting with them is needed before finalizing tech stack

Decisions Made

• Three proposal archetypes confirmed; no separate processes per archetype from a system standpoint
• Intelligence hub scoping interviews to be scheduled by Muhammad with 5 additional stakeholders
• Muhammad to follow up with Shivali (India BD — still missing from interviews)
• Broad Vision meeting to be scheduled by end of week
• Muhammad to investigate CRM project scope with Douglas

Observations

• The 75–80% time-on-proposals figure is the key KPI — if the system can reduce this to 40%, it frees significant capacity for scouting and relationship management
• Muhammad's "quality over volume" position directly aligns with the Full Curated Proposal tier; the Fast Proposal is a means to open conversations, not replace the bespoke work
• Intelligence Hub vs. CRM distinction is now clear: CRM = relationship reminders; Hub = external market intelligence and opportunity detection
• Cathal O'Shea's "ownable" requirement is a design constraint: the solution cannot be a black box that only Vela can maintain
• Shivali (India) is the outstanding interview gap — her perspective on the India market is critical for the intelligence hub lead sourcing design
• The parallel CRM project is an integration risk — if Broad Vision is building a CRM simultaneously, the intelligence hub must be designed to connect to it rather than duplicate it

Intelligence Hub — Michael O'Shea — Session 2 — April 21, 2026

Person

• Name: Michael O'Shea (referred to as "mos" in transcript)
• Role: Owner / strategic advisor (Cathal O'Shea's father; the primary financial backer of Kerten Hospitality)
• Note: Michael is not a "digital guy" — works with pen and paper; his input is strategic and experiential, not operational

Lead Sourcing Strategy

Target property profile:

• Independent hotels, 50–100 rooms per country
• Planning permissions (50+ keys threshold) as a lead signal — when a planning application is approved for a new hotel of that size, it's a prospecting trigger

Geographic priorities (in order):

• Morocco, Egypt, Greece, Spain, Italy, France, Poland, Scandinavia, India (with tighter criteria)

Countries to exclude:

• Germany — market structure is leases, not management contracts; Kerten's model doesn't fit
• Albania — too underdeveloped
• Malta — too small

India-specific constraint:

• ~99,000 independent hotels — a blanket scan is impractical
• Needs tighter targeting criteria (Tier 2/3, specific room count range)

His Approach

Volume and sequencing:

• Do not blast all targets at once — do ~100 at a time per country
• Prioritize markets where Kerten already has a footprint or strong broker network

Intermediaries:

• Architects and interior designers are too vague a category for AI targeting — relationship-dependent, not systematically addressable
• Brokers and consultants are the more addressable category

Competitive advantage:

• The window to use AI-based lead sourcing as a competitive advantage is short — once competitors adopt similar tools, the edge disappears
• Speed of implementation matters

Observations

• The 50-room / planning permission threshold is a concrete targeting rule — actionable, filterable, and maps directly to data sources like local planning authority databases
• "Don't blast all at once" is a sequencing discipline — 100 at a time per country maintains quality of outreach and allows capacity management
• Germany exclusion is a system-level constraint — the intelligence hub should filter out German targets by default, as management contracts are not the norm there
• India requires a separate targeting model — the 99,000 independent hotel figure makes it its own design challenge; Tier 2/3 with room count filters is the right aperture
• Competitive window is explicitly short — Michael's urgency framing should inform Vela's build timeline; speed matters more than perfection
• Michael is the highest-authority voice on what markets to prioritize — his geographic list should be treated as a hard design input, not a suggestion

Intelligence Hub — Muhammad Yacoubi — Session 1 — April 21, 2026

Person

• Name: Muhammad Yacoubi
• Role: Senior Director BD, Kerten Hospitality; Morocco/MENA focus; Stream 1 BD champion
• Position in intelligence hub: Primary articulator of the sourcing strategy; manages the highest-value lead relationships

Lead Channels (Three Types)

1. Brokers / Consultants

• Receive briefing packs (RFPs) and respond on behalf of property owners
• Most structured channel; leads come with project details already attached
• Kerten must be on their approved lists

2. Owners / Developers

• Direct inbound from property owners, often after Kerten is recommended by existing clients or intermediaries
• Higher quality leads; direct relationship; more trust

3. Intermediaries / Partners

• Architects, interior designers, joint venture partners, government agencies
• Less predictable; harder to systematize; relationship-dependent

His Process

Current approach — opportunistic, not systematic:

• Monitors news manually (no system); LinkedIn browsing (~5 hrs/week total across the team)
• Coffee chats are the highest-value lead source — relationships are the primary deal driver
• Reacts to inbound from brokers when Kerten is on their list
• No structured prospecting; no weekly scan cadence

Preferred intelligence system design:

• Two-level search system: (1) curate a broker contact list → (2) run regular searches on a subset of them
• Weekly digest format — not real-time alerts; a weekly summary of relevant news and leads is sufficient
• Lead scoring / scorecard — needs a way to prioritize which leads to act on vs. ignore
• Serial owner tracking — prefers to target owners who have done multiple hotels; more predictable deal behavior
• HMA renewal timing — 20-year contracts expiring are a strong signal; owners looking for new operators

Due diligence requirement:

• Wants basic owner background check as part of the intelligence process (money laundering risk is real)

Tools Used

• LinkedIn — browsing for market intelligence (~5 hrs/week across team)
• CoStar newsletter — daily email; useful for market context
• Email / WhatsApp — all communication; no CRM in use

Outputs & Handoffs

• Qualified leads → passed to relevant BD executive for proposal initiation
• High-value leads → Muhammad stays involved or hands to Ramin for strategic direction

Pain Points & Frustrations

• No systematic way to stay on top of broker activity across all geographies
• Most good leads come from relationships, not research — hard to replicate at scale
• No shared lead tracking system; information lives in individuals' heads and email inboxes
• CRM project is in progress (via Broad Vision/Douglas) but scope is unclear

Observations

• Opportunistic sourcing is not a failure — it's a strategic choice — Muhammad explicitly prefers "opportunistic over comprehensive scan" because quality of relationship matters more than quantity of leads
• The weekly digest is the right format — not a dashboard or real-time feed; just a curated, actionable summary once a week
• Serial owner preference is a smart filter — owners who have done multiple projects are faster to convert and more predictable
• HMA renewal as a trigger is a confirmed use case — CoStar tracks operator contract dates; 15–20 year contracts expiring = proactive pitch opportunity (also mentioned by 2026-04-17 Ramin Chief Business Development Officer)
• Lead scoring is an explicit requirement — the system must not just surface leads but prioritize them
• Due diligence on owners is a compliance requirement, not a nice-to-have — money laundering in hospitality investment is a known risk

Group General Counsel — Tara Marlow — April 21, 2026

Person

• Name: Tara Marlow
• Role: Group General Counsel, Kerten Hospitality
• Position in proposal process: Legal enters the process after the concept proposal is approved — first touchpoint is drafting NDAs, then Heads of Terms, then the full Hotel Management Agreement (HMA)
• Handoff point: BD owns the owner relationship until the HMA is signed; Legal (Tara) then hands over to Operations

Inputs

• NDA requests: approximately 3 per day, all third-party templates (Kerten does not generate them), reviewed and signed
• Commercial Terms document from BD — this is Tara's input for drafting Heads of Terms
• Signed HMA triggers handoff to Operations team

Her Process

Document Chain (in order):

1. NDA — signed before any sensitive information is shared; all third-party NDAs, reviewed manually
2. Concept Proposal — BD creates and delivers; Legal has no formal role but should add a non-binding disclaimer
3. Commercial Terms — BD creates using a legal template; contains target/minimum/ask fee scenarios
4. Heads of Terms — Tara drafts; auto-transfers key fields from Commercial Terms (saves ~20 min/doc)
5. Hotel Management Agreement (HMA) — full 75-page contract; Tara drafts; currently takes a full day, targeting 2 hours with AI assistance

Legal disclaimer requirements:

• All proposals need a confidentiality/non-binding disclaimer on cover or footer
• Five-year financial forecasts require a legal disclaimer at the bottom of the financial slide

Tools Used

• Word / standard legal drafting tools — primary document drafting
• AI (experimental) — explored for HMA drafting; 75-page → 2-hour target with AI
• Email — all communication

Outputs & Handoffs

• Executed NDAs — returned to requesting party
• Heads of Terms — drafted from Commercial Terms, sent to owner for negotiation
• HMA — full management contract (~75 pages), signed before hotel opens
• Post-HMA handoff: Tara exits, Operations (Mina's team) takes over

Approvals & Back-and-Forths

• NDAs: straightforward review, typically no major back-and-forth
• Heads of Terms: negotiation round with owner
• HMA: most complex, multiple rounds; commercial terms from BD must be consistent with what's in the HMA

Time & Volume

• NDAs: ~3 per day; high volume, mostly routine
• Heads of Terms: ~20 minutes saved per document if auto-populated from Commercial Terms
• HMA: currently 1 full day per agreement; AI target is 2 hours
• BD holds the owner relationship until HMA is signed — Legal is a downstream step, not a concurrent one for most proposals

Pain Points & Frustrations

• Proposals go to owners without a non-binding disclaimer — legal exposure if misread as a binding commitment
• Financial forecasts sent without required legal disclaimer on the slide
• Commercial Terms sometimes arrive at Heads of Terms stage with inconsistencies that require resolution
• No formal trigger for Legal involvement — Tara finds out reactively

Observations

• Three-stage document chain is the clearest articulation of the legal workflow: NDA → Heads of Terms → HMA. Each document has a distinct trigger and distinct owner
• BD owns the relationship until HMA is signed — this is the clearest boundary between BD and Operations/Legal. Post-HMA, Tara and Mina's team take over
• Disclaimer automation is a low-effort, high-protection quick win — adding a standard non-binding disclaimer to all proposals does not require legal review each time; it can be templated
• HMA automation is the biggest time-saving opportunity in Legal — a 75-page contract going from 1 day to 2 hours is a 75%+ reduction in drafting time. This is achievable with well-structured AI prompting and template population
• Auto-transfer from Commercial Terms → Heads of Terms is already partially in place (saves ~20 min); full automation of the data handoff is the logical next step
• Tara is the only legal resource — there is no legal team; all contract work sits with one person

Vela Internal Check-in — April 21, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

Mid-week check-in with multiple client meetings running today (Tara, Muhammad, Michael). Key alignment: all proposal archetypes follow the same technical process. Theo demos Claude Design output. Voice notes proposed as system design accelerator.

Key Topics

Survey structure:

• New survey needed (not just updating the old one) — needs more granularity on time spent
• Must capture: average time for basic proposal, time for extreme/complex proposal
• Format: email-style questionnaire (not Google Form) for time data; Google Form for formal distribution after client approval

Upcoming stakeholder meetings:

• Tara (legal) — scheduled
• Muhammad / Michael O'Shea (Intelligence Hub sessions) — scheduled
• Harsha (technical services) — confirmed for Friday 11am
• Ramin (Intelligence Hub lead sourcing) — to be scheduled for Thursday 11am DXB time

System archetypes — unified process confirmed:

• Shaheer: from a technical standpoint, all proposal archetypes (simple, standard, complex) go through the same system process
• The system asks the same questions, generates a brief, generates an outline, generates a PowerPoint — everything after that is human editing
• The difference between archetypes is the amount of human iteration, not a different technical path
• Theo confirmed: "There is only one process, no matter what the archetype is"

Claude Design demo (Theo):

• Theo plugged the team's conversation transcripts into Claude Design
• Output: full AI system flow with identified agents (research, creative, financial, imagery), a mockup user conversation, and a structured JSON output of the brief
• Even proposed CoStar data acquisition and financial inference
• Limitation: Claude Design's visual deck output (from an article) was unusable — bad layout, tiny font, overlapping elements
• *"Generating PowerPoint is f***ing impossible with AI"* — sets accurate expectations
• AI markers in text: M-dashes and certain capitalization patterns signal AI-generated content; must be removed before proposals go to owners

Voice notes for system design:

• Theo proposes: record a 10-minute audio note dictating vision and decision points
• Feed transcript to Claude Design to generate system flow
• Shaheer strongly supports — significantly speeds up design documentation

Expectations management:

• Theo flags that stakeholders (Sara, Alicia) have unrealistic expectations — they expect a fully autonomous, self-improving AI
• The system is not a magic wand; it requires users to engage and direct it
• Future evaluation methods: conversation-based testing, pure knowledge testing, or "how well people instruct AI" (not the quality of the AI output itself)

Decisions Made

• One unified process for all archetypes — no separate technical paths
• Maria to work on master flow + four departmental deep dives today
• Theo to record 10-minute vision audio note for system design
• Ramin intelligence hub session scheduled for Thursday 11am
• Harsha session confirmed Friday 11am

Observations

• The unified process decision simplifies the build significantly — there is no "three different systems"; there is one system that handles all proposal types
• Claude Design's deck output failure reinforces the python-pptx decision — AI cannot currently produce professional PowerPoint output directly; a coded assembly approach is necessary
• The voice note workflow is itself a demonstration of the product concept — Anthony dictating a vision into an audio note that feeds the system
• Expectation management is a project risk — if stakeholders expect full automation and get a tool that requires active direction, satisfaction will suffer even if the tool works

India Country Partner — Aditya Tripathi — April 22, 2026

Person

• Name: Aditya Tripathi
• Role: India Country Partner, Kerten Hospitality
• Background: New to hospitality (3 months in role); India market only 3–4 months active
• Note: Shivali is the more experienced India BD colleague — Aditya is newer and still learning the market

Inputs

• Personal contacts and professional network — primary lead source
• "Finders" (middlemen/brokers): individuals in the hospitality space who connect operators with property owners
• Excel databases (purchased cheaply, often unreliable) cross-referenced with MakeMyTrip to verify hotel existence and positioning
• Broad direction from Ramin — who was in India during the engagement ramp-up

His Process

Step 1 — Lead Identification

• Personal outreach via existing contacts
• Engages finders who surface leads from their own networks
• Cross-references cheap Excel databases with MakeMyTrip listings to verify hotel viability

Step 2 — Market Focus

• Focus on Tier 2 and Tier 3 cities (not major metros)
• Focus on family-run hotels — owners who are open to bringing in an operator

Step 3 — Proposal

• For large proposals (e.g. the India multi-brand proposal): Alicia prepared the deck
• Aditya's role is primarily relationship management and market sourcing, not proposal creation

Tools Used

• MakeMyTrip — verification of hotels in target markets
• Excel databases — purchased lead lists (low quality; require manual cross-referencing)
• Email / WhatsApp — all communication

Outputs & Handoffs

• Qualified leads passed to BD team for proposal creation
• Relationship management with local owners and finders

Approvals & Back-and-Forths

• Ramin oversees India strategy; was physically present during early market activation
• Large proposals coordinated centrally (Alicia prepared the India multi-brand deck)

Time & Volume

• Market very early stage (3–4 months active)
• Volume of proposals is low — still in lead identification and relationship-building phase

Pain Points & Frustrations

• India market has ~99,000 independent hotels — no practical way to systematically approach all of them
• Lead databases are cheap but unreliable — require extensive manual validation
• India contact and context not yet well captured in any shared system
• Distance from headquarters means less visibility on what proposals are being prepared centrally

Observations

• India requires tighter targeting criteria — as noted by Michael O'Shea in the Intelligence Hub Session 2, the 99,000 independent hotels figure makes a blanket scan impractical; focus on Tier 2/3 cities and family-run hotels is the right aperture
• Finders are the primary lead channel — this mirrors the broker/consultant model used in Europe, but with less formal structure
• Aditya represents the newer-joiner profile — similar to Ghassan Noursi; market-new, relationship-dependent, not yet embedded in the proposal creation workflow
• The India multi-brand proposal was Alicia's work — illustrating that large regional proposals are centrally produced, even for markets managed locally
• Shivali is the more experienced India BD person — Shivali's interview was flagged as outstanding in the weekly review and represents a gap in the knowledge base

Intelligence Hub — Sara Granieri — April 22, 2026

Person

• Name: Sara Granieri
• Role: Business Development Executive, Kerten Hospitality (European markets)
• Session focus: How Sara currently identifies and tracks leads — her intelligence sources, tools, and the informal CRM substitute she uses

Intelligence Sources

1. CoStar daily newsletter

• Receives daily email digest from CoStar
• Contains market news, transaction updates, and operator movement
• Free subscription (separate from the paid CoStar data platform)

2. Pambiano (Italian market only)

• Italian-language industry publication
• Only relevant for Sara's Italian market focus

3. LinkedIn (~5 hrs/week across the BD team)

• Used for monitoring developer and owner activity
• No systematic process; browsing and following relevant profiles

4. CoStar Database (downloadable Excel)

• 150,000+ rows of all hotels registered on CoStar
• Filterable by: country, owner, key count, independence status
• Only CoStar subscribers are in it — misses many boutique/independent properties not registered
• Karolina manages all CoStar logins

Internal CRM Substitute: EU Contacts Excel

• An internal Excel file tracking companies and contacts across European markets
• Last updated 3 months ago when Felix (previous team member) left
• Functions as an informal CRM — not connected to any system; manually maintained
• Sara and Alicia are the primary users

Lead Disqualification Criteria (her mental filters)

• Owner-operated (no management contract opportunity)
• Lease agreements (not Kerten's model)
• Properties with >400 rooms in Europe (too large for Kerten's typical mandate)
• Properties with <10 rooms (too small)
• No F&B or spa (doesn't fit Kerten's lifestyle brand positioning)

Reality of Lead Sources

• Actual successful leads from research are rare
• Most real deals come from networking events and coffee chats — relationship-driven
• Research confirms the lead quality; it rarely generates the initial connection

Pain Points & Frustrations

• EU Contacts Excel is out of date since Felix left — no ownership of maintenance
• CoStar database misses a significant portion of independent hotels (not all register)
• No structured way to track which contacts have been approached and what the status is
• LinkedIn monitoring is time-consuming and produces low signal

Observations

• The 150,000-row CoStar Excel is the most systematic lead list available — filterable, comprehensive for CoStar subscribers, but has the boutique/independent blind spot
• EU Contacts Excel = informal CRM — this is the actual relationship-tracking tool Sara uses; its degradation since Felix left is a process fragility
• Lead disqualification criteria are explicit and usable — these can be directly encoded as filters in the intelligence hub (owner-operated, lease, >400 rooms, <10 rooms, no F&B/spa = exclude)
• Networking events generate leads; research validates them — the intelligence hub should be designed to support validation and preparation, not as a replacement for the relationship-building channel
• CoStar login centralization under Karolina is an access control point — any system that pulls CoStar data automatically must be authorized through Karolina's account setup
• Felix's departure caused an immediate CRM gap — this is a recurring risk pattern: knowledge and data concentrated in individuals, not systems

Technical Workflow Design Session — Shaheer + Theo — April 22, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Theo Breward — Managing Director, Vela Advisory

System Architecture

Entry point: Brief / Research stage in Claude Code

• Anthony (or senior BD) opens a Claude session and talks through the deal
• Two built-in skills: 1. /market-research — triggers market data gathering (news APIs, web search, LinkedIn scrapers, Booking.com/hotel reviews, Clay/Apollo for contacts, CoStar API) 2. /submit-brief — synthesizes the conversation into a structured direction document (markdown file)

Four-agent system:

1. Orchestrator — receives the direction document; routes tasks to specialist agents
2. Outline Agent — generates chapter list and slide titles (not copy); BD team reviews and approves this view; can add/remove chapters and slides but cannot reprompt individual slides
3. Financial Agent — pulls CoStar data → auto-populates Excel template → surfaces assumptions for Karolina review → generates financial slide on approval
4. Assembly Agent — python-pptx; receives approved outline + copy + images; assembles the PowerPoint file

Image sourcing:

• Pinterest API called per-slide with thematic queries based on the brief
• Images pulled and surfaced for BD review; not auto-inserted without human check

Data sources:

• News APIs, web search, LinkedIn scrapers
• Booking.com / hotel review scraping
• Clay / Apollo for contact enrichment
• CoStar API (pending confirmation — three-avenue approach: third-party scrapers, CoStar support, Karten login credentials)

Key Design Decisions

Outline is the human checkpoint:

• BD team sees chapters + slide titles only, not generated copy
• Can restructure but cannot re-prompt individual slides (to prevent scope creep and inconsistency)

Financial validation step:

• Tool generates Excel output from CoStar data
• Human (Karolina or BD) validates assumptions before slide generation
• Option for user to upload their own revised Excel if they prefer manual overrides

Template definition:

• "Template" = PowerPoint file with brand background, logo, fonts, color palette — not the proposal structure
• Proposal structure is dynamically generated per brief, not templated

Theo's Key Insight

*"Generating PowerPoint is f***ing impossible with AI"* — expectation-setting: the Assembly Agent (python-pptx) will produce a structured, brand-compliant deck, but pixel-perfect creative design is a human task. python-pptx gives precise control; it does not give creative output.

UI Mockup Concept

• Chapter tree on the left panel
• Slide detail view on the right panel
• Comment/annotation system for BD review
• Approve / flag / edit workflow built in

Timeline

• 5–6 week build from approval
• Dependency: Claude enterprise access approval from Mina/Aman

Observations

• The outline-only review stage is the critical UX decision — showing BD the full draft before they've approved the structure creates confusion and rework; chapters + titles first is the right gate
• python-pptx is deterministic but not creative — it will produce a correctly formatted deck, not a visually stunning one; this aligns with the "brand compliance first, creativity second" philosophy
• CoStar API uncertainty is the biggest data dependency risk — three parallel avenues are being pursued simultaneously; if all fail, Lighthouse + Karolina manual input is the fallback
• Pinterest API per-slide is the image-sourcing approach — thematic queries per slide type (lobby, F&B, rooms, etc.) will produce relevant imagery without requiring a pre-built image library
• The direction document is the only handoff between Anthony and the system — this document must be comprehensive enough to drive all downstream agents without further human input
• Clay/Apollo integration enables contact enrichment alongside market intelligence — overlaps with the Intelligence Hub scope

Vela Internal Check-in — April 22, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

Mid-week check-in. Stream 3 awaiting client approval. Stream 1 process flows nearly finalized. Key focus: CoStar API strategy, missing brand assets, and financial validation step design.

Key Topics

Stream 3 status:

• Excel, recommendation deck, and survey all shared with client
• Ball is in the client's court — Maria to send follow-up email end of week
• Theo to WhatsApp Mina if no response
• Survey to go live only after client approval

Stream 1 process flows:

• Five processes nearing completion: (1) master hybrid view, (2) Anthony/concept track, (3) visuals/Lily track, (4) finance track, (5) one more TBD
• Finance track has grey areas — Karolina's discussions were future-state focused, not current-state
• Karolina primarily involved for smaller markets or when CoStar data is unavailable; not mandatory for all proposals

CoStar API strategy — three simultaneous avenues:

1. Third-party platforms that claim to scrape CoStar data
2. Continue following up with CoStar support team directly
3. Request Kerten's CoStar login credentials from Sarah to check developer console access

• Decision: pursue all three in parallel; ask Sarah for credentials during her upcoming session

Brand assets gap:

• Files received from Lily, Marina, and Alicia via SharePoint
• Still waiting: financial projection templates and outputs from Karolina
• Karolina uploaded to "Home link" (wrong SharePoint location) — files located and confirmed
• Missing assets identified by Shaheer: - Logo files (PNG/vector) for Cloud 7, The House, Hosmi - PPTX templates for all three brands - F&B brand information (Nakati, Chudood, etc.) - Cloud 7 hex color codes (not in current guidelines — under revision)
• Action: Shaheer to email Lily and Marina requesting complete asset set

Three primary hospitality brands confirmed:

• Cloud 7, The House, Hosmi (hospitality)
• Remaining brands are F&B: Nakati, Chudood, etc.

Financial projections workflow — validation step:

• Design question: does the financial flow go exclusively through Karolina, or is there a hybrid approach?
• Decision: hybrid approach — tool generates Excel output from CoStar data; human (Karolina or BD) validates assumptions before slide generation
• Option: user can upload their own revised Excel (same structure) for regeneration
• This is a mandatory human checkpoint, not optional

Decisions Made

• Three-avenue CoStar API strategy confirmed
• Shaheer to email Lily and Marina for complete brand asset package
• Financial validation is a mandatory human checkpoint (not optional)
• User upload of revised Excel is an explicit feature requirement
• Technical session with Theo scheduled for 6:30pm today

Observations

• The Cloud 7 asset gap is a build blocker — hex codes are missing and the brand is under revision (new identity by mid-May 2026, per 2026-04-16 Marina Digital Marketing Lead); system should start with The House and Hosmi
• The financial validation step resolves the Karolina bypass problem identified in 2026-04-16 Vela Checkin — instead of blocking or bypassing, a human checkpoint is built into the system flow
• The "Home link" SharePoint confusion is a symptom of the same document governance problem affecting proposals — people don't know where to put things
• Karolina's involvement threshold (smaller markets, no CoStar data) is now defined — this is the trigger condition for routing the financial workflow to her vs. running automatically

Intelligence Hub — Marloes Knippenberg — April 23, 2026

Person

• Name: Marloes Knippenberg
• Role: CEO, Kerten Hospitality (referred to internally as "Marlo")
• Session focus: Lead generation strategy, macro market signals, intelligence hub scope and philosophy
• Note: Marloes is identified in prior sessions as the most influential stakeholder and can override the organisation; she joined this session after Vela had already begun with Muhammad and Theo

Lead Generation Sources (Current Practice)

1. Classic + non-classic conferences

• Standard hospitality conferences (the expected channel)
• Non-classic events where high-net-worth individuals gather: boat shows, Russa's people conference, summer leisure destinations (South of France, Sardinia) — owners with hospitality assets are present but are not primarily there for hospitality

2. Friends-of-friends referrals

• Increasing proportion of leads coming via direct referrals; growing as brand reputation builds

3. OTA scouting (Booking.com / TripAdvisor)

• Looking at 3-star properties in good RevPAR command ranges — not the top tier (they don't need an operator) but the strong mid-tier
• Active work at the time of session: establishing who the owners are of target properties, with attention to owners who hold multi-property portfolios

4. Media and press coverage

• Using four PR agencies simultaneously (unprecedented for Kerten); named media coverage generates direct inbound (e.g. Morocco post with Muhammad's name → direct messages to Muhammad)
• Organic engagement is very high precisely because it has not been templated or paid-for

5. LinkedIn (personal, not corporate)

• High organic engagement and response rate; personal posts outperform corporate Kerten page
• Example: India announcement → "tons of messages" still arriving
• No formal LinkedIn strategy in place; Marketing wants to formalise it — Marloes is cautious about losing the authentic, non-templated character that makes it work

6. Finders (market-specific)

• Finders in different markets; preference for a smaller number of higher-quality finders who have real reach
• Consultants play a supporting role (vouching for Kerten once owner has decided) but are not strong lead-generators themselves; they default to established international brands

Macro Market Signal Framework

Marloes' distinctive contribution: she thinks about market readiness before individual leads. Signals she tracks at a country/region level:

Key insight: By the time classic signals (hotel signing announcements, brand flags) are published, the deal is already closed. Marloes works at the macro level to enter markets before competitors — Egypt is the live example (the team went, came back with many leads; others weren't there yet).

Volume vs. Quality Debate

Marloes' position:

• A list of 1,000 names, even without qualifying them, has value — awareness/warming strategy: people who don't know Kerten exists can't become leads
• Parallel approach: qualify a sub-set (50–100) deeply, while simultaneously warming the broader list through LinkedIn and communications
• This is how Kerten has grown: communications-first, so that when the BD team finally reaches someone, they've already heard of Kerten

Muhammad's framing (stated in the session): identify the right timing (low performance, ownership change, contract approaching) before acting; use softer touchpoints to "pre-warm" the broader pool.

Contrast with Michael O'Shea: wants the 1,000-name dump and mass email blast. Marloes' approach is more considered but aligned with the brand's actual history of how it's grown.

LinkedIn Strategy — Potential Phase 2 Feature

Theo described a gamified LinkedIn platform used at NBCG:

• Marketing dumps content/articles into a platform
• Team members choose what they want to post, customise the text
• "Smart post" function selects optimal posting time based on algorithm
• Points and leaderboard based on engagement

Marloes' reaction: this would work very well for Kerten. Reasons:

• Different team members have different followers and different relevant content
• Allowing text customisation preserves authenticity (rigid templates = nobody reads it)
• Many team members want to post but don't know what to post or didn't see latest press
• Risk of someone posting something wrong is minimal (easily corrected)

Status: flagged as a Phase 2 feature; not in scope for current build but worth capturing.

Decisions & System Implications

Proposal Generation System

• Not discussed; Marloes' session focused entirely on intelligence hub

Intelligence Hub

• Country-by-country configuration is a design requirement — the signals that work in Egypt (ministerial activity, currency, political window) are different from Greece (land clearing, institutional investors, OTA scouting) which are different from India (finders, management agreement shift). The tool must be tunable per market; a single global config will produce noise.
• Macro-first, micro-second architecture: Step 1 = market readiness filter (is this market in the right phase to pursue?); Step 2 = within the active market, apply tactical signals and lead sourcing. This is Marloes' mental model and should inform the tool's approach.
• Conference attendee lists are findable online — AI can aggregate speaker and attendee data from hospitality conference websites; useful pre-event research for Kerten team
• OTA scouting (Booking.com / TripAdvisor) for 3-star mid-tier properties is already a practiced approach — this should be one of the tool's standard scanning modes, alongside land registries
• 1,000-name list has standalone value — even without deep enrichment, a broad name list enables a warming/awareness communications strategy. Building the list and initiating comms can run in parallel with the enrichment effort.
• Cross-language entity matching is a technical challenge — Theo noted that an article about the same developer/property may appear in English, French, and Arabic with different name spellings; the system must resolve these to the same entity
• LinkedIn as a lead tool — LinkedIn done organically (personal, non-templated, named) has generated real inbounds for Kerten; the gamified platform concept is a Phase 2 feature worth scoping

Observations

• Marloes is the most strategic thinker in the intelligence hub sessions — she provides the macro framework that explains why individual signals matter; her Egypt example (went when instinct said "not yet" and came back with many leads) illustrates the cost of waiting for classic signals
• "The consultants don't naturally lean to us" — Marloes confirms that JLL and others default to established brands; Kerten must approach them market-by-market and relationship-by-relationship; the tool cannot rely on consultant referrals as a systematic source
• Kerten's growth has been driven by brand awareness + personal connection, not by systematic lead scanning — this is the most important context for scoping what the intelligence hub is actually for; it supplements a warm, relationship-based model, not replaces it
• Greece is an emerging opportunity — market just opened (land clearing complete), JLL just establishing office, not yet crowded with operators; actionable now
• India was the right call — Marloes confirms Kerten resisted India for 1–2 years but the market has now shifted to management agreements; the macro signals she cited (Aman's push, market movement toward management agreements) were correct leading indicators
• Karten's LinkedIn authenticity is a competitive asset — formalising it risks destroying the quality that makes it work; any AI/automation applied to LinkedIn must preserve personalisation and allow human text customisation

Intelligence Hub — Ramine (Ramin, CBDO) — April 23, 2026

Person

• Name: Ramine (same person as Ramin, CBDO — see 2026-04-17 Ramin Chief Business Development Officer for proposal process details)
• Role: Chief Business Development Officer, Kerten Hospitality
• Session focus: Intelligence hub — contract renewal prediction using CoStar, Booking.com deflag monitoring, outreach strategies, geographic prioritisation
• Context: Ramine had just returned from a full week in Cairo, landing at 3am the morning of the call; his Egypt example is from direct, same-week experience

Core Intelligence Strategy: CoStar Contract Renewal Prediction

Ramine's primary mechanism for proactive outreach — the highest-signal approach he described:

Logic:

• Most branded hotel management contracts are 15–20 years (some 10, some up to 30)
• Renewal negotiations happen approximately 1 year before expiry
• CoStar's participation list includes each hotel's opening date and room count
• By applying: opening year + contract length - 1 year = target year for outreach
• Build a rolling list of hotels entering their renewal window in the next 6–12 months

Example given:

• Anantara Eastern Mangroves opened 2012, 15-year contract → expiry 2027 → approach in 2026 ✓
• The hotel had already deflagged by the time of the session — the strategy would have caught it

What to do with this list:

1. Get owner background via CoStar or additional research
2. Pull competitive set performance (ADR, occupancy, RevPAR) vs. peers from CoStar — is the hotel bottom of its competitive set?
3. Scrape TripAdvisor and Booking.com reviews → aggregate by category (MEP issues, arrival experience, F&B, activities) → identify top 3 recurring complaints
4. Auto-generate a business case pitch: "We can see your hotel is bottom of the competitive set in these areas — here's how we fix it"
5. Approach owner with this prepared intelligence rather than a cold introduction

Ramine's assessment: "We're doing probably 2% of what we could be doing with the CoStar data." The manual effort to build the business case is impossible at scale — this is the perfect AI use case.

Booking.com Name Change Monitoring

Signal: If a hotel changes its name on Booking.com to an unrecognised name, it has almost certainly deflagged (management contract ended unexpectedly).

Why Booking.com specifically:

• Hotels prioritise Booking.com updates; sometimes the name changes on Booking.com before the hotel's own website
• Planned rebrands (e.g. "Hilton JBR" → "Hilton JBR The Walk") are not signals — minor name refinements within the same brand
• Unplanned changes (e.g. "Hilton JBR" → unknown name) = crisis / contract termination = immediate outreach opportunity

Current state: Entirely reactive — Ramine stumbles upon name changes while browsing Booking.com for other purposes. A deflag can go unnoticed for weeks.

Desired state: Automated monitoring (daily or hourly) with an alert when a hotel name changes materially. Decision: this is a confirmed build requirement for the intelligence hub.

Other Signals and Their Value

On LinkedIn specifically: Ramine has not received a "hot lead" through LinkedIn in 15 years. He views it primarily as a professional branding tool. (Note: contradicted by Marloes — see 2026-04-23 Marloes Intelligence Hub and 2026-04-23 Vela Checkin for team discussion of this contradiction.)

New Developer Tracking via Press Releases

Logic (distinct from the "too-late" problem):

• When a press release announces a hotel just signed by an unknown developer → that developer now has a hospitality track record
• They are likely to do another hotel, branded residential, or serviced apartments
• Get in touch now, before they plan the next project: "You just signed a Marriott — we'd love to tell you about Kerten for your next project"
• This converts a "too late" announcement into a future pipeline contact

This is a confirmed use case for the intelligence hub: scan for new developers via press releases and LinkedIn → identify companies Kerten doesn't know → add to outreach list.

Outreach Strategies (Human-Side Context)

• Market education trips: Ramine did a full India trip in February specifically to meet consultants, architects, designers, freelance legal advisors — these people know all the owners even when deals are already signed
• Targeted relationship ecosystem: consultants, architects + interior designers, master planners, lawyers (Baker McKenzie, Al Tamimi, freelance legal advisors) — all refer deal flow once they know Kerten
• Conference side-events: Ramine organises intimate dinners (5 owners + 2 consultants + 2 funds) on the margins of conferences — a fraction of the sponsorship cost, focused engagement
• Cairo example: A 2008 contact (18 years dormant) texted, reconnected → he had just launched a hospitality division → new deal in progress; this is what no AI tool will ever replicate, but it illustrates why network is primary

CoStar Data Coverage by Market

• Ramine holds personal CoStar lists for: Dubai, Abu Dhabi, Sharjah, Riyadh, Jeddah, Nairobi, Bali, Jakarta, Mumbai, New Delhi, Istanbul, others
• These are old (some 10+ years); the new system (which Karolina manages) pulls live data online
• India coverage: limited; New Delhi and Mumbai lists exist but not comprehensive
• Karolina is the right person for current CoStar access and extraction methodology

Geographic Priority

• Ramine shared a high-level location priority and "opportunistic" locations map during the session (screen share)
• Proposed starting point for intelligence hub build: Egypt, Morocco, UAE as top 3 priority markets
• Will provide Vela with a full priority list (by country, then specific cities within each country)
• Note: Kerten's BD bonus structure is linked to specific geographies — these incentive locations should be used as the tool's priority geography list

Decisions & System Implications

Proposal Generation System

• Shared data source with intelligence hub: The CoStar competitive set performance data (ADR, RevPAR, occupancy vs. comp set) that Ramine uses to build an outreach business case is the same data Karolina uses for financial projections in proposals → the two systems draw from the same CoStar source; the intelligence hub's comp set extraction can feed directly into the proposal generation system's financial agent
• No other proposal generation decisions from this session

Intelligence Hub

1. Contract renewal prediction engine — primary build priority: use CoStar opening dates + assumed contract lengths (15/20 year defaults; 10 as exception for Kerten) to generate a rolling 12-month target list, refreshed regularly
2. Booking.com name change monitor — automated daily scan; alert on material name changes (same brand refinement = ignore; brand removal = flag immediately)
3. Review aggregation and business case generator — scrape TripAdvisor / Booking.com reviews → categorise by complaint type → rank top 3 issues → auto-draft an approach pitch for the owner
4. New developer tracker — scan press releases and LinkedIn for hotel signings → identify developer → add to outreach list with a "future project" approach flag
5. Permit applications — Europe-only signal; do not apply to MENA, Africa, or India
6. Newsletter/industry news scanning — low priority; too slow; real-time signals (Booking.com name change, press releases) are higher value
7. Geographic build order — Egypt, Morocco, UAE first; use Ramine's bonus/incentive location list as priority guide; go city-specific within each country (e.g. Turkey = Bodrum + Antalya, not all of Turkey)
8. Brownfield / conversion priority — the tool should prioritise existing operational hotels approaching renewal over greenfield opportunities; brownfield deals generate immediate management fees

Observations

• The contract renewal prediction strategy is the most concrete, actionable intelligence hub use case to emerge from all sessions — it is data-driven, systematic, automatable, and produces a warm outreach with substance rather than a cold contact
• Ramine has the clearest mental model of what the tool should do — his framing (CoStar → renewal date → comp set performance → review aggregation → business case → approach) is a complete pipeline that can be built
• The Booking.com monitoring insight is unique to Ramine — no other session participant mentioned it; it targets a real gap (reactive discovery of deflags) with a straightforward automated solution
• Ramine's LinkedIn scepticism vs. Marloes' positive experience is a genuine contradiction — likely explained by how they each use LinkedIn (Ramine: passive/infrequent; Marloes: active, personal, organic); resolving this matters for the Phase 2 LinkedIn strategy
• The Cairo story — 18-year dormant contact → new hospitality division → new deal — is the clearest illustration of why network is the primary channel and why the intelligence hub must be positioned as amplifying the network (finding new contacts, surfacing timing signals) rather than replacing it
• Karolina is the CoStar access point — Ramine defers to her for current extraction methods; the intelligence hub's CoStar pipeline should be designed in coordination with Karolina's workflow

System Development Director India — Shivali — April 23, 2026

Person

• Name: Shivali (last name not stated in session)
• Role: System Development Director, India — Kerten Hospitality
• Background: Prior hospitality experience at another brand (unlike Aditya, who is new to the industry); more senior India BD contact
• Note: Aditya described her in the previous session as being able to answer more questions; Shivali confirmed she came "unprepared" but is willing to reconnect

Inputs

• Personal network and professional contacts from previous hospitality roles
• Finders / middlemen — primary channel: proactive outreach to known individuals + reactive inbound from their networks
• Consulting firms who run feasibility studies and include an "operator search" component (JLL, CBRE, HVS, Hotel Evaluate)
• Real estate firms and family-owned businesses with land banks and investment appetite
• LinkedIn — industry news, developer activity (~30% of working time on market intelligence)
• OTAs: MakeMyTrip (primary), Booking.com — used to find and filter independent hotels
• HICSA / HIXA and HVS analog reports — directional supply/demand statistics by city
• Local / regional media — real estate developer announcements, mixed-use development news
• "First contact" database + property activity database — maintained centrally with Ramin

Her Process

Step 1 — Lead Identification

• Proactive: reach out to known finders and middlemen, ask about active pipeline
• Reactive: middlemen contact Shivali when a promoter approaches them
• Brand awareness (PR press releases) → some promoters reach out directly after seeing coverage; this is the highest-quality inbound channel

Step 2 — Initial Filter

• Apply brand criteria before engaging further: exclude owner-operated properties, lease arrangements, minimum revenue models
• Focus exclusively on management contract opportunities
• Preliminary qualifying info needed from middleman: location, number of rooms/keys, stage of construction, floor plans
• ~30–40% of filtered management-contract opportunities are ultimately pursuable

Step 3 — Meeting with Promoter

• Goal: get to the promoter (final decision-maker / owner) within one or two calls, with the middleman as facilitator, not gatekeeper
• Present the brand, discuss the opportunity, assess fit against brand criteria

Step 4 — Proposal

• Shivali did not describe a specific proposal workflow; major India proposals (e.g. multi-brand) are prepared centrally by Alicia
• Ramin oversees India strategy and holds the central contact databases

Tools Used

• MakeMyTrip — primary OTA for India; filter for independent hotels
• Booking.com — secondary OTA; same independent hotel filter
• LinkedIn — market news, developer activity, new hotel signings
• HICSA / HVS / HIXA reports — supply stats, new developments by city (directional only)
• Email / WhatsApp / calls — all outreach and relationship management
• CoStar — not currently used; Shivali not aware of it before this session; willing to subscribe

Contact Tracking

• "First contact" database — all new contacts logged: finders, consulting firms, real estate companies, interested parties
• Property activity database — records all engagements and discussions per asset
• Both databases maintained centrally by Ramin; not India-only

Lead Disqualification Criteria (her mental filters)

• Owner-operated (no management contract opportunity)
• Lease agreements (not Kerten's model)
• Minimum revenue / guaranteed income structures
• Properties that do not meet brand criteria (room count, quality, positioning)

Pain Points & Frustrations

• India is a hugely people-driven market — consulting firms yield fewer leads than individual middlemen
• Inbound leads are low because Kerten's brand awareness in India is still building; established brands receive far more unsolicited contacts
• OTAs (MakeMyTrip / Booking.com) give a starting list of independent hotels but finding the actual owner contact requires separate Google research or cold calls
• No systematic way to track which finders or middlemen have been contacted; database is centralized but Shivali's access to it was not clear
• Disconnect within India team: Shivali was unaware of the Excel databases Aditya had shared the previous day — internal knowledge is siloed

Decisions & System Implications

Proposal Generation System

• Not discussed in depth during this session; proposal creation workflow was not covered
• Implicit: large India proposals are Alicia's work (confirmed from 2026-04-22 Aditya India Country Partner); Shivali's role is relationship management and lead sourcing

Intelligence Hub — India Configuration

• Primary lead channel is human-driven — AI intelligence is a supplement, not a replacement; system must be positioned accordingly
• Data sources to incorporate for India: - MakeMyTrip (preferred over Booking.com) — independent hotel filter as a seed list - LinkedIn — new hotel signings (to identify finders); developer activity; industry news - HICSA / HVS / HIXA reports — directional supply data by city; useful for macro market prioritization - Local media — mixed-use real estate development announcements (hotel element likely) - Hotel signing announcements — used to identify the finder / middleman involved → expand finder network
• Disqualification filters to encode: owner-operated, lease, minimum revenue → exclude; management contracts only → include
• CoStar in India: not yet active; Shivali open to subscribing → flag for Karolina to scope India coverage and set up access
• Inbound > outbound for brand-building: PR press releases in India generated significant promoter inbounds; brand awareness investment is higher-leverage than cold outreach for India market

Observations

• Shivali is the more experienced India BD contact — prior hospitality brand background gives her a comparative lens that Aditya lacks; her view on lead sourcing is more structured
• The finder network dominates all other channels — even consulting firms (JLL, CBRE) yield fewer actionable leads than individual finders; the India intelligence hub must center on supporting and expanding the finder network, not replacing it
• 30% of time on market intelligence is consistent with other BD team members — this is the addressable portion; the other 70% (networking, reactive inbound, relationship management) is non-automatable
• "Promoter reach within one or two calls" is Shivali's stated goal — this means the intelligence hub's primary role for India is populating and enriching the finder/middleman list, not the owner list directly
• India team knowledge gap is real — Shivali was unaware of CoStar and of Aditya's Excel databases; central coordination (Ramin holds the databases) does not mean shared awareness; this fragility should be flagged before building on top of it
• Mixed-use real estate developments are a reliable early signal — announced before a hotel brand is selected; architects, project management firms, and software vendors all get early visibility — these are the pre-middlemen worth reaching

Vela Internal Check-in — April 23, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

End-of-day debrief following three intelligence hub sessions (Shivali, Marloes, Ramine). Key focus: India team findings, intelligence hub concept crystallisation, and planning the Monday deliverable for Muhammad. The session reveals that no stakeholder has actually generated deals from the kind of intelligence scanning they're requesting — raising a fundamental question about where the tool's real value lies.

Key Topics

Shivali debrief (India intelligence hub):

• India is even more relationship-driven than other markets — entirely middleman/finder-dependent
• Shivali could not articulate what digital signals she would want beyond MakeMyTrip and Booking.com
• She was unaware of CoStar; Maria and Shaheer had to explain it; she noted it but didn't engage with it
• She was also unaware of Aditya's Excel databases (shared with Vela the previous day) — India team knowledge gap is confirmed
• Shaheer's read: Shivali kept circling back to networking and middlemen; "she was also trying to figure out exactly what it is that she wants"
• India data sources identified: MakeMyTrip (preferred), Booking.com independent filter, LinkedIn, FHRI / HICSA journals (mentioned in passing, she doesn't read them closely)
• Follow-up: Shaheer to email Shivali a list of identified sources for her to review and enhance

Marloes debrief (referenced):

• Macro market signal thinking (Egypt, Morocco, Greece, India) — most differentiated perspective of all sessions
• Confirmed: even a list of 1,000 names without enrichment has value for a communications/warming strategy
• Organic LinkedIn engagement is working for Kerten; gamified LinkedIn platform idea noted for Phase 2

Ramine debrief (referenced):

• LinkedIn sceptic: "I've never received a hot lead from LinkedIn in 15 years"
• Contradiction with Marloes: Marlo says LinkedIn brings leads → Shaheer's interpretation: Ramine doesn't want to post; his claim is about effort avoidance, not tool ineffectiveness
• Ramine's intelligence vision is the clearest of all sessions: CoStar contract renewal prediction is the primary mechanism

Intelligence hub identity problem:

• Shaheer: "I'm really having a tough time figuring out exactly what the intelligence hub is actually going to be. Is it a newsletter? Is it a lead sourcing mechanism? Is it something else entirely?"
• Different visions per stakeholder: Michael = mass email blast; Muhammad = targeted timing-based outreach; Ramine = CoStar-driven contract renewal targeting; Marloes = macro market signal + warming strategy
• The fundamental tension: everyone says they have never gotten a deal from the kind of scanning they're asking the tool to do; real deals come from networking, conferences, press releases, and personal relationships

Theo's architecture framework for the intelligence hub:

1. Foundation layer: knowledge graph of contacts, people, relationships — dynamic, not static (people move, sell businesses, die)
2. Enrichment layer: for any contact/property, auto-pull: reviews, CoStar ADR/ranking, company background, contact details, ownership history
3. Signal layer: newsletters, press releases, LinkedIn posts → qualify against Kerten criteria (independent? management contract? right size?) → match to enriched contacts in the database
4. Output layer: when signal + enriched contact align ("triple 7") → serve a ready-made pitch with full context

• "The consumption part is the easiest once you have the data" — search, alerts, weekly newsletter, auto-generated proposals are all possible outputs once data exists

The "list obsession" problem:

• Theo: BD people are obsessed with having lots of names but a plain list of names is useless
• The value is: names → enrichment → signals → context → pitch
• Theo's personal analogy: even knowing someone needs an accountant and receiving a systematic outreach for one, he still called friends for a recommendation; cold systematic outreach is reticent even when the need is known

Practical value proposition:

• The most concrete near-term value: automating the manual research BD does before an outreach (10–20 minutes per opportunity × hundreds per year)
• Ramine's CoStar pipeline (opening date → contract renewal → comp set → reviews → business case) is a fully specifiable, buildable workflow
• Booking.com name change monitoring is a concrete, bounded, immediately automatable feature

Decisions Made

Proposal Generation System

• Monday deliverable structure confirmed — three components for the meeting with Muhammad: 1. Processes as-is — process flows already prepared; no changes needed 2. Assessment / observations — notes on process flows + a few PowerPoint slides per major stage with non-judgmental observations (e.g. "people have different approaches at this stage; sometimes escalated, sometimes not, depending on deal size") 3. Solution ambition — what the system should do, where it will help, and Shaheer's technical architecture diagrams of the build
• Maria to create the presentation deck — no deck exists yet; Maria starts it; Shaheer adds technical diagrams
• Present proposal generation on Monday; intelligence hub to be discussed further first — proposal system has a clear picture; intelligence hub needs another session

Intelligence Hub

• Intelligence hub concept is not yet defined clearly enough to present to client on Monday — Theo and Shaheer to meet on Apr 24 at 2pm to align on the concept before presentation
• Build the list before the signal arrives — don't wait for signal detection to be working before starting the contact database and enrichment; so when signals fire, the enriched contact is already there
• Confirmed priority features to build (from synthesis across all three sessions today): - CoStar contract renewal prediction (Ramine's mechanism — highest-signal systematic approach) - Booking.com name change monitor (Ramine — near-real-time deflag alert) - OTA scouting for independent hotels (Marloes / Shivali — Booking.com + MakeMyTrip for India) - New developer tracking via press releases + LinkedIn (Ramine — future pipeline contacts)
• Country-specific configuration confirmed as a design requirement (Marloes' macro signal framework is market-dependent)
• LinkedIn strategy (Phase 2 gamified platform) — noted, not in current scope

Contradictions & Flags

1. LinkedIn: Ramine says useless; Marloes says it generates leads. Theo's interpretation: Ramine doesn't use LinkedIn well (doesn't post meaningful content); LinkedIn done organically and personally (Marloes' approach) does work. Resolution: Ramine's view is about his personal usage, not the tool's ceiling. The Phase 2 LinkedIn platform should still be scoped. → Not yet formally resolved.

1. Nobody has gotten deals from intelligence scanning. All stakeholders confirm that real deals come from networking and personal contacts. The tool must be positioned as amplifying the network (surfacing timing signals, reducing research time) not as a new lead generation channel. → This is a scope and expectation management issue for the Monday presentation.

1. India team knowledge is siloed. Shivali didn't know about Aditya's databases or CoStar. Aditya's session and Shivali's session produced inconsistent pictures of how India BD actually works. → The intelligence hub for India must be built on consolidated, verified inputs, not on what any single India team member described.

Observations

• The intelligence hub is the harder problem of the two — the proposal generation system has a clear workflow and clear stakeholder needs; the intelligence hub's value proposition is contested even by the people requesting it; this requires an explicit scoping conversation with the client before building
• Theo's "triple 7" framing is the clearest statement of what the intelligence hub must achieve: when location + hotel + owner + performance + signal + contact details + timing all align, the tool serves a ready-made pitch — but filling all cells for most opportunities is very difficult
• Enrichment is solvable; signals are not — Shaheer's distinction: enrichment platforms exist; the market signal layer (what to monitor, how to qualify) is still conceptually underspecified after all sessions
• The two-track architecture (static list + enrichment in parallel with real-time signal capture, both feeding into each other) is the right structure — Theo confirmed this; it avoids the trap of waiting for signals before building the base
• Ramine's CoStar pipeline is the first concrete build target — it is fully specifiable now; it uses existing data (CoStar); it has clear logic (opening date + contract length → renewal window); it produces a warm outreach with substance; start here

Director of Technical Services & Projects — Harsha Ramamurthy — 2026-04-24

Person

• Harsha Ramamurthy, Director of Technical Services & Projects at Kerten Hospitality.
• Self-describes as "anti-AI" — does not personally use ChatGPT or other AI tools, though he tells his team to use them as a starting point.
• Sits between BD/commercial decisions (which are owned by Marlo and Antony) and operational execution. His remit is technical feasibility: does the building actually work for the proposed brand and program.
• Typically engaged on a subset of proposals — straightforward properties bypass him entirely; complex conversions, ambiguous fit, or master-plan-heavy decks come to him.

Inputs

• Existing architectural plans / blueprints from the owner (often partial, sometimes only PDFs without CAD).
• A brand declaration from BD (e.g. "we want to put The House here") — already pre-decided with Marlo and Antony before reaching him.
• Owner stipulations: target keys, target revenue, what they're willing to spend.
• Site location (often just a pin / address) — he cross-references it on Google Earth.
• Sometimes ad-hoc, late-night requests ("need it by tomorrow morning").

Their Process

Step 1 — Brand fit triage. First question is always: which brand are we proposing — The House, Cloud 7, Hosmi? Pulls the relevant brand guidelines as a reference, not a hard rule. Brand guidelines specify minimums (e.g. The House: 30 sqm minimum room size) but he treats these as negotiable depending on location, building condition, and owner constraint. Compromises on a few rooms at 24 sqm, 20 sqm, or even smaller is acceptable; what matters is the majority distribution.

Step 2 — Area program check. Verifies the property has enough back-of-house space (storage, offices, staff areas) to operate the proposed key count. Manning ratio scales by star rating — 3-star can run <1 staff/room, 4- and 5-star scale up, ultra-luxury higher still. More manning means more BoH space requirement. If BoH is insufficient, alternatives are: rent a separate warehouse / offsite office, or compromise (which causes downstream operational pain).

Step 3 — Cost-per-key range. Gives BD a range (e.g. €20k–€23k/room), never a fixed number. The range depends on whether scope includes restaurant, gym, façade repaint, etc. — cost per key is "total renovation budget ÷ keys," and most early-stage decks don't have the inputs to be precise. Tells BD to use ChatGPT to get a baseline market figure, then he adjusts for project type (whitefield vs. conversion vs. retrofit) and remoteness.

Step 4 — Master plan review. When plans arrive, walks the floor plates, validates the labeled square meterages (often catches errors — "this says 114 sqm, it's actually not"), checks adjacencies (reception location, kitchen-to-restaurant flow, guest circulation, entrance positioning relative to street/tourist flow). Cross-references the entrance against Google Earth to confirm it's facing the right way for the actual market.

Step 5 — Envisioning (sometimes). On a subset of projects, owners want him to draw how it could work, not just if. In that case he marks up the plan with reception location, spa flow, show kitchen, dumb waiter, secondary entrances, seating packs. If CAD files are available (rare at proposal stage), he does this in CAD for precise clearances; otherwise he hand-draws over the PDF.

Step 6 — Pushback or sign-off. ~1 in 10 cases he pushes back hard ("you can't propose that"). Most cases he finds a way to make it work, often by visiting the site with the architect — cited a Bassano project where the owner insisted on 40 keys, Harsha thought 60, and after a full-day site visit with the architect they fit 65.

Tools Used

• Brand guidelines documents — reference for minimums (under revision currently, per 2026-04-16 Marina Digital Marketing Lead).
• Internal area program standards — developed by Harsha in coordination with architects, derived from Neufert's Architects' Data.
• Google Earth / Google Maps — to verify site context, surrounding tourist flow, building footprint, adjacent construction.
• ChatGPT — used by his team (not him personally) to pull baseline market cost-per-key figures, which he then adjusts.
• CAD tools — for precise measurements when CAD files are provided (post-signing usually).
• Hand markup over PDF plans — at proposal stage when CAD is unavailable.

Outputs & Handoffs

• A go / no-go (or more often: "go, with these caveats") on brand fit and area program.
• A cost-per-key range to BD for the financial model.
• Marked-up plans showing reception, spa flow, kitchen placement, etc. — when owners ask for envisioning.
• Verbal validation of key counts and feasibility, fed back to BD who incorporates into the proposal deck.
• Aman handles manning numbers and downstream P&L decisions — Harsha's output flows into Aman's work.

Approvals & Back-and-Forths

• Harsha does not approve commercial positioning — that's Marlo / Antony.
• He flags red flags ("this won't operate") and BD decides whether to proceed anyway.
• Owners frequently push back on his key count estimates; some cases need a site visit with the architect to resolve.
• When BD over-promises in a deck before consulting him (e.g. rooftop pool on a building that can't support it), he gets pulled in after the owner queries it.

Time & Volume

• Engagement varies project to project — some bypass him, some need full master-plan review.
• Area program check on a whitefield project is "fairly easy" — fast turnaround.
• Detailed master-plan markup with envisioning takes longer; usually post-signing rather than proposal stage.
• Late-night / next-morning requests are a recurring frustration.
• Currently overloaded with active projects, which means BD sometimes skips bringing things to him.

Pain Points & Frustrations

• BD over-promises in decks before consulting him — happens roughly 1 in 10 times. Recent example: a deck promising key counts that the building physically can't support; owner pushed back and Harsha had to retrofit a defense.
• Plans arrive without CAD — at proposal stage owners rarely share CAD files, so precision work is impossible until later.
• Owner-driven compromises — when owners squeeze out BoH space or manning to hit a financial target, the operational cost shows up later as staff burnout, retention issues, retraining cost. This is invisible on the P&L but real.
• Late-stage involvement — when he's pulled in after signing (cited Colorado and Cagliari), the most impactful changes are no longer possible.
• Anti-AI stance with caveats — frustrated that ChatGPT outputs generic cost-per-key figures that don't account for whitefield vs. conversion, room size, or scope of renovation; treats it as a starting point only.
• Overload — too many active projects; BD doesn't always loop him in early because they don't want to wait.

Decisions & System Implications

Proposal Generation System

• Technical feasibility is a distinct review step, separate from brand-fit and financial validation. The system should route a subset of proposals (complex conversions, ambiguous fit, master-plan-heavy) to Harsha; not every proposal needs his input. A triage rule based on project type (whitefield vs. conversion vs. retrofit) and ambiguity in the brief would mirror current practice.
• Brand guidelines are guidelines, not standards. Any automated brand-fit check that hard-rejects properties below minimum room size will produce false negatives — Harsha's whole point is that compromise on a few rooms is normal and viable. If the system surfaces a brand-fit signal, it must be a flag for human review, not a gate.
• Cost per key is always a range, never a point estimate. The financial agent should output €X–€Y per key with a stated assumption set (whitefield / conversion / retrofit; greenfield vs. existing build; what scope is included). Aligns with 2026-04-15 Sara Development Executive and 2026-04-15 Karolina Director Revenue Distribution use of CoStar.
• Project type is a first-class input. Whitefield, conversion, and retrofit have different cost models and different review paths. The concept brief / direction document should capture this explicitly so downstream agents can branch.
• Location-cost variance is a post-signing concern, not proposal-stage. Don't try to model "couch in Milan vs. couch in the Alps" precision in the financial model at proposal stage. Use a range, note the assumption, move on.
• Master plan markup is two-mode: (a) feasibility-only ("can it work?") vs. (b) envisioning ("how would you do it?"). The proposal system should let BD specify which mode is needed when invoking the technical review step.
• Area program / BoH check is a discrete validation that can be partially automated. A simple rule library (key count × star rating → minimum BoH sqm; manning ratio bands by star rating) could pre-compute a feasibility flag before Harsha sees the plan, saving him time on the easy cases.
• Brand decisioning is upstream of Harsha. By the time a proposal reaches technical review, the brand is already chosen by Marlo / Antony. The system should preserve this ordering — concept brief → brand decision → technical feasibility → financial → assembly.

Intelligence Hub

• Not discussed in this session. Harsha is downstream of lead sourcing entirely; he engages only after a property is in active proposal development.

Observations

• Harsha is the operational truth-teller in a process otherwise driven by commercial optimism. His value is catching impossibilities before they reach the owner; the system risks routing around him if it makes proposal generation faster without preserving his check. The 1-in-10 catch rate is the visible failure mode — the invisible mode is the BoH compromise that ships and burns out staff two years later.
• "Guidelines, not standards" is a recurring theme across stakeholders — also surfaced in 2026-04-15 Lily Creative Director and 2026-04-16 Marina Digital Marketing Lead regarding brand assets. Kerten operates with soft constraints intentionally, because the conversion market they target rarely fits hard standards. Any automation that treats guidelines as standards will systematically reject the deals Kerten wants to win.
• The cost-per-key range vs. point-estimate distinction is a quiet alignment point between Harsha and Karolina (2026-04-15 Karolina Director Revenue Distribution) — both push back against false precision. The financial agent design should default to ranges with stated assumptions, not single numbers.
• Anti-AI but pro-team-using-AI is a workable pattern. Harsha doesn't need to use the system himself — his team can feed him pre-processed outputs (area program flags, cost-per-key baselines, plan validations) and he reviews. The system should target his team's workflow, not his.
• Late-stage technical involvement is a structural failure mode, not a Harsha problem. The Cagliari and Colorado examples show what happens when technical review is bypassed at proposal stage and reintroduced after signing. The proposal system can either fix this (by enforcing a routing step) or codify it (by making the no-technical-review path explicit and tracked).
• CAD availability is the real precision gate. Until owners share CAD, all square-meterage validation is approximate. Worth flagging that the proposal system's master-plan review step should accept PDF as input but mark its output as "approximate, pending CAD."
• Harsha's site visit story (Bassano: 40→60→65 keys) is a counter-example to the "automate the proposal" narrative. A full-day on-site with an architect unlocked 60% more keys than the owner's estimate. The system can't replicate that. It should leave room for it — i.e. not lock in key counts too early, and flag conversions where on-site validation could materially change the numbers.
• Harsha's Aman handoff is a routing detail worth confirming. He says manning decisions go to Aman — this maps to the Aman/Ramin financial-approver ambiguity already flagged in INDEX.md contradictions. Aman appears to own technical-cost / manning numbers, while Ramin owns commercial financial sign-off. May resolve the contradiction.

Vela Internal Check-in — April 24, 2026

Attendees

• Theo Breward — Managing Director, Vela Advisory (calling from south of France; travelling to Paris this evening, back to Dubai Sunday)
• Maria Haddad — Consultant, Vela Advisory
• Shaheer Ahmed — Tech Lead, Vela Advisory

Summary

End-of-week check-in focused almost entirely on finalising the Monday client presentation. The deck structure, time savings targets, and solution design narrative were locked in this session. One final stakeholder call (Hara — proposal process) is scheduled immediately after this check-in; any findings will be folded in before the deck is sent. CoStar account setup remains blocked.

Key Topics

Week-end status:

• Client engagement is in a good state — collaborative, responsive, generally trusting the direction
• Michael O'Shea is the exception; Theo's position: stop seeking buy-in from him and go directly to showing results
• Maria completed all process flow mapping this week (maxed out her Claude usage doing so)

Final proposal stakeholder call today:

• One outstanding call with Hara (role in proposal process — not yet in Key People table) scheduled immediately after this check-in
• Observations and process flows may need minor amendments based on what Hara shares
• Scope: proposal creation process only

Monday meeting logistics:

• Two Monday calls: (1) Stream 1/BD — Muhammad + Cathal; confirmed and responsive; (2) Stream 3 — Mina + Aman; only Cathal replied tentatively; Mina and Aman have not confirmed
• Action: Theo to WhatsApp Mina directly to confirm
• Plan: send the deck to clients today so they can read over the weekend before Monday calls

Deck delivery timeline:

• Shaheer to send his section to Maria by 4:00–4:30pm Dubai time
• Maria to consolidate and send combined deck to Theo before 5:00pm Dubai time
• Theo on train to Paris 5:00–8:00pm; will review and send to client on Saturday morning
• Theo sends to client (Maria does not)

Monday Deck Structure — Finalised

Section 1 — Process mapping (as-is)

• The full process flows Maria has built
• Add observation stickies directly on the process maps (not a separate section per phase)
• Purpose: show the client their own process, not to review box by box on the call

Section 2 — Time estimates

• Time spent per activity/phase, averaged across stakeholder inputs
• Big disclaimer required: these figures cover only the operational proposal-writing work; they do NOT include time spent by management on meetings, ideation, market research, transmitting direction to the team, or work done by other departments (legal, finance, marketing, revenue)
• Do NOT break out new-joiner vs. experienced timing — irrelevant as an observation; blend all inputs into a single average
• Target framing: simple proposal ~12 hours today → target ~6–8 hours; complex proposal ~40 hours today → target ~25–30 hours

Section 3 — Observations

• One summary slide with the big cross-cutting observations (not per-phase detail — too much, risks appearing critical)
• Key observations to include: - No standardised templates; each BD person builds their own way - Teams rely on other departments differently depending on context - Two distinct proposal types: graphic-heavy (concept/lifestyle) vs. data-heavy (financial/market); these have different emphasis and different effort profiles - Approval routing is not fixed: financials go to finance, Karolina, or Ramin depending on deal type and market

Section 4 — Solution design

• Shaheer's technical architecture; reviewed live during this call (screen share)
• Final structure agreed: 1. Overall view: three phases end-to-end — Concept Briefing → Outline Generation → Document Generation; each phase ends with a human-in-the-loop validation checkpoint before proceeding 2. Inputs slide: all data ingestion sources, using slightly technical language to convey genuine complexity (scraping, APIs, document parsing, image recognition, CoStar API); include the conversational AI agent (Claude guided conversation / slash command skill) as the primary human-AI interaction for the concept phase 3. Per-phase detail: for each of the three phases — (a) high-level flow slide, (b) deeper technical complexity slide, (c) UX/interface concept slide (Claude Design mock-up shown as concept) 4. Outputs slide: all system outputs listed clearly — PowerPoint presentation, Excel financial model (inputs tab + clear assumptions), concept brief as Word/PDF, image bank — all delivered together as a folder

Framing intent for the presentation:

• Show enough complexity that the client understands it is not a "press a button" solution — many tools, data sources, imperfect inputs, AI judgement required
• Do not overpromise or be triumphalist
• The session is a checkpoint: the client must have a clear enough picture to agree with the direction or raise objections now — "right now to speak or forever hold your peace"

Decisions Made

Proposal Generation System

1. Three-phase architecture confirmed for Monday presentation: Concept Briefing → Outline Generation → Document Generation, with human checkpoint at end of each phase
2. System outputs confirmed: PowerPoint, Excel financial model (inputs tab + assumptions), concept brief (Word/PDF), image bank — delivered as a folder
3. Data ingestion sources confirmed for inputs slide: template library, web scraper, document parser (PDFs/newsletters), CoStar API (pending), image library, conversational AI agent
4. Time savings targets set: simple proposal 12hrs → 6–8hrs; complex proposal 40hrs → 25–30hrs
5. Observation framing: summary-level, non-judgmental; stickies on process maps; one synthesis slide; no per-phase breakdown
6. New-joiner timing variance excluded from observations — not a relevant or useful data point for this presentation
7. Shaheer to begin building the concept brief phase from next week — this is the clearest-scoped phase and can start in parallel with architecture finalisation
8. Technical deep dive on system architecture (hosting, databases, security) scheduled for Tuesday Apr 29 — Shaheer flagged he had underestimated the level of detail Theo expected; this will be caught up then

Intelligence Hub

• CoStar API still blocked: Theo's account signup hit a bug (email field locked but submission flagging it as empty); waiting for CoStar support response
• Escalation option if still blocked: get Karolina to walk through her account live on a call, so the team can understand the data extraction flow even without independent access
• No new intelligence hub design decisions in this session

Contradictions & Flags

1. Stream 3 Monday call unconfirmed — Mina and Aman have not replied. Cathal approved tentatively; Mina and Aman have not confirmed. → Theo to WhatsApp Mina directly today.

1. Hara call outcomes not yet incorporated. The final proposal stakeholder session (Hara) happens after this check-in; observations may need amending. → Maria to fold in findings before sending deck to Theo.

Observations

• The Monday presentation is a trust-building milestone, not a deep review — Theo's framing is clear: don't walk the client through every box in the process map; show them their process exists, show them the observations, pivot quickly to the solution. The value of the discovery is not the map itself but what it reveals.
• The three-phase structure with human checkpoints is now the agreed system architecture — this resolves the earlier open question from 2026-04-22 Technical Workflow Session about when humans are involved; the answer is: between every phase, not just at the end
• CoStar access is a build dependency that is not yet resolved — two weeks into the engagement, the Vela team still does not have working CoStar access; the intelligence hub's primary signal strategy (Ramine's contract renewal pipeline) cannot be fully built until this is resolved; Karolina walkthrough is the right escalation
• Shaheer starting the concept brief phase next week is the right call — it is the best-understood component; building it will also surface real integration questions (template library, document parser, conversational interface) that the Tuesday architecture session needs to address
• The "big disclaimer" on time estimates is important — the 12-hour and 40-hour figures are operational only; actual total cost of a proposal (including management direction, legal, finance, marketing) is substantially higher; the savings figures should not be compared against total cost without this context
• Hara is an unknown — the final proposal process call today may introduce new observations; if Hara's role is significant in the proposal workflow (their name suggests a Country Director or similar), the process map may be incomplete without it

Vela Internal Check-in — April 27, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Maria Haddad — Vela Advisory
• Theo Breward — Vela Advisory

Summary

Morning check-in ahead of the 4pm weekly review with Muhammad and Cathal. The team aligned on the ROI narrative for the proposal automation, agreed on a unit-cost framing for inference pricing, and confirmed Shaheer is starting the Phase 1 build today. Two blockers were flagged: missing Cloud 7 template assets from Lily, and the AI foundation review meeting still pending Mina and Aman's input.

Decisions Made

Proposal Generation System

• Phase 1 build starts today. Shaheer will create Claude Desktop plugins to implement the concept brief phase, including the /market-research and /submit-brief slash commands.
• Cost framing: Use a unit price per proposal rather than a monthly aggregate. Theo's working estimate: ~$50–100 per proposal in inference cost. Shaheer declined to commit to a number until the full tech requirements are mapped (due tomorrow or day after).
• Weekly Monday demos to client are confirmed as the engagement cadence from now on. Keeps clients involved and calibrated on complexity; counters the "AI can just figure it out" assumption.
• Cloud 7 template assets are a blocker. The templates Lily provided are incomplete — missing cover page and section dividers. Shaheer to send a complete list of missing assets to Theo immediately after this call; Theo to forward to Lily.
• Image pipeline simplification: Shaheer found that Aifi scrapers provide high-quality metadata about images. This may eliminate the need for a separate AI image-analysis step in the pipeline — images can be selected based on scraper metadata alone. To be investigated further.

Intelligence Hub

• Needs a dedicated brainstorm session with the client before scope can be defined. Too much is still unclear.
• Maria to start preparing material on current vs. desired lead generation methods and current market monitoring practices (interviews-based synthesis). This will form the basis for the intelligence hub scope conversation.
• Book the intelligence hub brainstorm during today's 4pm client meeting.

Key Topics

Proposal automation ROI document

Maria prepared a document laying out time savings targets: ~10h saved on both simple (20h→10h) and complex (48h→36h/38h) proposals. Theo's framing for the client: the ROI argument should emphasize (1) hours saved across 2–3 proposals per week (20–30h/week = ~1 FTE saved), and (2) cognitive load reduction — the tool removes the burden of jumping between CoStar, Excel, PowerPoint, email, and the web; reviewing AI-generated work is faster than creating from scratch.

Cost estimation

Shaheer is mapping all API costs (CoStar, Claude, web scrapers, image sourcing, Pinterest, Excel computation). Phase 1 (concept brief) runs primarily on Claude subscription with some API calls in the background. Phases 2 and 3 are inference-heavy. Theo flagged that if inference hits ~$5,000/month at current proposal volumes, the ROI breaks even — unit pricing per proposal is the right way to frame this to avoid that framing issue.

AI foundation review meeting (Stream 3 / Mina and Aman)

A 2pm meeting today was scheduled for AI tooling review with Mina (COO) and Aman (CFO). They have been unresponsive (Maria was "ghosted"). Theo messaged them this morning. Kahal (Cathal) is the only one who responded (tentative). The ball is in their court to come back with survey comments and the Excel review.

Stream 3 (training and policy)

Low priority for now. Theo noted that Gonzalo's Claude training materials from another client engagement (an investment fund) can be reused as a base; BCG training templates are also available. Adaptation to Kerten's context is the main task. Policy templates also exist. No significant new work needed until Stream 3 is prioritized.

Intelligence hub scope

Still vague. Neither Shaheer nor Theo have had time to converge on a design since the stakeholder sessions ended Friday. Decision: take the ideas gathered so far directly to the client (Muhammad, Cathal) and run a brainstorm rather than designing in isolation. Ask: which of these possible capabilities are most useful to you, and in what order?

Contradictions & Flags

1. Template assets still blocking build: Cloud 7 PPT templates from Lily are incomplete. The House templates are also missing entirely. This has been known for days; the email to Lily has not yet been sent. → Status: action assigned (Shaheer → Theo → Lily); unblocked once sent

1. Claude Enterprise access still pending: Mina and Aman approval for Claude Enterprise was mentioned in passing. The AI foundation review meeting may resolve this, but it is still blocked. → Status: unresolved; dependent on today's 2pm meeting

Observations

• The unit-cost framing for inference is the right one — a per-proposal price of $50–100 is easy to compare against the value of 10 hours of BD time; a monthly aggregate obscures whether ROI is positive depending on proposal volume
• Aifi scraper metadata is a potentially significant simplification — if image metadata is rich enough to select images without a separate AI analysis pass, it removes one agent from the pipeline and reduces both cost and latency; worth prototyping early
• The Monday demo cadence sets a hard weekly forcing function — Shaheer starting Phase 1 today means something demonstrable needs to exist by next Monday; this is the right pressure
• Maria preparing intelligence hub material in parallel is the correct sequencing — even if the brainstorm hasn't happened yet, arriving with a synthesis of what was learned from the stakeholder interviews will make the conversation more focused
• Lily's incomplete templates are a harder blocker than it appears — python-pptx assembly requires knowing the master template structure before the assembly agent can be built; this cannot be worked around; the sooner the complete assets arrive, the sooner Phase 3 can be designed concretely

BD AI System — Weekly Progress Review — April 27, 2026

Attendees

• Muhammad Yacoubi — Senior Director BD / CBDO, Kerten (Stream 1 champion)
• Cathal O'Shea — Owner's representative
• Theo Breward, Maria Haddad, Shaheer Ahmed — Vela Advisory

Key Topics Discussed

Proposal automation solution walkthrough

Theo presented the end-to-end architecture. Three-phase flow: (1) Concept Brief — guided conversation in Claude Desktop; (2) Outline Generation — chapter/slide structure proposed by agent, human reviews; (3) Proposal Generation — PPT + Excel financial model + image bank + concept brief document.

Data sourced during Phase 1: CoStar benchmarks (ADR/occupancy), web scraping (competition, reviews, activities), contact/owner context. All runs in background while the human is in the concept brief conversation.

Phase 2 output: visual outline showing chapter, slide title, narrative direction, and layout type per slide. Human can remove/add slides before hitting generate.

Phase 3: image sourcing agent finds pictures per proposal from the web, populates branded template slots. Validation layer checks image quality, layout, crop. Output is a finalized PPT — no re-prompting after this point.

Time savings targets and Muhammad's pushback

Vela's current targets: 20h → 10h on simple proposals, 48h → 36h on complex. Muhammad's reaction: 25% reduction on complex proposals seems underwhelming given the AI hype; he expected a more dramatic cut. Theo's explanation: for complex proposals, the non-automatable steps (Lily's design work, Harsha's technical feasibility assessment, iterative back-and-forth on fit) cannot be compressed. Framing agreed: restate simple proposals as "2x faster" rather than "50% reduction."

Cathal suggested a task-level breakdown of the 36-hour new state, identifying which tasks are still slow and why, to make the case more concrete. Muhammad agreed this would give a fairer picture than a headline percentage.

Key conceptual distinction Theo made: the tool may do 30–40 hours' worth of work, but half of that won't be good enough — so the human still spends 10 hours redoing and refining. The net human time drops but total work input is higher.

Third proposal archetype — the teaser

Muhammad introduced a third archetype: a mass teaser proposal for initial outreach — quick, not fully customized, possibly generated in under 2 hours. This connects directly to the intelligence hub: hub identifies 100 targets → system auto-generates 100 teasers. Muhammad framed this as a new business development capability, not just a time-saving one. Theo acknowledged the tool could eventually support this; it is the more ambitious future state.

Image sourcing approach

Current design: AI searches the web and selects images per proposal; human can override. Alternative discussed: AI builds a per-proposal image library, human makes the final picks. Decision: stay with the current AI-selects approach (more ambitious) for now, but human override remains available.

Muhammad suggested that visual mood and look-and-feel direction should be captured early in the concept brief conversation, so the image sourcing agent has proper guidance before it starts searching. Theo confirmed this is planned but the v1 is text-only for mood; image mood board is an enhancement to consider.

PowerPoint vs. alternatives

Muhammad asked about Canva and Pitch as alternatives, noting that Lily already uses Pitch. Shaheer: PPTX is one of the hardest frontiers for AI — essentially unsolved at scale. Canva is the best AI-integrated presentation tool currently. Markdown-to-slides is possible but not suited to Kerten's proposal style. Decision: test Canva and Pitch for automation fit before any switch; adoption cost is high so the advantage needs to be clear. Muhammad's position: if a tool gives a better visual outcome and integrates better with AI, it's worth learning.

Multi-model / multi-tool architecture

Muhammad asked whether different AI models will be used for different tasks. Theo confirmed: yes — Excel handles calculations (not AI per se, but AI-prompted), LLMs handle content, dedicated tools handle images. The system is engineering-orchestrated rather than a single model doing everything.

Muhammad also raised the idea of a "convergence period" — a phase after the 10 weeks where the model learns from many trials. Theo clarified: weak learning mechanisms are built in for specific tasks (taste/preference feedback loop), but this is not full mathematical machine learning. It is prompt engineering and systems integration.

Sprint plan and client engagement

• Next 5 weeks: focused on proposal generation build; Shaheer starting Phase 1 (concept brief plugins for Claude Desktop) this week
• Following 5 weeks: intelligence hub build; some overlap possible
• Weekly Monday demos to client; Theo will show progress, surface blockers, and gather directional feedback
• Muhammad: use WhatsApp group for ad-hoc unblocking rather than waiting for weekly calls
• Suggestion: invite a BD team member (Sara or Alicia) into the weekly call so someone on the client side builds working knowledge of the system

Intelligence hub

Not deep-dived today. Theo: ideas are formed but scope is still vague. A dedicated brainstorm session with client is needed. Muhammad's vision: hub should eventually power mass teaser proposals (100+ prospects → auto-generated teasers), directly linking Streams 1.1 and 1.2.

Post-12-weeks maintenance and cost (Cathal)

Cathal raised: who maintains this after the engagement ends? What is the ongoing inference cost? Theo: working on the cost estimate; will share shortly. Every proposal generation involves many API calls. No specific numbers committed in this session.

Decisions Made

Proposal Generation System

• Include mood/look & feel as an explicit input in the concept brief phase (v1: text description; image mood board as a future enhancement)
• Reframe time savings messaging: "2x faster on simple proposals" rather than "50% reduction"
• Prepare a task-level breakdown of the new-state 36-hour estimate (showing which tasks are still slow and why) for the next stakeholder presentation
• Third archetype (teaser/basic) to be scoped: near-zero human time if standardized, enables mass BD outreach
• Test Canva and Pitch for automation compatibility before switching from PowerPoint; no switch without a clear advantage
• Weekly Monday demos to client team starting now
• Invite a BD team member (Sara or Alicia) into future weekly review calls so client-side knowledge is built

Intelligence Hub

• Muhammad's vision explicitly links it to the proposal generator: hub surfaces 100+ prospects → teaser proposals auto-generated — design should account for this
• Dedicated brainstorm session needed with Muhammad and Cathal to pin down scope; to be scheduled via today's 4pm meeting

Contradictions & Flags

1. Time savings expectations gap: Muhammad's intuition is that <10h on simple proposals should be achievable; Vela's current target is 10h. The gap is real and driven by non-automatable human steps (design quality, editorial judgment, iterative fit). A task-level breakdown was agreed as the way to address this — but it may surface further expectation misalignment. → Status: partially addressed; task breakdown pending

1. Lily uses Pitch, not PowerPoint: Confirmed again in this session. No decision made on whether to adopt Pitch. Vela will test before recommending. → Status: unresolved; testing required

1. Post-12-weeks ownership: Cathal flagged maintenance and cost as open questions. Vela has not yet provided specific answers. → Status: unresolved; cost estimate pending from Shaheer

Observations

• Muhammad's 25% reduction reaction is a useful signal — if the Kerten leadership's baseline expectation is more aggressive, the presentation order matters: show the architecture before showing the numbers so they understand what the system actually does before judging the headline
• The teaser archetype unlocks a new business model, not just efficiency gains — Muhammad's vision of 100 auto-generated teasers from intel hub is where the system's real strategic value lies; this should be surfaced more prominently in how Vela frames the proposal
• Lily's role remains a single point of failure for image quality — even with AI-sourced images and human override, the design refinement step that Lily currently handles is not automatable at her quality level; this will continue to constrain how much time can be saved on image-heavy complex proposals
• The "AI picks images" vs "AI builds library, human picks" decision is worth revisiting: Muhammad's suggestion of validating visual direction at the concept brief stage is a middle path that could reduce downstream image rejection without requiring a full library system
• Cathal's maintenance question is the right one to ask now — Kerten needs to own this post-engagement; the architecture decisions (hosted vs. local, API-dependent vs. self-contained) affect long-term maintainability and should be documented before build decisions are locked
• Weekly Monday demo cadence is a healthy forcing function — it ensures the build stays oriented toward something demonstrable rather than abstractly "in progress"; Shaheer's start on Phase 1 today sets the clock

Vela Internal Check-in — April 28, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Maria Haddad — Vela Advisory
• Theo Breward — Vela Advisory

Summary

Extended check-in that became a technical deep-dive on the concept briefing plugin build. Shaheer demonstrated a working hotel reviews skill (TripAdvisor scraping via web fetch), confirmed the plugin hosting approach (GitHub, not Modal), and the team worked through the full concept briefing conversation flow: section-by-section guided discussion, AI-first creative direction proposals, context management strategy, and CoStar fallback behaviour. Theo added commercial terms (fee levels) as a new item for the concept brief. Intelligence hub work deferred for 2–3 days to allow Shaheer to make meaningful progress on the proposal gen build.

Decisions Made

Proposal Generation System

• Plugin hosted on GitHub, not Modal. Shaheer scrapped the Modal hosting approach from the day before. The plugin (.claude-plugin folder) is zipped and hosted on GitHub; users add it by URL in Claude Desktop — same flow as connecting to Booking.com as a connector.
• No custom MCP servers unless explicitly required. Use web scraping (web fetch/web search) as a workaround. Booking.com MCP (third-party Anthropic/Booking.com) doesn't surface actual reviews; TripAdvisor scraping via web fetch works. Booking.com and Expedia direct scraping to be tested next.
• Hotel reviews skill: surface both positive and negative reviews. Current prompt targets negatives only. Theo's suggestion: blend both. Agreed. Three sources planned: TripAdvisor (working), Booking.com (to test), Expedia (to test). Apify used for some scrapers but minimal credit consumption.
• Concept briefing: section-by-section guided discussion. AI fills each section (property metadata → positioning thesis → concept direction → owner context → financial anchors → design decisions → phasing), validates with user, saves to artifact, moves to next section. Human says go/no-go at each step.
• AI proposes creative direction first; human refines. Claude gives a first-draft concept (experiences, design direction) based on research and Kerten's historical context. User approves or steers. Creative direction is not purely human-generated — AI takes the first swing and the human corrects.
• Submit-brief validator checks required vs. optional fields. At the end of the guided discussion the /submit-brief command runs a validator confirming all required fields are populated. Optional fields presented to user for a final review before confirming submission.
• Commercial terms to be added to the concept brief. Theo: fee levels (management fee, royalty, etc.) are set by BD from an Excel model and vary by market (e.g. Morocco: start high; French/Italian: start closer to target). AI should suggest commercial terms from that Excel based on the market context and positioning thesis.
• CoStar fallback: AI makes assumptions and flags them. If CoStar returns no data (e.g. greenfield in a remote market), AI makes its best assumptions using common sense and explicitly tells the user what it assumed, rather than blocking or silently failing. Loosely defined in the prompt — not a hard-coded fallback path.
• Context management: rely on built-in compaction; sub-agents optional. Claude's compaction handles context pruning well enough for most cases. Sub-agents (summariser + validator) can be added at the submit point to give the Direction Document generation clean context, but this is not a first-build requirement.
• Target demo for Monday May 4: Guided discussion showing property metadata + positioning thesis sections. Creative direction, financial anchors, and owner context sections can be deferred for that demo.

Intelligence Hub

• Deprioritized this week. Shaheer needs 2–3 days of focused build time on proposal gen. Intelligence hub to pick up afterwards.

Key Topics

Plugin architecture overview

Shaheer walked through what the plugin looks like: a .claude-plugin folder containing metadata, skills, commands, agents, hooks, and MCP definitions. All content is markdown except the metadata (JSON). Plugin is zipped and hosted on GitHub — team members add it by URL in Claude Desktop. Skills are auto-selected by Claude based on the description field; slash commands are explicit triggers. The plugin covers four concerns: metadata, skills, commands, and MCP.

Hotel reviews skill demo

Shaheer demonstrated a working /hotel-review slash command that takes a lead prompt (property name, location, owner, etc.) and scrapes TripAdvisor for 10 reviews. Output structure: overall summary, recurring complaint themes, KH-tailored suggestions (currently generic — no KH context yet), and individual reviews. The team verified two reviews against TripAdvisor live and confirmed the output was factual, not hallucinated. One 5-star review that appeared in the negatives was explained: the review was 5 stars overall but contained a negative comment about construction; the AI correctly surfaced it. One issue flagged: a 2024 review appeared in results — Theo suggested adding a recency constraint to the prompt (no reviews older than 1 year).

Concept briefing workflow design

Theo asked how the guided discussion connects to the final concept brief structure. Shaheer's approach: freehand conversation up front; at submit point, a validator checks the required fields. Theo's addition: the AI should also guide the discussion towards those fields throughout — not just at the end — and should propose things (experiences, concept direction) rather than waiting for the human to generate them. Agreed: AI does a first pass of the concept, human corrects section by section. The concept brief structure document (required/optional fields) will be shared with Theo today.

Context management

Theo raised concern about context window degradation over a long multi-source research conversation. Shaheer confirmed Claude's built-in compaction removes irrelevant tool calls, errors, and stale context once the window fills. For the summarisation at submit time, sub-agents can be optionally added to produce clean context for the Direction Document generation step. Shaheer's experience: Claude already auto-spawns sub-agents internally in long sessions when it judges context is filling.

Commercial terms

Theo flagged that BD defines commercial terms (management fee levels, royalty percentages) from an Excel model, with market-dependent starting positions. This belongs in the concept brief, not just in downstream legal work. Agreed to add it as a section; AI will suggest fee levels based on market context with rationale, and the BD team can tune the underlying prompt.

CoStar API status

Still blocked. Theo tried the support email; an SDR support address was found and will be tried. Karolina flagged as unable to help further (API access is outside her reach). Edge case discussed: for greenfield in markets with no CoStar data, the tool should make reasonable assumptions and flag them — not hard-fail.

Week priorities

Proposal gen build is the week's focus. Intelligence hub: Maria is preparing 3–4 slides on current vs. desired state for that workstream, but the build is deferred. Daily 30-min technical check-ins proposed (after the daily stand-up).

Contradictions & Flags

1. Booking.com MCP vs. direct scraping: skills/market-research/CLAUDE.md currently lists "Booking.com hotel review scraping" as a web scraper. This session confirmed the Booking.com MCP doesn't surface actual reviews; direct scraping needs to be tested. → Status: decision made (use direct scraping, not MCP); not yet tested

1. CoStar support escalation path expanded: pipeline/integrations/CLAUDE.md lists three avenues. A fourth (SDR support email) was added in this session. → Status: update integrations CLAUDE.md

Observations

• GitHub hosting is the right call — Modal would have required a persistent server and custom MCP plumbing; GitHub URL distribution means zero infrastructure overhead and the plugin stays alongside the codebase; this matches how Claude Desktop's existing connectors work
• The 5-star-with-a-negative-comment case reveals a useful product decision — surfacing negatives from positive reviews is actually more valuable signal than 1-star rants (owners will dismiss extreme reviews); the skill should be framed as "weakness detection" not "bad review aggregation"
• Theo's commercial terms addition is scope-creep-adjacent but justified — fee levels are market-dependent and BD makes them without tooling today; if the AI can suggest a starting position with rationale, it removes a judgment call that currently has no system support; however, this requires the BD team to encode their market-specific logic into a prompt, which is non-trivial
• Section-by-section validation with AI-first proposals resolves the blank-page problem — the original design risked BD staring at an empty brief and not knowing what to fill in; AI proposing a first draft per section and asking for approval or correction is a fundamentally better UX
• Context management concern is real but premature — Claude's compaction is adequate for most sessions; the sub-agent option is a good back-pocket move for the submit step but over-engineering it now would slow the build
• Intelligence hub deferral is the right call — a working demo of concept briefing by Monday is more valuable than half-progress on two streams simultaneously; the Maria slides give the client something to react to on intelligence hub without requiring Shaheer's time

Vela Internal Check-in — April 29, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Maria Haddad — Vela Advisory
• Theo Breward — Vela Advisory

Summary

~1 hour check-in split between a digression on sovereign AI platforms (N8N-on-steroids type tools), a demo of Shaheer's sync/summarize-transcripts workflows, the concept briefing plugin architecture, and two escalations (Lily's templates and CoStar). Theo proposed a revised time-savings framing for the client slides: unquantified "hours saved" on research in phase 1, and a flat "2× faster" claim on the execution phase. Maria completed a 4–5 slide BD intelligence hub deck showing current state, pain points, and target ambition.

Decisions Made

Proposal Generation System

• Separate research agents feed the main context window concisely. The concept briefing conversation should maintain continuity in a single context window. Tool calling, web research, and other heavy operations are handled by sub-agents that return concise summaries back into the main chat — the main window is not polluted with raw tool output.
• KH brands context document to be populated from actual brand PDFs. The generic placeholder in the plugin will be replaced with content extracted directly from Kerten's brand guideline PDFs so the model has real brand context during concept briefing.
• CoStar fallback: schedule with Karolina for alternative ADR/seasonality data approach. Theo will reach out to Karolina with the question: "How would you get ADRs and seasonality data if you didn't have CoStar?" Whatever her method, the team will investigate whether it can be systematized.
• Time savings slide framing revised. Phase 1 (research/briefing): "saves you hours on research" — no attempt to quantify. Execution phase (phases 2+3): "2× faster" / 100% faster across the board. Drop the complexity split (complex vs. simple proposals saving different amounts) — it weakens the message. A single clear claim per phase.

Intelligence Hub

• Maria's 4–5 slide deck created (current channels, why the process is broken, target ambition). More conceptualization work needed; Theo noted their process is more organic and undocumented than expected.

Key Topics

Sovereign AI platforms

Theo was pitched a "sovereign AI platform" (centralized hub for AI workflows, model garden, RAG, observability, access management, fine-tuning) by a French AI ambassador contact. Similar products exist from Dynamic AI (Dubai, ~$5k/month) and a Chinese investment fund. Shaheer noted these overlap significantly with LangChain's agent builder and OpenAI's agent builder — open-source tools he'd studied 6 months prior. His assessment: powerful for conceptualization and boilerplate code generation, but not production-ready for enterprise use at the time due to missing custom logic support, loop limitations, and abstraction constraints. The platforms have value for organizations struggling with sprawling, ungoverned AI deployments, but technically capable teams don't need them. Shaheer's view: someone who knows Claude's skills and plugin ecosystem deeply doesn't need these at all.

Sync/summarize-transcripts workflow demo

Shaheer demoed the two-command transcript workflow to Theo and Maria: /sync-transcripts pulls new meetings from Google Drive; /summarize-transcripts produces structured summaries in a defined format. Summaries include decisions by system (proposal gen, intelligence hub), key topics, and recommendations on what to update in the system design document. Theo asked about sharing it — Shaheer said he'll package it as a plugin and share via Claude Desktop (the same distribution mechanism as the proposal gen plugin).

Concept briefing plugin architecture

Shaheer showed the current plugin folder structure: each section of the concept brief has its own markdown file defining the purpose, approach, quality bar, and artifact format. A central concept-briefing.md skill file defines the overall conversation protocol (announce purpose, work through sections, validate, save to artifact, advance). A kh-brands.md context document will feed Kerten brand context (brands, audiences, competitive positioning). Theo's question: will the model accurately pick the right brand, or will it over/underfit? Shaheer: testing will tell; this is a core thing to validate.

Blockers raised

1. Lily (templates): 2 days without a response. Theo to follow up.
2. CoStar API: Still blocked. Theo to contact Karolina for manual alternative approach discussion.

Time savings slide

Theo flagged the existing slide tried to quantify savings per proposal type (complex vs. simple), which weakened the message. Revised framing: two separate claims — one for the research/briefing phase (unquantified, but clearly saves time) and one flat "2× faster" for the execution phase. Acknowledge that some steps (Lily's design, Harsha's technical review) can't be compressed — stand the ground on realistic targets.

Contradictions & Flags

1. Time savings targets revised again: Prior framing (from 2026-04-27 Vela Checkin) quantified simple vs. complex savings separately. This session replaced that with a two-part unquantified research savings + flat 2× execution claim. → Status: resolved; update the slide accordingly

1. CoStar escalation path exhausted at Anthropic level: Prior sessions flagged Karolina as the escalation path. This session reframes her as the person who can suggest a manual alternative, not as an API unblocking resource. → Status: new action; Theo to schedule with Karolina

Observations

• The sovereign AI platform digression is directionally useful — Theo will keep getting pitched these tools by clients and contacts; having a clear opinion (open-source alternatives exist, they solve a real governance problem for large ungoverned deployments, technically capable teams don't need them) is valuable positioning for Vela Advisory
• Shaheer's assessment that deep Claude skills knowledge makes these platforms redundant is partially correct but misses the access management gap — Theo rightly noted that per-user model permissions and usage observability are much harder to solve with Claude alone; this is a real limitation worth tracking as Claude Enterprise features mature
• KH brands context document is a hidden critical path item — the concept briefing positioning thesis depends on accurate brand context; using generic placeholder content in the demo will produce poor results and could mislead Kerten stakeholders about the tool's quality
• The CoStar blocking issue now needs a workaround, not just an escalation — the API has been blocked for multiple sessions without resolution; getting Karolina's manual methodology is the right pragmatic move; the risk is that her method (likely manual STR/comp set lookups) can't be systematized in time for the May 4 demo
• The revised time savings framing is cleaner but still needs quantification — saying "saves you hours on research" without numbers is easy for a skeptic to dismiss; the team needs to time Antony or another senior doing the research phase manually to anchor the claim; Shaheer flagged this as a gap
• Maria's intelligence hub deck is a useful forcing function — it gives Kerten something to react to on stream 1.2 without requiring build progress; the conceptualization gap Theo identified is real and should be surfaced in the next meeting with Muhammad

Vela Internal Check-in — April 30, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Maria Haddad — Vela Advisory
• Theo Breward — Vela Advisory

Summary

Short 9-minute check-in. Shaheer confirmed the entire concept briefing structure will be complete by end of day and will do a user flow walkthrough with Theo the next morning. Theo requested a cost estimation ready before the May 1 morning meeting. Maria is working on AI policy customization for Kerten and needs clarity on whether Kerten has a data classification framework. The team aligned on testing sequencing: Theo tests first, demo to Muhammad on May 4 (Monday), Muhammad tests afterward.

Decisions Made

Proposal Generation System

• Concept briefing structure complete by April 30 EOD. Shaheer is building section by section and testing each section's chat behavior. Full structure to be ready for Theo to test on May 1 morning.
• User flow walkthrough on May 1 morning. Theo and Shaheer to walk through the actual end-to-end flow from a user perspective as a practical test session.
• Muhammad to test after Monday demo, not before. Theo wants to test and validate the tool himself before exposing Muhammad Yacoubi. Plan: Theo tests → Vela demo to Muhammad on May 4 → Muhammad tests independently afterward. Shaheer asked about engaging Muhammad as a tester immediately; Theo said no, wait for the demo.
• Cost estimation delivered before May 1 morning meeting. Shaheer committed to having a complete cost estimate ready before the next morning's check-in.

Intelligence Hub

• No updates this session.

Key Topics

Concept briefing build progress

Shaheer is testing each section of the concept brief in sequence, evaluating how the chat responds to each prompt and section context. Expects the full structure (all sections) to be built out by end of the day.

Cost estimation

Theo flagged that the client will need a cost estimate by Monday (May 4). Shaheer committed to delivering it the following morning. (See 2026-05-01 Vela Checkin for the cost analysis discussion.)

AI policy work (Maria)

Maria is customizing an AI policy framework for Kerten, adapted from prior work done for a financial/defense-sector investment fund. Key question blocking customization: does Kerten have a data classification framework? The investment fund client had robust classification requirements; Kerten likely doesn't, but Tara's (legal) involvement suggests there may be something. Maria has a list of questions to go through with Theo to avoid duplicating questions already answered in prior client interactions.

Testing sequencing

Shaheer asked whether Muhammad Yacoubi should be brought in as a tester before Monday. Theo's position: run the demo first, then bring Muhammad into testing mode afterward. Theo believes he can do enough initial testing himself to validate the tool before showing it to the client.

Contradictions & Flags

None identified in this session.

Observations

• This was a brief logistics check-in — the substantive content is in the April 29 and May 1 sessions; the main value here is the testing sequencing decision and the cost estimate deadline
• Theo testing before Muhammad is the right call — presenting a tool with obvious rough edges to Muhammad Yacoubi risks anchoring his first impression on the current limitations rather than the potential; Theo's self-test acts as a quality gate
• The AI policy work (Maria) is a separate stream not yet captured elsewhere — data classification framework question for Kerten is a legitimate dependency; it should be directed to Tara Marlow (Group General Counsel) given she's the only legal resource, but she's also a single point of failure per 2026-04-21 Tara Group General Counsel
• Cost estimate was delivered and reviewed the next morning — see 2026-05-01 Vela Checkin for the full analysis

Vela Internal Check-in — May 1, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Maria Haddad — Vela Advisory
• Theo Breward — Vela Advisory

Summary

The most substantive check-in to date. Theo did a full end-to-end run of the concept briefing plugin using a real RFP (Marrakesh property, The House brand), producing a complete direction document in approximately 2.5 hours. He gave detailed feedback on quality, UX, and structural issues. Key findings: the output quality is genuinely impressive when pushed, but the session pace is too slow (5 min/section), the section ordering needs reworking, and the model over-indexes on initial context and is resistant to correction. Shaheer reviewed the cost analysis and the team aligned on the Muhammad demo strategy for Monday.

Decisions Made

Proposal Generation System

• Section order revised. New order: property metadata → owner context → competitive set & asset assessment → positioning thesis → concept direction → remaining sections. Rationale: knowing the owner context and market benchmarks before committing to positioning and concept direction prevents the AI from building on an incorrect foundation that compounds through later sections. Theo observed the model assumed an Atlas mountain resort context that took significant back-and-forth to correct — market context upfront would prevent this.

• Two workflow paths: with-RFP and without-RFP. When a client provides an RFP, the AI should extract most property metadata and context from it directly without asking redundant questions. This can significantly reduce session time for the large proportion of proposals that come with an RFP. Without an RFP, the current more-questioning approach applies.

• Async-style workflow to be explored: collect inputs first, generate in background. Theo proposed separating user input collection (lightweight, fast Q&A) from section generation (slow, 5 min each), letting generation happen in the background while the user continues answering questions. Shaheer confirmed it's technically possible and would improve the pace substantially, but the conversation loop stops when user input is needed — needs workflow redesign rather than just prompt changes.

• Positioning balance: reduce context overfit, allow more creativity. The model is currently over-grounding itself in the context documents (brand guidelines, previous proposals) and under-applying creativity in positioning and concept direction. Shaheer to adjust the grounding instruction to give more room for novel directions.

• Memory/learning mechanism: 15-point rolling cap. Idea agreed in principle: at the end of each concept briefing session, the tool captures 2–3 lessons from how the session went and saves them to a memory file. When the file reaches 15 points, the model asks the user which to remove before adding new ones. This prevents uncontrolled drift while allowing the tool to improve from session feedback. Not in the first build — a future enhancement.

• Upskill users on directing the AI. Theo's behavior during the session was to provide constructive feedback ("I'd like it a bit more precise") rather than direct commands ("don't like this, try again"). For senior users like Antony or Ghassan, the briefing should explicitly tell them they can reject and restart a section rather than trying to iterate incrementally.

• Users need max Claude subscription ($5/month plan). The $20 plan won't provide enough usage for the iterative generation required. Opus model recommended for concept briefing given the quality gap vs. Sonnet.

• Muhammad demo plan. Theo will send Muhammad the generated concept brief output today (without mentioning the 2.5h session time). Shaheer to retool the workflow toward the lighter "questions-first" approach. Theo tests the new flow, then the team demos to Muhammad on Monday May 4. Do not mention generation time in the demo until the optimized workflow is ready to demonstrate.

Intelligence Hub

• No new decisions.

Key Topics

Full concept briefing run — Theo's detailed feedback

Theo ran the full concept briefing plugin with a real RFP for a Marrakesh property (The House brand, 228-key resort, ~10km from city center). Key observations by section:

What worked well:

• Property metadata extraction from uploaded PDF: accurate, fast, minimal questions needed
• Cross-section consistency: when Theo changed something in section 8, the model proactively offered to revise section 3 to stay consistent
• F&B concept development: when pushed explicitly, the model generated rich, differentiated concepts (library bar, citrus pavilion, villa pantry with chef service, garden breakfast). The creativity was there but needed prompting.
• Competitive benchmarking: did useful market research without CoStar. Identified that a proposed spa concept was already used by competitors and revised it unprompted — a genuinely useful self-correction behavior.
• Commercial terms: generated a thorough proposed term sheet (base fee, royalty fee, incentive fee, etc.) even for sections Shaheer hadn't yet written explicit instructions for. Pulled categories from the RFP. Notably, it identified the owner has Hilton properties and compared its proposed terms against typical Hilton terms.
• Handling of the owner's business context: found two other properties owned by the same group, both with Hilton, and anchored term recommendations accordingly.

Issues identified:

• Session pace: 5 minutes per section generation. With 9+ sections, total session was 2.5+ hours. Not viable as a regular workflow without restructuring.
• Context overfit: The model anchored on "Atlas mountains" imagery from the RFP's language about views, and produced positioning framing around a mountain retreat. The property is actually closer to Marrakesh and will be hot in summer. Took significant back-and-forth to correct, and the model remained partially path-dependent even after correction.
• Traveler profiles too narrow: Initial output gave only two profiles (essentially the same person — one European, one Moroccan). After feedback, expanded to four but all remained similar archetypes. Lacks breadth.
• ADR mismatch: The RFP specified $160 ADR target but also called for "upper upscale" positioning. The model over-indexed on "upper upscale" and benchmarked against hotels with $500+ ADR, then recommended increasing the target ADR to ~$280–320 — a significant departure from the RFP. The model's reasoning was internally consistent, but points to how a misframing early in the session (property metadata/positioning tier) compounds through the financial model. This is not a bug; it's a system design requirement: upfront inputs must be very precise.
• AI phrasing: Final direction document contains generic "this is not just a hotel, it's an experience" language. Tone calibration needed.
• Section ordering: Theo observed that competitive set and market dynamics context would have helped shape the positioning thesis if done earlier. As-is, positioning is set before the AI has analyzed the market, meaning any market reality that conflicts with the initial positioning requires correction after the fact.

Cost analysis

Shaheer presented a cost analysis built on paper calculations. Key numbers:

• Per-proposal token cost: ~$8 (based on deep research system at ~$2/run × 4, applied as a safety buffer; actual likely lower)
• Phase 1 (concept briefing) is the most token-intensive phase; phases 2 and 3 are much lighter
• Volume scenario presented to Kerten: 15 proposals/month (current) → 30 proposals/month (doubled capacity with system)
• Total monthly cost at 30 proposals: ~$533 (fixed Claude subscription + variable API costs)
• Benchmarked against Inventable's published agentic system costs: well below their figures even for their most complex multi-thousand-run workflows
• Shaheer's note: precise pre-deployment cost estimation is not standard practice for agentic systems; teams always measure post-build and cost-optimize. The estimate is a well-reasoned upper bound, not a guarantee.

Muhammad demo strategy

Theo to send Muhammad the concept brief output generated from the real RFP, framing it as a rough first pass and asking whether the direction sounds right for the market. Shaheer to rebuild the workflow with lighter UX (questions-first approach) before the Monday demo so the in-session experience Theo demonstrates to Muhammad is faster. Don't reference the 2.5h session in the Monday demo context.

Contradictions & Flags

1. Section ordering change contradicts current plugin build: The current skill file defines sections in the order: property metadata → positioning thesis → concept direction → owner context → competitive set → asset assessment → rest. This session decided to move owner context, competitive set, and asset assessment to before positioning thesis. Shaheer needs to update the workflow definition. → Status: unresolved; requires prompt/skill update before Monday demo

1. "Upper upscale" vs. $160 ADR contradiction in RFP itself: The Marrakesh RFP contains an internal contradiction — it calls for upper upscale positioning but targets a $160 ADR, which is far below upper upscale market rates. The concept briefing tool surfaced this correctly (it flagged the mismatch and recommended increasing ADR). This is not a bug, but Vela needs a decision on how the tool should handle RFP-internal contradictions: flag and pause for human input, or proceed with its own resolution? → Status: unresolved; needs product decision

1. Time savings: phase 1 was previously unmeasured: Prior sessions only quantified execution phase time savings (phases 2+3). This session showed phase 1 is significant (Theo: "definitely quite a lot of time that they're spending") and the concept briefing tool might take similar time to the manual process before optimization. The "saves you hours on research" claim in the slides needs a real time measurement from a senior BD person doing the manual research phase. → Status: unresolved; measurement action item

Observations

• The tool output is genuinely impressive but the session experience is a blocker — Theo's 2.5h session would be immediately dismissed by Muhammad or Antony as "more work than just writing the brief myself"; fixing the pace is the top priority before the Monday demo, not feature additions
• Section ordering is a load-bearing architectural decision — the ADR mismatch issue demonstrates clearly that late market context corrupts earlier decisions that are hard to reverse; fixing the order is not a cosmetic improvement, it's a quality guarantee
• Context overfit is a calibration problem, not a fundamental flaw — the model is doing what it was told (ground in context documents); adjusting the instruction to give more weight to user steering vs. document anchoring is a straightforward prompt change
• The commercial terms section is a sleeper highlight — Theo's reaction ("it's not too bad") understates it; generating a term sheet that benchmarks against the owner's existing Hilton terms without being explicitly prompted is the kind of behavior that will surprise and impress Muhammad; worth calling out explicitly in the demo
• The memory mechanism concept is worth prototyping quickly — the 15-point rolling cap is clever; even a basic implementation (manual review rather than automated CLAUDE.md rewrite) would give the concept briefing tool a "gets better with use" story for the Kerten pitch, which addresses the AI maturity expectations gap identified in 2026-04-16 Antony Chief Experience Officer
• The ADR recommendation departure is a risk signal — the tool confidently recommended doubling the target ADR from what the client specified in their RFP; in the wrong hands, this kind of confident divergence could cause a BD team member to go to a client meeting with the wrong financial anchor; human review of financial outputs is not optional
• Maria's RFP observation unlocks a significant UX improvement — the insight that RFP = skip most questions is obvious in hindsight but wasn't in the original design; most Kerten proposals do come with some form of brief or RFP, so the with-RFP path may actually be the primary path, not a secondary one

Vela Internal Check-in — May 4, 2026

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory

Summary

Morning check-in before the Muhammad demo. Theo gave detailed feedback on concept briefing v2 — the new faster version is a step forward on UX but the bulk-generation approach produces shallower output than the iterative v1 session. The key design conclusion: add 2–3 intermediate form checkpoints mid-flow for concept, segments, and pricing so users review at key moments rather than at the end. Shaheer explained the SharePoint state management architecture (one row per proposal run, Power Automate trigger to kick off phase 2). The team also worked through the project north star: Vela's goal is to become Kerten's trusted AI advisor, not just to deliver the proposal tool.

Decisions Made

Proposal Generation System

• Intermediate forms required mid-flow. The current one-form-at-the-start UX produces high-level output because the AI runs through the full brief in one sweep without human course-correction. Theo identified 2–3 moments that must involve the user: concept direction, segment definition, and pricing hypothesis. These should surface as pre-populated forms the user can edit inline, not chat dialogue.

• Context engineering per section. Explicit per-section instructions needed on research approach — including telling the model to take its time and do thorough web research for data-heavy sections (e.g. ADR benchmarking). V2 skipped web research for benchmarks; V1 did it because the iterative pace gave the model more "thinking time" per section.

• SharePoint as the proposal state store. The pipeline is stateless; SharePoint becomes the central record for each run. One row per proposal: creator, concept brief, approved outline, generated documents, image bank. All parties (Muhammad, Sarah/Alysia, Shaheer) work off the same shared SharePoint list.

• Power Automate triggers phase 2. When the concept brief is saved to SharePoint, a Power Automate flow calls the backend to start outline generation. BD team receives an email with a link to the approval UI. This removes the need for manual file passing between phases.

• Past proposals ingested as markdown, ~50 max. PPT → plain text markdown. File sizes are minimal. For creative or one-off concepts, the model's own training data is more useful than past proposals — past work doesn't help with never-done-before ideas, and may suppress creativity by anchoring on precedent.

• No-RFP path: slash command → blank form. Without an RFP, users trigger the flow with the slash command, a blank form appears, and they fill in what they know. Same flow, different starting state — no structural changes needed.

Intelligence Hub

• Owner typology for Apollo needs clarification. Shaheer raised that "owner" surfaces as individuals, PE funds, developers, and consultancies in Apollo results. Action: ask Muhammad for a typology of owner types Kerten typically deals with, and what title to target within a company (vs. contacting the owner directly).

Key Topics

Concept briefing v2 — Theo's feedback

Theo tested v2 (v0.2.5) over the weekend and compared it to his earlier 2.5h iterative session.

What improved:

• Speed: night and day vs. the previous version
• Pre-populated form at the start: Theo strongly prefers this over chat-based back-and-forth; the model makes a hypothesis, writes it out in a form field, and the user edits directly rather than having a dialogue. "Much more interesting way of dealing with it."

What regressed:

• Output quality: more high-level, more repetition, concepts slightly redundant, customer profile narrow, pricing not well-defined. Not generic in the old AI sense — better than that — but not ready for the BD team as a concept brief.
• Root cause: bulk generation in one sweep vs. section-by-section. In the iterative session, the model had more time per section and the user was forced to engage at key moments. Without forced checkpoints, those moments don't happen.

Theo's design proposal: 2–3 intermediate forms after the initial intake. Each form surfaces the AI's hypothesis for a specific decision (concept, segments, pricing) as an editable block. User reviews, adjusts, and submits. All forms batch-submitted rather than waiting for a back-and-forth dialogue.

Past proposals as context

Theo asked whether the system ingests past proposals. Shaheer: extracts PPT text as plain markdown — file sizes are small, ~50 proposals feasible. Discussion on whether more is better:

• Theo's concern: unique concepts (e.g. a Nile cruise experience) won't appear in past proposals
• Shaheer's response: for genuinely creative one-offs, the model's training data is more useful than past proposals. A past proposal library could actually suppress novelty — the model has 5 examples of standard hotel concepts and 1 of the Nile cruise, so it weights standard patterns more heavily. Creative outputs should be left to the model's own creative range.

Testing coverage — fringe cases

Theo wants to test:

• Flow with no RFP at all ("I had a coffee chat with this guy, I need a thing, it's a hotel in this place")
• Edge cases: alpine resort in Italy (small, ~28 keys), fringe concepts like a boat on the Nile

Shaheer: no-RFP flow works — slash command triggers blank form, user fills in what they know. No structural difference in the system.

Phase timeline

• Phase 1: ~80% done. Remaining: intermediate forms + context engineering. Shaheer targets end of today (May 4).
• Phase 2: Start tomorrow (May 5). Primarily UI work. Target: done by Monday May 11.
• Phase 3: Bulk of engineering, most complex component. Bulk of remaining sprint.
• Intelligence hub: Begin ramping up on the tail end of the Phase 3 sprint.

Muhammad demo (this afternoon)

Marlo confirmed. Sarah/Alysia haven't responded. Theo planning to:

• Show side-by-side comparison: v1 output (thorough) vs. v2 output (faster, higher-level)
• Point to specific areas that still need refinement — make the iteration process visible so the client understands the effort involved
• Set up a Claude seat for Muhammad and one for Sarah or Alysia
• Ask BD team to test the flow themselves and provide more RFPs/concepts for diversity testing

SharePoint state management

Shaheer's architecture: the pipeline runs stateless, meaning there's no persistent memory between phases. SharePoint becomes the connective tissue:

1. User completes concept briefing → brief is saved to SharePoint list (one row per proposal run)
2. Row includes: creator, concept brief, approved outline, final documents, image bank
3. Saving the brief triggers a Power Automate flow → calls the backend → outline generation begins
4. BD team gets an email with a link to the approval UI

Theo confirmed this works for multi-user scenarios (Muhammad starts a brief, Sarah picks it up in the UI). Requires Douglas/Broad Vision for SharePoint access and Power Automate configuration.

Owner typology (Intelligence Hub)

Shaheer raised: Apollo returns a mix of individuals, PE funds, developer companies, and third-party consultants all described as "owner." Theo explained the landscape:

• Individual high-net-worth owner
• Investment firm (PE, mutual fund)
• Developer that builds and holds hotels
• Third-party consultant appointed by the owner to manage the RFP process

For companies, there's typically a project manager type running day-to-day; the senior decision-maker only appears for the final call. Some RFPs (like the Marrakesh one) have a consultancy as the owner's representative.

Action deferred to Muhammad: ask him for a full typology and what title to target when Apollo surfaces a company rather than an individual.

Stream 2 — AI ideas benchmarking

Theo wants to kick off a meeting with Michael, Marlo, and Kah. Before that meeting, needs:

• A benchmark of 4–5 well-researched stories of what other hotel groups are doing with AI (not a list — proper research, possibly phone calls with people who have intimate knowledge)
• A Kerten-specific ideas list (more creative, based on what Vela knows is possible)

Separate decision needed on discovery format: one-on-one interviews vs. a design thinking workshop (in Dubai, or possibly an offsite in Ireland). Maria to revise her preliminary list with this framing.

Stream 3 — AI Foundations

Mina confirmed for afternoon; Aman likely joining. Douglas invited. Theo's assessment: Stream 3 is relatively straightforward at this point — configure Claude for the organization, write a policy, design trainings. Maria is using a NASA AI policy as a base template and adapting it. Trainings are back-burner until policy is approved. Kerten has no existing data classification policy, so Maria will start with basics.

Project north star

Shaheer asked explicitly: what does success look like for this client?

Theo's answer (summarized): Success is not delivering the proposal tool. The tool's value is capped at the ~5 weeks Shaheer spends building it. The real value is the BD team evolving their AI fluency — understanding what AI can and can't do, developing their own ideas, and starting to experiment independently. If that happens, Kerten calls Vela for the next AI initiative. That's the measure of success.

On how to win trust: the scope covers 90% of the work. The other 10% is identifying a real pain point outside the brief and solving it unprompted — a quick win that surprises someone (Tara's legal work was flagged as a candidate). That's what converts a client from "useful contractors" to "trusted advisor."

Contradictions & Flags

1. Kerten minimum hotel size is flexible, not fixed: Shaheer understood Kerten doesn't take hotels below 50 keys. Theo clarified: they have guidance on key range but have made exceptions, especially at the lower end. The current 28-key Italy hotel is an exception that's going poorly and unlikely to be renewed — but the rule isn't as hard as previously assumed. → Status: resolved; intelligence hub scouting filters should apply a soft floor, not a hard cutoff

Observations

• The intermediate forms decision is the single most important output of this session — without it, the v2 fast mode will always produce shallow output because there's no forcing function for the user to engage at the moments that determine brief quality (concept, segments, pricing); this isn't a prompt calibration issue, it's a UX architecture issue
• SharePoint + Power Automate is the right state management call for this client — it meets Kerten where they are (already on SharePoint, Douglas managing it), gives the BD team a familiar interface for tracking runs, and avoids building a custom database that needs separate maintenance; the tradeoff is dependency on Douglas/Broad Vision's timeline for access
• The Nile cruise discussion resolved a latent tension in the past-proposals strategy — there was a risk of over-investing in proposal ingestion to maximize recall; Shaheer's argument (creative concepts need model creativity, not precedent retrieval) correctly limits the scope; ~50 proposals for structural grounding is the right ceiling
• Marlo's 10-hour dissatisfaction is an asset, not a problem — Shaheer correctly identified that her low baseline expectation gives room to exceed it; the demo strategy of showing before/after (GPT vs. current output) and making the iteration visible is the right frame; trying to claim the tool is "done" would invite scrutiny of remaining gaps
• The north star discussion surfaces a gap in how Shaheer has been framing the work — building within scope is necessary but not sufficient; identifying quick wins outside the brief (Tara, or similar) needs to become a background thread alongside the build, not something that happens organically
• Power Automate as the phase trigger introduces an IT dependency that could block phase 2 testing — Douglas/Broad Vision access to SharePoint and Power Automate needs to be confirmed before Shaheer starts phase 2 UI work, otherwise the backend is ready but the trigger mechanism isn't wired in
• The owner typology gap in Apollo is load-bearing for the intelligence hub build — the lead enrichment and outreach targeting logic depends on knowing what "owner" means and what title to surface; deferring this question to Muhammad is correct, but it must be answered before the Apollo/Clay integration is designed

Weekly Progress Review — May 4, 2026

Attendees

• Muhammad Yacoubi — Senior Director BD (Kerten)
• Marloes Knippenberg — CEO (Kerten)
• Cathal O'Shea — Owner's Representative (Kerten)
• Sara Granieri — BD Executive Europe (Kerten)
• Alicia — BD Executive (Kerten)
• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory
• Shaheer Ahmed — Vela Advisory (Tech Lead)

Summary

First live demo of the concept brief tool to the extended BD team, including Sara and Alicia as future heavy users. Theo walked through two versions: v1 (conversational, ~2.5 hours) and v2 (form-based batch input, ~5-10 minutes) using a Marrakesh five-star resort RFP. Marloes joined and asked substantive questions about collaboration, CAD drawing enhancement, and what the tool can and cannot do. CoStar API access was confirmed permanently unavailable by the CoStar support team.

Decisions Made

Proposal Generation System

• Knowledge base: good proposals only (~10-15). Only high-quality past proposals should go into the training library. Bad proposals should not be included — the model autocompletes toward examples it's given.
• Qualitative curation over win/loss. Cathal proposed labeling proposals by quality, not just win/loss outcome, since some losses were due to non-content reasons (no guarantee given, not content quality).
• Sara to coordinate proposal collection from Muhammad, Antony, Alicia, and Marloes.
• CoStar manual download confirmed permanent. CoStar has no API; comp set data must be manually downloaded and uploaded by the user. Claude may help identify the comp set but cannot pull data.
• Outputs of phase 1 confirmed to client: concept brief PDF + Excel financial model (populated from user-uploaded CoStar data) + commercial terms Word document.
• Collaboration model: phase-level handoff only. The tool is not natively collaborative within a session. Documents (emails, RFPs, meeting notes, Harsha's inputs) can be bulk-uploaded as context at the start. Phase handoffs are the primary point of ownership transfer between users.

Intelligence Hub

• Not discussed in this session.

Key Topics

Tool Demo — v1 vs v2

Theo demonstrated both iterations using the Marrakesh RFP. V1 was fully conversational: each exchange triggered a 5-minute processing cycle, totalling ~2.5 hours. V2 uses a form that batches all initial questions, reducing the session to 5-10 minutes with a slightly less detailed but substantially faster output. Vela committed to sharing both output files and giving Muhammad, Sara, and Alicia test access immediately after the call.

Collaboration and Handoff

Marloes asked whether multiple people could contribute different sections to one brief. Shaheer clarified: phase 1 is a single-user workflow by design. Handoff between phases is possible — one person does the concept brief, another picks up at outline generation. Bulk-uploading email chains, meeting notes, or Harsha's technical annotations provides a multi-stakeholder input mechanism before the brief is run.

CAD Drawing Enhancement

Alicia and Marloes raised the need to make Harsha's CAD floor plan annotations look more polished in presentations. Muhammad gave the Casablanca example: color-coded CAD drawings were impactful for the pitch despite looking clinical. Shaheer flagged that Anthropic recently announced MCP connections with CAD/3D tools (Blender, AutoCAD variants). He committed to exploring SVG-based rendering as a potential approach this week and reporting back at next Monday's meeting. He was explicit that this is cutting-edge and he cannot yet commit to what is achievable.

Proposal Library Curation

Marloes estimated 10-15 high-quality past proposals exist that could anchor the knowledge base. Shaheer confirmed ~12 is a good target — too many examples risks over-fitting toward specific patterns; bad examples should not be included because the model will autocomplete toward them. Cathal suggested qualitative labels ("best pitch," "had shortcomings") over binary win/loss.

CoStar API

Permanently unavailable. CoStar support confirmed no API access exists. Shaheer noted their infrastructure appears very dated. The Excel financial model will be populated when the user manually downloads and uploads CoStar data; the workflow will handle populating the template from there.

Knowledge Base Architecture

Sara asked whether the tool's knowledge base would be shared across users. Yes — the knowledge base (past proposals, protocols) sits on a shared SharePoint owned by the BD team. Each new session starts fresh but draws from the same central library. Individual session outputs (concept briefs, proposals) will also be stored in a shared folder accessible to the team.

Contradictions & Flags

1. Excel population timing communicated incorrectly to the client. Theo told the group that the Excel financial model is generated in phase 1. Shaheer's design validates assumptions in phase 1 but populates the Excel via a script in phase 3. Shaheer flagged this internally after the call. Not a contradiction in intent but a miscommunication of timing to the client. → Status: Theo and Shaheer aligned post-call; Excel validation in phase 1, Excel population (script) in phase 3.

Action Items

• Theo: Set up Claude test accounts for Muhammad, Sara, Alicia immediately after call.
• Sara: Coordinate collection of 10-15 best past proposals from Muhammad, Antony, Alicia, Marloes.
• Shaheer: Explore CAD/SVG tool integrations (Anthropic MCP connections with Blender/AutoCAD); present findings at next Monday's meeting.
• Theo/Shaheer: Share Marrakesh concept brief output files (v1 and v2) with the team.
• Vela: Continue conversation with Mina, Aman, and Douglas to get Claude enterprise access for Kerten.

Vela Internal Check-in — May 5, 2026

Attendees

• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory
• Shaheer Ahmed — Vela Advisory (Tech Lead)

Summary

Debrief of the May 4 weekly progress review and first Kerten BD team demo. The main substantive content was a significant architecture debate: whether Excel financial modeling and commercial terms should be separate phase 1 skills, whether phases 1 and 2 should be merged, and whether the outline review UI should be expanded to show slide-level copy and image suggestions before generation. Excel and commercial terms were agreed to move to phase 1. The phase merge question and UI scope expansion were both deferred to Thursday's in-person session.

Decisions Made

Proposal Generation System

• Excel financial model added as a separate phase 1 skill. Not within the concept brief conversation — a separate Claude session that reads the finalized concept brief MD file, handles the Excel template format, and produces the populated financial model.
• Commercial terms added as a separate phase 1 skill. Same pattern as Excel: separate conversation, reads the concept brief MD, produces the Word document output using legal's existing template.
• Claude access for Kerten testers. Theo will create Gmail accounts and pay for $20/month personal Claude Pro subscriptions for Muhammad, Sara, and Alicia. Shaheer to create the Gmail accounts. Personal accounts can connect to the GitHub marketplace plugin for auto-sync. Treated as a temporary workaround until Kerten's enterprise access is approved.
• CAD/SVG exploration assigned this week. Shaheer will test SVG-based floor plan rendering and Anthropic's new MCP connections with Blender/AutoCAD-type tools. Will report findings at next Monday's meeting. No deliverability commitment made.
• Phase merge and UI expansion scope deferred to Thursday in-person session. Both open questions have significant build implications; decision will be made in person.

Intelligence Hub

Not discussed in this session.

Key Topics

May 4 Demo Debrief

Overall positive reception from the Kerten team. A technical glitch (form didn't render on Shaheer's demo) was handled by Theo showing a prior conversation as a substitute. Shaheer will push the final version of the concept brief tool with last edits within hours. Test access will be set up for Muhammad, Sara, and Alicia immediately after.

Claude Access for Kerten Testers

Vela's Teams subscription is domain-restricted; Kerten staff cannot be added. Theo will create Gmail accounts and pay individual Pro subscriptions. Maria raised shadow AI concerns — using accounts outside IT-approved tooling. Acknowledged as a temporary workaround; Theo will include a disclaimer. Enterprise access for Kerten via Mina, Aman, and Douglas remains the real solution.

CAD Drawing Enhancement

Shaheer briefed Theo on Anthropic's recent MCP connections with CAD/3D tools (Blender, AutoCAD variants). He proposed SVG-based rendering as a more achievable middle ground: Claude generates vectorized drawings natively rather than editing raw CAD files. Theo was uncertain whether the tooling handles what Kerten actually needs (floor plan annotations, not from-scratch architecture). Shaheer committed to testing this week and reporting at next Monday's meeting, explicitly with no commitment on deliverability.

Architecture: Excel and Commercial Terms in Phase 1

Theo proposed a separate skill within phase 1 — not within the concept brief conversation — that generates the Excel financial model and commercial terms document, both reading the finalized concept brief MD as context. Shaheer agreed. This is technically clean (no additional context load on the concept brief conversation), and it resolves the May 4 miscommunication where Theo told the client Excel would be a phase 1 output.

Architecture: Phase 1 and Phase 2 Merge

Shaheer raised the consequential question: if Excel, commercial terms, and outline generation can all be phase 1 skills feeding off the concept brief, why build a separate phase 2 UI at all? Theo's framing: phase 1 = ideas and analysis in raw form; phase 2 = the narrative (what goes in the proposal); phase 3 = click-and-generate execution. Conceptual separation still matters. Shaheer flagged that merging makes the product look simpler, which is a commercial risk. Not resolved — deferred to Thursday in-person.

UI Scope Expansion

Theo proposed expanding the outline review UI to show three elements per slide: (1) the selected layout template, (2) editable copy, and (3) image suggestions with swap/upload capability. Shaheer's concern: with five weeks total and phase 1 not yet complete, this UI is heavy work. Layout editing in particular risks scope creep — once users can see layouts, they will want to edit them. Agreed to constrain layout selection to the existing template library (no generative layout prompting). Shaheer asked for until Thursday to assess feasibility. Theo's core motivation: avoid the cycle of generating a 20-minute PowerPoint only to discover wrong images and layout choices post-generation.

Proposal Library Curation Confirmed

Re-confirmed from May 4: only 10-15 best proposals should go into the knowledge base. Bad examples explicitly excluded — the model autocompletes toward all examples it's given, including poor ones. Sara to coordinate collection from Muhammad, Antony, Alicia, and Marloes.

Contradictions & Flags

1. Excel timing miscommunication now resolved: The flag from 2026-05-04 Weekly Progress Review — Theo told the client Excel would be generated in phase 1 while Shaheer's design had it in phase 3 — is resolved by this session's decision to add Excel as a separate phase 1 skill. What Theo told the client now matches the architecture. → Resolved.

1. Phase 1 scope is expanding significantly mid-build: Original phase 1 = one concept brief skill. After this session it includes: Excel financial model skill, commercial terms skill, and possibly outline generation. Shaheer flagged that this pushes the end-of-week completion target. → Unresolved; Thursday session will scope.

Observations

• The "separate skill reading the concept brief MD" pattern is the de facto architecture: Every new phase 1 capability (Excel, commercial terms, potentially outline) follows this model — independent conversation, shared state via the MD file. This is clean but means phase 1 is now a multi-session suite, not a single workflow. How this is communicated to Kerten matters.
• Theo's proposed UI expansion is approaching mini-PowerPoint editor territory: Editable copy, image selection, and layout swapping before generation is functionally what Pitch and Canva already offer. Shaheer's scope concern is valid and distinct from his earlier objections to UI complexity — this time it's not about logic but about the front-end surface area needed to make it work reliably.
• The Thursday in-person is a critical product checkpoint: Phase merge, UI scope, and timeline are all open simultaneously. If these three decisions go in different directions, the phase 2 and 3 build may need to restart. This meeting needs a concrete output document.
• Shadow AI risk was flagged and deprioritized: Maria correctly noted that Gmail-based Claude accounts bypass Kerten IT policy. Theo's response — don't tell the IT team — is a reputational risk if it surfaces, particularly given Kerten's close relationship with Douglas at Broad Vision, who manages their SharePoint and is aware of the project.
• The form rendering glitch during the demo is a reliability signal: The form-based input is the single biggest UX improvement over v1. If it fails during internal testing or a follow-up demo, confidence in the tool degrades quickly. Needs explicit testing before the next client touchpoint.
• Shaheer's SVG proposal is technically grounded: Claude demonstrably generates high-quality SVGs (shown in the intelligence hub architecture diagram session). The open question is whether CAD-specific constraints — floor plan scale, annotation accuracy — can be approximated well enough for Harsha's context, where clinical accuracy is the whole point.

Vela Internal — Financials Walkthrough — 2026-05-06

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Theo Breward — Vela Advisory

Summary

Working session walking through the Excel financial templates Vela has been given by Kerten BD. Shaheer needed Theo's modeling background to interpret the sheets before specifying how the Financial Agent should generate them. The session surfaced four substantive issues: (1) the CoStar export Vela has is just a final comp set, not the raw data the model needs; (2) the BD template has been edited with Claude-in-Excel without anyone disclosing this; (3) the BD template and Karolina's template are different models, and it is unclear which is canonical; (4) a much more detailed model with manning/salary/employer-tax sheets exists in the shared folder, suggesting Vela has been working from an incomplete picture. The session ended with a clear agreement to redirect financial validation away from Karolina and onto Alicia + Aman, and a defined list of questions to send.

Decisions Made

Proposal Generation System

• Karolina is out of the picture for the financial template work. The model Vela needs to automate is a BD template, not Karolina's. Karolina barely receives it. Validation moves to Alicia (BD owner) and Aman (CFO sign-off). Karolina's domain is CoStar/comp set, not the financial model itself.
• Two questions to Alicia (email + meeting request): (1) which CoStar exports do you actually use — what we have looks like a final comp set, not raw data; (2) the BD template and Karolina's PNL template are different — which is the latest, which should we automate against? Shaheer to send today.
• Validation sequence: Alicia first (verify documents + how they handle template exceptions) → Aman second ("if we fill this sheet out, are you happy, or will you still ask follow-up questions?").
• Template architecture: fixed structure, variable input. The Excel template the Financial Agent produces should never change shape between proposals. Variability is handled by leaving empty slots that resolve to zero when unused — multiple room categories, multiple restaurants, multiple meeting spaces, additional residence/villa/glamping types. Calculations downstream still resolve correctly with zero values.
• All variable values live in the assumption sheet. Nothing variable should be hardcoded in the monthly P&L. The current BD template hardcodes 0.35 (room service / breakfast?), 0.15 (FNB uplift per restaurant), 0.20 (meeting space uplift), 12%/14.5% rooms-dept variable cost, and 50%/25% inhouse-vs-third-party margins directly into formulas. If BD ever tweaks these per-proposal, the AI tool needs to know — they need to surface those values into the assumption sheet so the agent can populate them.
• AI agent must produce a one-line justification for each assumption it sets. Theo's framing: "we put 15% because beachside mid-range hotels in the Mediterranean typically charge that." This is what makes the AI's assumption-setting trustable to a BD reviewer who would otherwise default to their own bias.
• Training source for assumption logic: prior pitch-decks paired with their corresponding P&L sheets — the agent learns which assumption profiles map to which property archetypes from completed historical proposals.
• Currency and inflation are unanswered assumption-source questions. AED-EUR rate is hardcoded — where do they fetch it (day-of, monthly average, annual)? Inflation rate is 2% — when does it change? Whatever source they use, the agent must use the same source. Add to Alicia question set.

Intelligence Hub

• Not discussed in this session.

Key Topics

What's actually in the shared folder

Files inspected: co-star export six (single sheet — just the final comp set, not the raw CoStar export), STR census (resembles a Lighthouse export, not CoStar), an empty Excel file, Karolina's P&L template, the BD-team template, and (discovered late in the call) a separate "financial projections" folder under the client BD materials with much more detailed models including Manning sheets. Theo's read: Vela does not have a proper CoStar report at all, and the model Vela has been told to automate against may not be the actual model BD uses for complex proposals.

"This was made by Claude"

The BD template has a yellow-cell-as-input convention with an explanatory note in the format Theo recognised as Claude-generated (the explainer comment phrasing and the yellow-circle convention). Confirms someone in BD has been using a Claude Excel add-in — without disclosing it in any of the stakeholder interviews. Theo: "Someone's got the cheeky has been using Claude without telling anybody." Best read: BD asked Claude to redesign the input sheet only — the monthly P&L view appears unchanged from the underlying model.

Two competing templates

Karolina's P&L template: simpler, single room category, no Claude markers. BD's template: more complex (rooms + residences as separate categories), Claude-modified input sheet, different assumption set. Numbers do not match between them. Which is canonical for the agent to generate is unanswered — this is question two on the list to Alicia.

Template versatility

The current BD template handles a maximum of two room categories (rooms + residences). Real proposals will hit cases with three or more categories — villas, glamping, residence tiers, premium room classes. Decision: build the template with extra empty slots that zero-out when unused. Same logic for restaurants, meeting spaces, other operating departments. The concept ADR residences label is also hardcoded — needs to be dynamic so the same slot can be relabeled villas for a Marrakesh-style RFP.

The restaurant uplift formula is broken

BD models restaurant revenue as 15% × number_of_restaurants × room_revenue. With three restaurants this becomes 45% of room revenue, with ten restaurants 150%. This doesn't reflect reality — guests don't eat at three restaurants per night. The 15% benchmark only makes sense as a per-guest spend on F&B inside the property, independent of restaurant count. External-guest revenue (which would scale with restaurant count) is a different driver and not captured. Either the BD assumption is wrong, or it is right only for one restaurant — needs Alicia clarification.

The Manning sheet rabbit hole

The shared folder contains detailed manning sheets with per-position salaries, headcount, employer taxes, and gross-salary multipliers. Two examples differ structurally: one uses a flat 25% employer tax (Dubai/UAE pattern), another uses a tiered gross-salary multiplier with thresholds at 5,000 and 12,000 (looks French/European). This depth is absent from the BD template Vela was given. Either (a) BD strips this out for proposal purposes, or (b) there's a fuller model that BD passes to Aman that Vela hasn't seen. Needs explicit confirmation.

Hardcoded values that may or may not be tweakable

The BD monthly P&L hardcodes a list of "industry standard" values directly into formulas: 12%/14.5% rooms variable cost (size-driven), 50%/25% in-house-vs-third-party margins, 2.7% admin & general, 35% F&B room-service base, plus the restaurant/meeting-space uplifts. Theo's pivotal question: do these ever change between proposals? If never — fine, the agent leaves them alone. If sometimes — they need to migrate into the assumption sheet so the agent can populate them, otherwise the agent will silently produce wrong numbers.

The "experiences" gap

Concept briefs generate proposed experiences (creative direction). The financial model has no row for experience revenue — only rooms, F&B (as % of rooms), meeting space, and other ops. Theo's position: experiences are add-ons, ADR is strictly key-revenue, so the gap is a property of how Kerten chooses to model, not a build issue. But the concept-brief → financial-agent handoff loses information here — worth flagging.

Contradictions & Flags

1. Karolina's role on the financial model — reversed: Project context (and meetings/CLAUDE.md stakeholder table) says Karolina validates financial model assumptions and is the CoStar expert. This session: Karolina is out of the picture for the BD financial template — it's a BD-owned artifact she barely sees. She remains the CoStar/comp-set expert. → Status: needs clarification — likely split (Karolina = CoStar/comp set, Alicia + Aman = financial template/assumptions). Update stakeholder mapping.
2. BD has been using Claude on Excel without disclosing it: None of the prior BD interviews (Alicia, Sara) mentioned this. Either (a) only one BD person uses it and it didn't come up, or (b) BD's stated AI maturity in stakeholder interviews was understated. → Status: open — implications for change-management messaging when Vela's tool ships.
3. Two different financial templates in circulation (BD vs. Karolina) — canonical version unknown: → Status: pending Alicia response.
4. CoStar export Vela has is the comp-set output, not the raw data the model consumes: Vela has been planning the Financial Agent assuming the CoStar export contains ADR, occupancy, and seasonality — it doesn't. → Status: pending Alicia response. Compounds the existing CoStar API blocker — even with API access, Vela needs to know the right export shape.
5. A more detailed Manning/salary model exists in the shared folder, never surfaced in stakeholder interviews: → Status: open — needs explicit confirmation that BD's "complex proposal" actually uses this depth.
6. Hardcoded "industry standard" values in monthly P&L — tweakability unknown: If they're ever tweaked per-proposal, the assumption sheet is incomplete and the agent will produce wrong numbers. → Status: pending Alicia response.
7. Restaurant revenue uplift formula does not scale with restaurant count: 15% × n_restaurants gives 45% at 3 restaurants, 150% at 10. → Status: pending Alicia clarification.
8. Concept-brief experiences have no revenue line in the financial model: → Status: open — likely accept as Kerten's modeling choice, but document the handoff loss.

Action Items

• Shaheer: send email to Alicia today with two questions (CoStar export shape + canonical template) + request a 30-min call. Add currency/inflation source questions to the same thread.
• Shaheer: audit formula dependencies in the BD template (Trace Dependents) to map where each cell pulls from before the Alicia call.
• Shaheer → Theo: after Alicia call, plan the Aman validation session.
• Shaheer: investigate the financial-projections folder and Manning sheets — confirm whether any of that is in scope for the agent build.

Observations

• The "Karolina validates financials" assumption has been load-bearing in our system design and is now wrong. Multiple prior summaries treated Karolina as the financial sign-off node. This session reframes her as the CoStar/comp-set node only. Aman is the financial sign-off, and Alicia is the template owner. The Phase-3 human checkpoint described in the project CLAUDE.md ("Karolina validates financial model assumptions") needs to be re-pointed — likely to Alicia for assumption review, Aman for executive sign-off.
• Discovery that BD is using Claude in Excel changes the AI-maturity baseline for the project. Earlier stakeholder interviews painted BD as AI-curious-but-not-yet-using. Reality is at least one person already has a Claude workflow inside their Excel. This is good news for adoption (less novelty resistance) and bad news for the "we will introduce AI" narrative — Vela isn't introducing it, just systematising it.
• The CoStar block is now a definition problem as well as an access problem. Even when Theo eventually gets API access, Vela does not yet know which export shape the model needs. Resolving the API account without resolving the export-shape question doesn't unblock Phase-3 build. The Alicia question on this is therefore on the critical path.
• The "fixed template, variable input" architecture decision is the right one and should be lifted into the design doc. It's also what should drive the Financial Agent's behavior: pick which slots to populate based on the concept brief, leave the rest at zero, never restructure the sheet itself. This is a design constraint worth pinning down before build, not after.
• "Hardcoded values may or may not be tweakable" is the highest-stakes unknown in the financial agent build. If BD never tweaks the 35%/15%/20%/12-14.5%/50-25% values, the agent has a tractable scope. If they do tweak any of them per-proposal, every untweaked-by-the-agent value is a silent error in the output. The Alicia call must produce a definitive list. Worth a question on its own line.
• The Manning sheet discovery is the second time this engagement has uncovered "there is more model than we were shown." First time was Karolina's CoStar workflow vs. Sara's financial-model workflow (resolved as two separate agent calls). Pattern: BD describes its own subset of the work and assumes that's the whole picture. Worth probing for "what other sheets do you have?" as a default question with every BD stakeholder.
• The restaurant uplift formula problem is a tell. A formula that produces 150% room-revenue at 10 restaurants would have been flagged by anyone who ran the numbers across proposals with multiple F&B outlets. That it hasn't been suggests either (a) all their proposals are 0–1 restaurant cases, or (b) someone overrides the formula manually in those cases. Both possibilities are diagnostic of how mature the existing template actually is.
• Aman re-emerges as the critical financial gatekeeper. The session lands on Aman as the final review. Aman has not been responsive (per 2026-05-06_Vela_Checkin). Booking that validation conversation may be the slowest item on the Phase-3 critical path — worth opening that thread before the Alicia call lands.

Vela Internal Check-in — 2026-05-06

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory

Summary

Shaheer demonstrated HTML-rendered concept brief mockups (dashboard, magazine, pitch-deck styles) and floated replacing PPTX with an HTML→PDF deliverable for phase 2. Theo rejected the pivot — too risky for a 5-week sprint and user comfort issues with Michael — but accepted HTML as the right format for the concept brief itself, in dashboard/report style rather than slideshow. Image workflow shifted from bulk pre-search to per-slide API calls for accuracy. Stream 2 (operations) AI use case list was revised by Maria; Lily template blocker still unresolved.

Decisions Made

Proposal Generation System

• Stay with PPTX assembly route for final deliverable. Do not pivot to HTML→PDF. Reasons: VC money is being poured into this problem and no one has cracked it cleanly; users (especially Michael) will perceive lost capability vs. PowerPoint they have used for years; not solvable in a 5-week sprint. HTML pitch-deck approach is technically sound but out of scope.
• Concept brief display: HTML dashboard/report format, not slideshow. The concept brief is not the proposal copy — only vision/mission carry over verbatim; everything else is adapted at outline stage. A slideshow format risks blurring this distinction in the user's mind.
• Image workflow inverted: per-slide API calls at compose time, not bulk pre-search. Earlier plan was to bulk-search ~100 images at concept-brief time using positioning thesis/mission/vision/creative direction, then match to slides. Theo argued 100 images is too narrow to cover slide-specific imagery (e.g., a slide on rejuvenating spa needs essential-oils imagery, not generic spa exteriors). Compute cost accepted as the price of accuracy.
• No image swap-out in outline UI. Outline stage UI lets the user reorder/add/remove slides and pick a template per slide, but does not surface or let them edit images. Image edits happen in the final PPT. Reason: too many failure points in a UI swap path.
• Backend research agent restructured. Separated into its own agent; narrowed result volume (was returning 50–70 web search results); now feeds context back into the main conversation at defined intervals rather than all at once. Performs more accurately on less context.
• Comp set generation needs fine-tuning. Marrakesh test surfaced Royal Mansour (luxury, ~$1,700 ADR) alongside $60 hotels in the same comp set. Causes: prompt instructions too loose, plus ADR data hallucinated without CoStar. Tighter narrowing needed.
• Roll out current markdown concept brief to testers today; HTML upgrade tomorrow. Avoid pushing the HTML view in the first install — let testers see the markdown version first, then experience the HTML aesthetic upgrade as a delight moment. Shaheer to revert the recent HTML push.

Intelligence Hub

• Not discussed in this session.

Other (Stream 2 — Operations / Stream 3 — Policy)

• Stream 2 use case list revised to: booking agent, journey orchestrator/butler/companion, AI community engine, operations copilot, revenue scanner. Maria to deliver as a table with plain-English description and an "expected benefit" column.
• Benefit framing rule: non-revenue outcomes (waste reduction, time saved, NPS improvement, return customers, sense of belonging). Direct revenue framing reserved for the revenue scanner only.
• Friday target: present framework + 1–2 concept slides per use case to Cathal, Michael, Marloes.
• BCG training materials assessment: "borderline shocked" — quality is poor. Theo has not uploaded them yet. Maria will still review for delivery-format ideas, not content.

Key Topics

HTML output exploration for concept brief

Shaheer built three HTML rendering mockups: dashboard, magazine-editor style, and pitch-deck slideshow. The pitch-deck one prompted the question of whether phase 2 itself could move to HTML templates. Theo's position: HTML is the future format for written records (PowerPoint is mis-used as a written record when it was designed for oral presentations) but the market has not solved HTML→PowerPoint conversion. Tools like Gamma and Genspark write in HTML and export to PPT but the export is imperfect. For this engagement: HTML for the concept brief display only; PPTX for the final deliverable.

Concept brief vs. proposal copy

Important system design separation. Vision/mission go from concept brief into the proposal verbatim. Everything else is adapted at outline/compose time. The display format of the concept brief should reinforce this — a dashboard/report makes it clear this is a planning artifact, while a slideshow risks the user thinking the slideshow IS the proposal.

Outline-stage UI scope (unresolved)

Yesterday's discussion (per Theo) suggested users should see the actual copy and image options at outline stage, click compose, and the tool fills slots. Shaheer pushed back: outline stage shows structure only (chapters, slides, template choice), no copy preview. User sees copy in the final PPT and edits there. Not fully aligned — flagged below.

Image selection workflow

Shaheer wanted to bulk-search at concept-brief time and reuse the same image bank across all slides. Theo countered with a specificity argument: slide content is granular (e.g., a specific spa treatment), and a 100-image generic library will produce visually mismatched results. Decision was per-slide search at compose time. Each slide will: (1) extract topical intent from copy, (2) prompt for recommended imagery type, (3) Pinterest API call, (4) select best, (5) populate.

Comp set quality issue

Marrakesh test produced a comp set spanning $60 to $1,700 ADR including Royal Mansour. Two contributing causes: instruction prompts not narrow enough, and CoStar still blocked so ADR figures are hallucinated. Tracked under existing CoStar-blocker thread; instruction tightening is a separate fix.

Financial commercial terms next

Phase 1 still needs the financial terms / commercial terms component built. Shaheer wants a 30-min session with Alicia or Sara on the new financial template. Theo will first walk Shaheer through the financial side himself this afternoon (after 2:30) — Theo argues the work is "vanilla" and his BCG experience covers most of Shaheer's questions, so the BD-team session may not be needed.

Stakeholder responsiveness blockers

• Cathal: hasn't replied to WhatsApp setup ask; was supposed to schedule the Broad Vision meeting.
• Mina: not answering on the Broad Vision sync.
• Aman: doesn't answer.
• Lily: still no templates a week after request. Suspicion: templates don't exist; Sara and Alicia have both said so; Lily said they exist on Apr 15 but may have meant "you should assume they exist."

Contradictions & Flags

1. Outline-stage copy visibility: Theo (May 5) suggested user sees copy + image options at outline stage; Shaheer (today) maintained no copy review until the final PPT. → Status: unresolved — needs explicit alignment before phase 2 build
2. Image workflow inverted from earlier plan: prior design was bulk pre-search ~100 images at concept-brief time; now per-slide API calls at compose time. → Status: resolved this session
3. HTML→PDF as alternative to PPTX assembly: considered and rejected this session. → Status: resolved — stay with PPTX
4. Concept brief display conflated with proposal output: Shaheer's pitch-deck HTML mock blurred the line between concept brief and final proposal copy. → Status: resolved — concept brief renders as dashboard/report
5. Lily templates may not exist (existing flag, escalated): Lily said templates exist (Apr 15); Sara and Alicia said they don't. A week after request, Lily has delivered nothing. → Status: unresolved — Shaheer to WhatsApp, Theo to work network

Observations

• The HTML-vs-PPTX decision is a discipline check, not a technical one. Shaheer correctly identified that HTML→PDF would simplify the build and produce more flexible output. Theo correctly identified that solving this in 5 weeks is not realistic given that better-resourced teams have not, and that Michael's perception of "lost capability" would dominate any technical merit. Holding the line on PPTX preserves the engagement's deliverability — this is the kind of choice the project is most likely to regret if reversed mid-flight.
• The image workflow change has real cost implications. Per-slide API calls multiply Pinterest/Apify spend by the slide count for every proposal. The build-cost analysis from earlier this week assumed a different volume. Worth re-running cost estimates with the new model before locking in.
• Concept brief display format is the first user-perception artifact testers will see. The decision to ship markdown today and HTML tomorrow is a small psychological play that is worth doing — first-install perception will anchor how Muhammad/Alicia/Sara discuss the tool internally. The HTML upgrade then becomes a "they're moving fast" signal rather than the baseline.
• The outline-stage copy-visibility disagreement matters more than it looks. If users only see structure at the outline gate, they have no checkpoint between "approved chapter titles" and "final PPT" to catch off-tone copy. If they see copy at outline stage, the UI complexity grows substantially. This is the same trade-off as the image swap-out debate, and the answer should be consistent across both.
• Comp set hallucination is the third surfacing of the CoStar block as a quality risk. Without CoStar, ADR data is unreliable; with unreliable ADR, the financial model and the comp set both degrade. This is no longer a "blocker" item to track passively — it's actively shaping output quality in tests.
• Lily template situation needs to be forced to a clear "no" before phase 2 build. A week of silence with the suspicion that the templates don't exist is the worst state — neither blocked nor unblocked. Getting an explicit "we don't have these" lets the project pivot (build them in-house as PPTX or HTML) without political fallout. Theo's framing is right: the goal is to get them to say it.
• Theo's financial-template self-walkthrough offer is a velocity move worth taking. Skipping the Alicia/Sara session compresses a 1–2 day stakeholder-coordination loop into a same-afternoon conversation. Risk: Theo's BCG-derived mental model may miss Kerten-specific assumptions. Mitigation: keep the BD session as a fallback if questions surface.

Business Development Executive — Alicia — Financial Walkthrough — 2026-05-07

Person

• Name: Alicia (also covered in 2026-04-15 Alicia Business Development Executive)
• Role: Business Development Executive, Kerten Hospitality
• Tenure: 2.5 years
• Position in this session: Subject-matter source for the financial template Vela is targeting in Phase 3. Walking Theo and Shaheer through the BD-owned Excel and the CoStar workflow that feeds it.
• CoStar account holders at Kerten: Alicia, Sara, Ramine, Karolina

Inputs

• A request from senior BD (Muhammad / Anthony / Ramine / Hassan) to build a proposal — the financial step is invoked once the concept and brand are decided
• Concept-side decisions that drive the financial inputs: number of keys, residences yes/no, glamping yes/no, number of FNB outlets, meeting space yes/no
• Aman's input on growth-rate curves when the proposal is being walked through

Her Process

Step 1 — Build the comp set in CoStar

• Open CoStar website → Properties section → filter by number of keys, location, category/star rating
• Manually pick 4–6 comparable properties as the comp set
• If CoStar's coverage in the market is thin (Alicia's words: "sometimes there's not enough properties") → switch to manual research on Booking.com / Expedia to find candidate hotels and pull their monthly published rates plus seasonality
• Export the comp set; the exported workbook has multiple tabs but Alicia uses two: the comp tab (occupancy + ADR averages) and the last tab (names of comp set + monthly view)

Step 2 — Pull the market benchmarks

• From the CoStar export's comp tab: take the average occupancy and average ADR across the selected comp set
• For markets where CoStar is short on data: ADR comes from Lighthouse; occupancy still has to be derived manually from Booking.com / Expedia, since Lighthouse does not return occupancy

Step 3 — Open the financial template

• The BD team has switched from the old Casadora template (very detail-oriented, requires lots of manual input) to a new template called the hotel BNL model, which the finance team built
• The new template was updated "just now last week" to add the residences component (the original BNL model lacked residences)
• The version Vela has was sent by Karolina; Alicia confirmed it includes the residences component

Step 4 — Populate yellow-cell assumptions

• Yellow cells = inputs / assumptions to populate. Most of the rest is automatic
• Currency: AED–EUR exchange rate looked up online each time (no fixed source)
• Inflation: 2% by default — applies in 90% of cases; only changed when a specific country's rate diverges meaningfully
• Comp-set ADR + occupancy per month → from the CoStar export
• Growth-rate curve for ADR / occupancy → starts from a base derived from previous proposals in similar countries; Aman validates and adjusts. Country-level events (Alicia's example: World Cup in Morocco) bump specific years
• Hotel positioning premium/discount: −20% to +20% applied against comp-set ADR and occupancy. Reflects Alicia's read of how the proposed concept compares to the comp set (e.g. smaller property → easier to fill → +10% occupancy premium)
• Number of keys, residences, glamping, F&B outlets, meeting space → from the concept

Step 5 — Validate growth rates with Aman

• Alicia plugs in a base growth-rate curve before the call, then Aman either signs off or adjusts up/down (Alicia's words: "we always start with a base… then we check with him")

Step 6 — Hand to the operations team

• This is a preliminary P&L. After the owner signs the proposal, it propagates downstream — operations needs the final delivered numbers to be close to what was shown in the proposal, otherwise it is "a nightmare" for them. The new template is faster but less detailed than Casadora; the team's working assumption is the two produce comparable results

Tools Used

• CoStar — primary source for ADR, occupancy, comp set. Web interface is slow and outdated; backed by PKF data
• Booking.com / Expedia — manual fallback when CoStar coverage is thin; gives published monthly rates and seasonality, no occupancy
• Lighthouse — fallback for ADR only; does not provide occupancy
• Excel — hotel BNL model — the current BD financial template (residences added last week)
• Excel — Casadora — the old detail-oriented template, being phased out
• Google — exchange rate and inflation lookups, ad-hoc

Outputs & Handoffs

• Filled-in hotel BNL model spreadsheet with comp-set, growth, positioning, FNB, residences, and assumption inputs populated
• Goes to Aman for growth-rate sign-off
• Final numbers feed the proposal deck and downstream are taken on by the operations team after signing

Approvals & Back-and-Forths

• Aman is the validator for growth rates and the broader financial model. Alicia explicitly: "for sure he approved" the formulas in the new template
• The new template's formulas were authored by someone in finance (not Aman directly), but Aman has signed off
• BD has been giving comments on the new template as they use it (e.g. specialty restaurant range moved from 0–1 to 0–3); the template is described as still in flux

Time & Volume

• Not quantified in this session (covered in 2026-04-15 Alicia Business Development Executive — financials ~3 hours when CoStar covers the market)
• CoStar interface delays add meaningful time per proposal — Alicia visibly waited for the property page to load mid-call

Pain Points & Frustrations

• CoStar is slow and outdated. Alicia and Vela both observed the property page failing to load during the call. Acknowledged as the only available comprehensive data source, despite the UX
• CoStar reports are paywalled per-report or rate-limited — BD switched a few months ago from generating full reports to picking properties one-at-a-time. Slower per session but avoids the report cap. Karolina knows the exact terms; Alicia does not
• Lighthouse is ADR-only — fills a gap when CoStar is thin but occupancy still has to be triangulated manually
• Glamping requires manual surgery on the Excel — when a proposal needs glamping, Alicia has had to insert a new section and manually re-wire the connections (FNB, rates) to the rest of the model. Rare but disproportionately expensive when it comes up
• Specialty restaurant formula range was too narrow until very recently — only allowed 0–1, BD asked for 0–3 and got it
• The 15% FNB uplift per specialty restaurant feels wrong. Alicia: "I honestly don't think that it would be 15% if we have five [restaurants]… that would be insane." She doesn't know the formula's derivation; assumes Aman owns it
• The new template was introduced last week and is still being refined — BD is the user base providing comments back to finance

Decisions & System Implications

Proposal Generation System

• Canonical financial template = hotel BNL model (with residences). Resolves the "two competing templates" question opened in 2026-05-06 Financials Discussion. Karolina's older P&L template is not the one to automate against. The Financial Agent should generate against the new BD template.
• Casadora is deprecated. Do not target it.
• Country-default growth-rate curves should be the agent's starting point. Theo proposed populating year-by-year growth-rate curves keyed on country code; Alicia agreed — "that would be great." The agent populates a country-default curve, then a human (Aman) overrides per-proposal exceptions like one-off events. Build implication: country → growth-curve lookup table, manually overridable in the assumption sheet.
• Inflation rate default = 2%, country-overridable. Hardcode 2% as the assumption, allow override per-country.
• AED–EUR exchange rate is fetched online per-proposal. No fixed source today. The agent should auto-fetch from a single, documented source — and the same source should be the one Alicia references, to avoid divergence with what BD would pick if doing it manually.
• Three default property categories, zero-out when unused: rooms, residences, glamping. Confirms the architectural decision in 2026-05-06 Financials Discussion. Glamping is rare but the manual-restructuring cost when it does come up justifies a default slot.
• Hotel positioning premium/discount range is −20% to +20%. Bounded input applied to comp-set ADR and occupancy. Captures Alicia's mental model of "smaller property fills easier" type adjustments.
• Specialty-restaurant input range = 0 to 3. "Specialty restaurant" excludes the main restaurant (e.g. Juntos), which is always counted at the base 35% in the model. Each specialty venue (e.g. Char) adds the 15% uplift the formula applies. Recent BD-driven change to the template.
• Nati / gelato concession is not modeled. Alicia has never added it in 2.5 years; the revenue is too small relative to the rest of the P&L. The agent should not include it as a counted F&B outlet.
• The 15% FNB uplift formula is broken; needs Aman call. Confirms the issue raised in 2026-05-06 Financials Discussion. Alicia agrees the formula does not scale sensibly past one specialty restaurant. She defers to Aman on the derivation. Action: schedule a call with Aman before locking the Financial Agent's logic on this slot.
• Template is still in flux. Don't hard-couple the agent to the current cell layout; keep the binding indirect (assumption sheet → named ranges) so finance team revisions don't break the agent.

Intelligence Hub

• Not discussed in this session.

Observations

• The session resolved most of the questions queued in 2026-05-06 Financials Discussion. Canonical template = the new BNL model. CoStar export = comp set + averages, not raw data. Inflation/exchange-rate sources clarified. Restaurant-uplift formula confirmed broken — kicked to Aman. Karolina's role redefined as CoStar-only. The remaining unresolved item is the formula derivation itself, which only Aman can answer.
• Country-default growth curves is a small, high-leverage build item. Alicia agreed instantly. It removes the "go look at past Excels for similar countries" step from the BD workflow and replaces it with an editable starting point. Good candidate for an early Phase-3 win that demonstrates AI value without complex automation.
• Aman is now the unblocking node for two things, not one. Growth rate sign-off (already known) and the FNB-uplift formula (new). His unresponsiveness flagged in 2026-05-06 Vela Checkin is now on the Phase-3 critical path twice over. Booking that conversation should not wait for the Alicia track to complete.
• The "BD comments → finance team adjusts the template" loop is informal but active. The specialty restaurant 0–1 → 0–3 change happened that way. Implication: the template Vela is automating against will keep moving for the duration of the build. Indirect bindings (named ranges, not cell references) are not optional.
• Alicia describes the new template as "mostly automatic" — but the assumption-tweakability question is unresolved. She believes it is a "set inputs, get outputs" tool, but 2026-05-06 Financials Discussion surfaced multiple hardcoded coefficients (12/14.5%, 50/25%, 35%, 15%, 20%) buried in formulas. Alicia did not read those out as tweakable. Either she does not tweak them and the agent can leave them alone, or she tweaks them and does not notice she's doing it. Aman call should also probe this.
• CoStar's report-cap workaround (per-property navigation) is a stable user behavior worth modeling around. BD has been on this workaround for "a couple of months." The shape of the export Vela has reflects that workaround, not the full report. When CoStar API access lands, the agent's input contract should not assume the API output matches what Vela has been reading — it might be richer.
• Three Aman dependencies (sign-off + FNB formula + assumption tweakability) cluster the financial-validation risk on one person. Worth flagging in the project plan as a single-point-of-failure on Phase 3, parallel to the Lily template SPOF on the visual side.

AI Foundations — IT Alignment Session — 2026-05-08

Attendees

• Douglas Turner — Head of IT, Kerten Hospitality / General Manager, Broad Vision
• Luka Kokot — Broad Vision (London), assists Douglas on ground-level IT needs across Europe
• Sinisha Kokot — Director, Broad Vision (25+ years)
• Mina Anziani — COO, Kerten Hospitality
• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory
• Shaheer Ahmed — Tech lead, Vela Advisory

Purpose

First alignment session between Vela and the Kerten IT partner (Broad Vision) to cover three topics: (1) general-purpose AI tool selection, (2) AI policy, (3) BD tool infrastructure requirements and system handover planning.

Topic 1 — General-Purpose AI Tool: Claude Teams

Decision: Claude Teams approved as the org-wide general-purpose AI tool.

Douglas Turner confirmed no concerns with the selection. Key implementation requirements assigned to IT:

• Single sign-on (SSO): IT owns the account; controls which domains can register; manages seats.
• API connector management: IT controls which MCP connectors and external APIs are permitted for use in Claude (e.g., SharePoint integration, right-access management).
• Tier upgrade policy: a process needs to be created (jointly with finance) for users who max out their usage allocation — what justification is required, who approves, what the path is to a higher tier.

Enforcement model: soft enforcement via policy + training (not technical blocking). Claude will be presented as the default sanctioned tool; the AI policy will state that other AI tools are forbidden for work purposes or with client information; case-by-case exceptions possible via escalation.

Topic 2 — AI Policy

Douglas confirmed two existing IT policies:

1. Broad policy covering security, governance, compliance, and data.
2. User-level acceptable use policy.

Neither currently addresses AI. Next step: Vela reviews both documents; team then either adapts them to include AI provisions or creates a dedicated AI annexure. Sinisha Kokot flagged that any policy exception process should follow the same change-management and control process used for existing IT policy exceptions.

Topic 3 — BD Tool Infrastructure

Architecture recap (as presented to IT)

• Phase 1: Claude Desktop plugin (.claude-plugin) hosted on GitHub, called from Claude Desktop. Skills: /market-research, /submit-brief.
• Phase 2/3 UI: React application hosted on Vercel. Back-end: Modo. State management and file storage: SharePoint.
• Triggers: Power Automate workflows for SharePoint form → system feed.
• APIs: Apify (web scrapers), and others per skill.

SharePoint

Decision: Dedicated Business Development SharePoint site to be created by Douglas.

Current KH SharePoint contains data for entities outside Kerten Hospitality (Michael O'Shea's other ventures — handled by Tara). Giving Vela access to the existing site would expose non-KH data and restrict Vela's access to folder-level only — insufficient for the BD tool build. The dedicated BD site resolves both issues.

• Vela gets full ownership of the new site.
• Long-term plan: migrate all BD data from the existing KH SharePoint to the new dedicated site. Business development then works exclusively from the dedicated site.
• Power Automate: basic license sufficient (HTTP trigger from SharePoint form — no Premium features required).

System Ownership Post-Engagement

Open item — offline discussion required. Douglas raised the question of who will maintain the GitHub repository, the Vercel frontend, and the other environments after Vela's engagement ends. Shaheer confirmed all materials will be handed over, but the right owner within Kerten/Broad Vision IT has not been identified. Douglas to regroup with Mina and the team to designate an owner. Requires "a little bit of technical savviness."

Immediate Action Items (Douglas)

• Share 2 existing IT policies with Theo.
• Create dedicated BD SharePoint site; grant Vela full ownership.
• Set up Power Automate access (basic license).

Decisions & System Implications

Proposal Generation System

• Dedicated BD SharePoint site replaces the existing KH SharePoint as the system's storage layer. The direction document, outline JSON, and delivery folder artifacts will all live on this new dedicated site. Affects system-design.md (SharePoint path references), and any code that constructs SharePoint URLs.
• Power Automate trigger: basic license confirmed sufficient. HTTP-request-based triggers from SharePoint form submissions are within the basic license. No Premium license required.
• System handover documentation required. GitHub repo, Vercel deployment, Modo back-end, SharePoint site structure, and Power Automate flows will all need to be documented for transfer to Broad Vision / Kerten IT. No owner identified yet.

Intelligence Hub

• Not discussed in this session.

Observations

• Douglas Turner is a competent, pragmatic IT lead. He arrived prepared, asked specific questions (what license? dedicated vs. shared site?), and committed to concrete deliverables. This is meaningfully different from the engagement's previous IT experience (where Cathal had not followed up on the Broad Vision meeting). The path to SharePoint and Power Automate access is now unblocked.
• The dedicated SharePoint site is the right call for reasons beyond data segregation. Michael's non-KH ventures data being on the current SharePoint was the official rationale, but the real driver is that a dedicated site gives Vela full programmatic ownership during the build and hands over a clean, bounded environment post-engagement. A folder-permission approach on the shared site would have created ongoing access headaches.
• The system handover question is the most important open item from this session. Shaheer and Theo have built something that requires "a little bit of technical savviness" to maintain — it has a GitHub repo, a Vercel deployment, a Modo back-end, and Power Automate flows. Broad Vision has the IT background to own this, but a specific person needs to be named. Without a named owner, the system becomes orphaned the moment Vela leaves. This should be resolved before the engagement ends, not after.
• Claude Teams SSO and connector management are now IT-owned, which is correct. Handing SSO to IT prevents the risk of Vela-managed credentials becoming a dependency after the engagement. The connector governance point (IT decides which APIs Claude can call) is also sensible from a security standpoint and aligns with Douglas's cybersecurity/compliance focus.
• The soft-enforcement policy approach is well-calibrated for Kerten's culture. Blocking ChatGPT at the network level in a hospitality org with minimal IT enforcement overhead is impractical. Defining "using other AI tools for work purposes" as a policy violation, while providing Claude Teams as the sanctioned alternative, achieves the centralisation goal without creating IT overhead or user friction.
• Shaheer's disclosure of the full tech stack (Vercel, Modo, GitHub, Power Automate) to IT was the right move. IT needs to understand the infrastructure to plan for handover, licensing, and security review. Withholding it would have created problems at the end of the engagement. The immediate output — Douglas committing to SharePoint + Power Automate access — is a direct result of that transparency.

Vela Internal Check-in — 2026-05-08

Attendees

• Shaheer Ahmed — Tech lead, Vela Advisory
• Theo Breward — Vela Advisory
• Maria Haddad — Vela Advisory (calling from Oman)

Summary

High-token-consumption alerts from Kerten testers prompted Shaheer to debug the Phase 1 plugin. Two root causes identified: inline SVG animations costing significant tokens at Opus level, and the research agent stopping prematurely and forcing the main agent to re-run it three times per phase. Optimization plan agreed: Sonnet for the main conversation, Opus offloaded only for heavy-thinking subtasks as a separate agent. Shaheer also revealed PDF reading is happening at Opus — a major previously unnoticed cost driver. Financial modeling was deprioritized to second place pending an Aman call. The team rejected moving to a direct API approach (and away from Claude Desktop) after Shaheer explained the engineering weight required to rebuild the harness.

Decisions Made

Proposal Generation System

• SVG loading animations removed. Inline SVG/HTML animations (coffee animations, waiting-period UX) generated by Opus are too expensive per proposal run to keep. Static assets via artifact files would have been feasible but the current inline approach cannot be replaced within the build timeline. Removed from the plugin.
• Model routing: Sonnet for main conversation, Opus as a separate offloaded agent. The optimization strategy is to run the main user-facing conversation permanently on Sonnet, and route only heavy-thinking tasks (tasks currently burdening Opus) to a dedicated Opus subagent — similar to how the research agent is already offloaded. Keeps per-run costs lower without sacrificing output quality on complex reasoning steps.
• PDF reading must move off Opus. Discovered late in the session: the RFP and supporting document reading is still happening on Opus, making it one of the largest cost drivers in the workflow. Not yet resolved — flagged for next optimization pass.
• Research agents now run in parallel, not sequentially. Phase 1's two background research agents previously ran sequentially (a regression from an earlier version). Now restored to parallel execution.
• Continue with Claude Desktop; no custom UI or API-only approach. Theo raised switching from Claude Teams subscription to direct API calls (pay-per-use, user-defined budget), which would require building a custom chat UI. Shaheer's position: the Claude Desktop harness (tool calling, error handling, context management, retry logic) is the entire engineering foundation the plugin rests on. Rebuilding it would take months, risk quality degradation, and introduce security and context-management complexities. Decision: stay on Claude Desktop and optimize within the subscription model.

Intelligence Hub

• Not discussed in this session.

Key Topics

Token spike root causes

Maria's tester session hit limits unexpectedly. Shaheer had been debugging since the previous night. Root cause 1: SVG animations, which Shaheer added as a waiting-period UX touch (coffee cup upgrading from espresso to flat white), require Opus to generate HTML/SVG from scratch on every run — each generation consumes a disproportionate share of tokens. Root cause 2: The research agent (handling web search in the background) was stopping prematurely without synthesizing results. Because the summary was absent when context returned to the main agent, the main agent re-triggered the research agents. In Phase 1 (two agents in parallel), this re-ran three times; in Phase 2 (five to six agents), two to three times. This multiplied costs by 3–6× in the affected phases.

Granular usage monitoring

Shaheer built a session-level usage monitor that translates token consumption to API-equivalent dollar cost. Theo flagged that this converts to API pricing, not subscription pricing, so it's a proxy not a literal cost. Shaheer: that proxy is exactly what's useful — it surfaces the relative cost of each agent and step within a run. Will drive ongoing optimization decisions.

Subscription vs. API cost model

Theo's concern: with 15+ users on a subscription, some will exhaust their allocation doing non-proposal work, and the fixed per-seat cost across inactive users is wasteful. His proposal: move to direct API calls, set a per-user proposal budget. Shaheer's response: the tradeoff is that Claude Desktop provides the harness for free — workflows, tool calls, error handling, retry logic. Replicating that in a custom UI means writing all of it from scratch in Python, plus UI, authentication, data security, and context management. Even the Claude Code source leak, which would have illuminated the harness architecture, is gated behind paid Substack articles. Conclusion: too much risk for marginal cost savings, especially mid-engagement. Optimize the subscription approach instead.

Financial modeling

Theo's view: financial model work is second priority — the requirements will change before the engagement ends, and it is not super complicated (comp set from CoStar, a few assumption derivatives from the concept brief). The real blocker is Aman (CFO): Theo needs to understand how he derives growth curves per country, and whether he will accept the output the system produces. Theo flagged that the BD team applies wildly inconsistent levels of detail — sometimes granular salary/headcount, sometimes a 35%-of-RevPAR top-line estimate. Without knowing what Aman considers acceptable, building the financial model is premature. Plan: catch Aman at the Stream 3 meeting. Email also sent. Ramin flagged as a potential alternative contact (more responsive).

Survey review

The Akaba workshop survey has been pending BD team review for two weeks. Maria will push for a deadline in the upcoming meeting. If no commitment is made in the room, the survey will be sent to Marloes with a Monday deadline set unilaterally.

Upcoming meetings

Two back-to-back after this call: AI Foundations alignment with Douglas Turner (IT/Broad Vision) — relevant for SharePoint and Power Automate access; and a strategy meeting with Doug. Shaheer confirmed needed for the AI Foundations call to speak directly to IT about system handover and infrastructure.

Contradictions & Flags

1. PDF reading still on Opus — previously untracked cost: No prior session identified PDF reading as an Opus operation. This is now confirmed as a significant cost driver that was not factored into any of the earlier cost estimates. → Status: unresolved — optimization required, affects cost-per-run estimates
2. Research agent sequential regression: The research agents in Phase 1 had been running sequentially (not in parallel as designed). The version upgrade to 0.6 may have lost this configuration. → Status: resolved this session — restored to parallel
3. API-only approach deferred, not dismissed: Theo's API-vs-subscription concern is legitimate at scale (15+ users), but deferred because the engineering cost is too high mid-engagement. If the engagement extends or the system is sustained post-Vela, this becomes relevant again. → Status: deferred — revisit if engagement scope expands or Kerten takes over development

Observations

• The research agent re-run loop was a silent cost multiplier. Phase-1 research running three times means every test session cost 3× what it should have. The premature stop without synthesis is a correctness bug (the main agent was completing phases without full market data) as much as a cost problem. Fixing it both reduces cost and improves output quality.
• PDF reading at Opus is a bigger deal than it appeared mid-discovery. RFPs and supporting documents are the primary input to Phase 1. Running every document read at Opus means every session starts with a high-cost burst before any research even begins. Moving this to Sonnet or caching parsed document content is probably the highest-ROI single optimization available.
• The Sonnet-for-main-conversation strategy is architecturally sound but needs careful routing rules. The proposal output quality depends on Opus-level reasoning at key moments — positioning thesis synthesis, competitive differentiation framing. "Heavy thinking" must be operationally defined in the routing logic, otherwise the quality gains from Opus get lost along with the cost.
• The custom-UI/API argument will resurface if the system's per-run cost does not come down. Theo's instinct (pay for what you use) is correct at scale. The counter-argument (engineering cost of rebuilding the harness) is valid today but weakens if Kerten wants to sustain this post-engagement with an IT team that can't maintain Claude Desktop workflows. The handover question in the AI Foundations meeting directly connects here.
• The inline SVG animation was a good design decision that hit a model constraint. It would work cleanly as a static artifact — Shaheer confirmed this. The limitation is purely that the current implementation generates inline HTML every time. If a static KH-branded loading asset is ever built as an artifact file, this could be reintroduced at negligible cost.
• Aman is now the critical path for financial modeling. Until the team knows what level of detail Aman considers acceptable (growth curves, assumption derivation, model structure), building the financial module is guesswork. The model is "not super complicated" only if the input contract is settled.