Methodology

This page documents the methods I use to study anticipatory care in hospitality environments.

The goal: understand how practitioners make judgment calls under constraint, then investigate whether transparent intelligence tools could enhance—not replace—that human judgment.

The approach: direct field observation, structured operator interviews, pattern extraction, and technical experimentation with explainable cognitive architectures.

This work sits at the intersection of ethnographic research, service design, and explainable AI. The methods draw from anthropology (participant observation, semi-structured interviews), operations research (timing studies, service blueprinting), and human-computer interaction (prototype testing, usability observation).

Everything documented here is designed to be replicable, ethical, and operator-centered.

Research Questions

Primary Question

How do expert hospitality practitioners anticipate guest needs under real constraints?

Sub-questions:

• What contextual cues do operators read when making service decisions?
• How do they balance personalization with efficiency?
• What mental models guide their judgment under time pressure?
• Where do existing tools help vs. hinder that intelligence?

Secondary Question

Can transparent cognitive architectures support—not replace—operator judgment?

Sub-questions:

• What does "explainability" mean to a front desk agent troubleshooting a recommendation?
• How much context is enough for a system to feel attentive vs. invasive?
• What does graceful failure look like when technology breaks during service?
• Can systems learn from operator corrections without requiring explicit training?

Field Sites & Selection Criteria

Types of Properties Studied

Selection Criteria

Properties must meet at least 3 of these:

1. Small team size (under 20 staff) - where individual judgment matters
2. High guest satisfaction (reviews mentioning "attentive," "anticipatory," "personal")
3. Operational constraints (peak hours, language barriers, tech limitations)
4. Willingness to participate (permission for observation, interview access)
5. Diversity of context (different cultures, property types, service models)

I prioritize properties where care happens despite constraints—not because they have enterprise budgets or perfect tools.

Field Observation Protocol

What I Observe

• Arrival sequences (first 5-10 minutes): Greeting ritual, information gathering, context reading, service choreography.
• Peak operations: Multiple arrivals/departures, system failures, staff coordination, triage decisions.
• Transition moments: Shift handoffs, daily briefings, information transfer protocols.
• Breakdown & recovery: Failure modes, operator improvisation, guest escalation, post-incident reflection.

What I Measure

• Timing: Arrival-to-greeting interval, check-in duration, response times, queue lengths.
• Counts: Staff-to-guest ratios, interaction frequency, touchpoints per stay, system access patterns.
• Artifacts: Service scripts, backup protocols, checklists, physical tools.
• Qualitative signals: Tone shifts, body language cues, moments of visible care, guest reactions.

Field Notes Format

Each observation produces a Field Report with context, scene narrative, measurements, patterns, questions, and operator reflection.

Observation Ethics

• Minimal disruption: I observe from positions that don't interfere with service flow
• Guest privacy: I never record guest names, personal details, or identifying information
• Operator consent: Staff know I'm observing and can ask me to pause or leave
• No photography of guests: Only staff, tools, and environments (with permission)
• Debriefs, not surveillance: I explain what I'm studying and why

Operator Interview Protocol

Interview Structure

Semi-structured format (45-60 minutes), conducted in operator's preferred location. Audio recorded only with explicit consent; otherwise handwritten notes.

Core Questions

Compensation & Credit

• No payment for interviews (to avoid bias toward positive framing)
• Service audits offered: I provide a 1-page summary of observations as value exchange
• Attribution: Operators can choose: full name, first name only, anonymized role, or no attribution
• Review before publishing: Any quotes or stories shared publicly get operator approval first

Pattern Extraction & Analysis

After field visits, I synthesize raw notes into Pattern Cards—structured artifacts that capture transferable principles.

Validation

Patterns get validated through:

1. Operator feedback: "Does this match your experience?"
2. Multiple sightings: Observed at 3+ different properties
3. Reproducibility: Other operators recognize and can apply it
4. Edge case testing: Where does the pattern break down?

Technical Experimentation

I explore whether BDI (Beliefs-Desires-Intentions) cognitive architectures can model how operators think—and whether that modeling makes intelligence more transparent and learnable.

Not building: Black-box automation, "AI chatbots," efficiency dashboards.

Exploring: Explainable reasoning systems that show their work, learn from corrections, and preserve human judgment.

Prototype Testing Protocol

• Small-scale mockups: Shown to 3-5 operators for feedback on explainability.
• Wizard-of-Oz testing: Manual simulation of intelligent systems to test assumptions.
• Limited field pilots: With 1-2 operator partners, designed for learning, not efficiency.
• Transparent failure analysis: Documenting why things break publicly.

Ethics of AI Experimentation

• No guest data collection without explicit consent
• Operator override always available
• No hidden automation—guests and operators know when they're interacting with AI
• Graceful degradation—if system fails, service continues without it
• Explainability required—every recommendation shows its reasoning

Data & Privacy

Anonymization Protocol

• Default: First name + role + city (e.g., "Ana, front desk manager, Lisbon")
• On request: Role + property type only (e.g., "GM at 12-room boutique")
• Venue details: Room count and city only; photos edited to remove branding if requested

Limitations & Boundaries

What This Research Can't Do

• Can't generalize to large-scale operations: I study small teams where individual judgment matters.
• Can't separate observer effect: My presence changes behavior, though I minimize disruption.
• Can't capture everything: Some intelligence is tacit and hard to articulate.
• Can't promise outcomes: This is exploratory research, not a product pitch.

Bias & Positionality

My background shapes what I see:

• Product design lens → I notice tools and interfaces more than interpersonal dynamics
• Tech experience → I may overvalue technical solutions
• Privileged traveler → I access properties/experiences not available to all guests
• Limited to English + Spanish → I miss nuances in other languages

I compensate by hiring translators, seeking challenging views, and inviting corrections.

Research Timeline

Timeline is flexible—research follows interesting threads, not arbitrary deadlines.

Publications & Outputs

Collaboration & Participation

How Operators Can Participate

• Nominate your property: Email me with your details. I provide a service audit in exchange.
• Share a ritual or failure story: Contribute to collective practitioner intelligence.
• Review Pattern Cards: Help validate what's transferable vs. context-specific.

How Researchers/Builders Can Participate

• Compare notes on transparent AI: Share research on explainability and cognitive systems.
• Contribute technical experiments: Propose prototype tests grounded in field observations.

How Anyone Can Contribute

• Share examples of technology enhancing or degrading care.
• Question assumptions in my field notes.

Contact & Transparency

Email: carlos@omote.io

What I'm happy to share: Detailed field notes (anonymized), interview protocols, Pattern Cards, technical explorations.

What I can't share: Identifiable operator insights without permission, proprietary systems, raw field data with venue names.

Corrections: If I misinterpret something, email me. I'll correct promptly and note the update.

Why This Methodology Matters

Most hospitality AI is built by people who've never worked a front desk shift. Systems get designed in conference rooms, optimized for metrics that don't capture what makes care human.

This research starts from the opposite direction: operators first, technology second.

By documenting how expert practitioners make judgment calls under constraint—and only then exploring whether transparent architectures could enhance that intelligence—I'm betting we can build tools that make care more human, not less.

The methodology is designed to earn that right:

• Systematic observation (not casual blogging)
• Ethical boundaries (not exploitative data mining)
• Operator-centered (not user research for product development)
• Public documentation (not proprietary competitive advantage)

This is slow, careful work. But if hospitality intelligence is worth operationalizing, it's worth studying properly first.