Background
Independent hoteliers are a distinct segment. Unlike enterprise hotel chains, they operate with small teams, tight budgets, and a deep personal investment in every decision the property makes. They are experienced enough to know that technology promises rarely arrive intact, and cautious enough to push back hard when something feels opaque or out of their control.
Lighthouse had developed a set of agentic AI concepts: ideas about how the product could take on routine commercial decisions autonomously. The enterprise case was relatively straightforward: large operations have processes for integrating new tools, dedicated commercial teams, and tolerance for some level of managed risk. The independent hotelier case was harder. For a sole operator managing reservations, pricing, and distribution personally, the question was not just "does this work?" but "do I trust this enough to let it act on my behalf?"
We needed to test whether our concepts could answer that question, and if not, understand what would need to change.
The approach
Rather than running a standard research cycle over several weeks, I designed a validation week: a structured five-day format that would take a set of prototype concepts, put them in front of real customers twice, and produce a prioritized, evidence-based roadmap by the end of Friday.
I co-planned the week with a researcher and set the strategic framing: what this vertical specifically needed from an agentic product and what questions we most needed to answer. I also arranged for a designer on the team to build an initial prototype using AI-assisted tooling to represent the concepts before the week began. I would evolve the prototype as feedback came in. The researcher would lead the interviews, with me participating throughout. I would facilitate all internal working sessions. The output ownership was mine.
We recruited a group of independent hoteliers willing to participate in two sessions across the week, with time between them for us to update the prototype based on what we heard.
The week
First customer sessions
We opened the week with concept interviews. The researcher led, I participated and observed. We presented the prototype concepts and framed each session around the same core question: where does this feel like a capable assistant, and where does it feel like something taking over?
The response was consistent across participants. The concepts that generated confidence were the ones that showed their reasoning: the AI surfaced a recommendation alongside the signal that had triggered it, so the hotelier could evaluate rather than just accept. The concepts that created friction were the ones that acted first and reported after. Independent hoteliers, it turned out, did not object to automation in principle. They objected to invisibility.
Internal co-creation
I facilitated an internal session to translate what we had heard into design principles. The goal was not just to list feedback but to make a set of decisions: which concepts were structurally sound and needed refinement, which needed to be reconceived, and which assumption had been wrong enough that we should drop it.
The session produced three clear commitments: every autonomous action would show its reasoning before and after execution; the hotelier would have meaningful override capability at every step; and the product would default to suggesting rather than acting until a user had explicitly granted a higher trust level. These were not edge-case considerations. They were the core of what made the product viable for this segment.
Prototype iteration
I updated the prototype to reflect the decisions from the co-creation session. The main changes were structural: replacing action-first flows with recommend-then-confirm flows, adding reasoning disclosures to every agent card, and redesigning the trust configuration so it felt like something the hotelier was actively setting rather than something that had been set for them.
The updated prototype was not a polished design. It was functional enough to put in front of customers again and clear enough to make the changes legible.
Follow-up customer sessions
The second round of interviews used the same participants. This is where the compression format earned its value: participants could compare what they had seen earlier in the week with what they were seeing now, and react to specific changes rather than evaluating concepts in the abstract.
The updated flows landed significantly better. The transparency mechanisms were noticed and appreciated without prompting. Several participants articulated versions of the same sentiment: they could see themselves using this in the way we had designed it, and they could not have said that after the first session. The remaining friction points were specific and actionable, which is exactly the state you want before committing to a roadmap.
Internal prioritization
I facilitated a closing session with the broader team to work through the output. We reviewed each concept against two dimensions: customer validation strength and implementation feasibility. The goal was a prioritized set of next steps that the team could act on with confidence, not a wish list that would require further validation to be credible.
We left the session with a clear first tier of concepts ready for refinement and build, a second tier to revisit once the foundation was in place, and a small set of ideas set aside. Not killed, but not the right priorities given what we now knew.
What we learned about trust
The most durable finding from the week was not about a specific feature. It was about the mental model independent hoteliers need to adopt an agentic product. They are not looking for a system they can hand everything to and walk away from. They are looking for a system that handles the operational repetition competently while keeping them clearly in the picture. The language that resonated most was not "autonomous" but "handles it for me, shows me what it did."
That is a meaningful design constraint. It means transparency is not a safeguard layered on top of the product. It is a core feature of the interaction model. Every agent action needs a readable trail. Every recommendation needs a visible reason. The hotelier needs to feel like a manager reviewing work, not a passenger in a vehicle they cannot steer.
Key insight
Independent hoteliers did not object to automation. They objected to invisibility. Designing for this segment means treating transparency not as a compliance requirement but as the primary trust mechanism. The concepts that made reasoning visible, before and after execution, were the ones participants said they would actually use.
Outcome
By end of Friday we had a prioritized roadmap of tested concepts. The solutions in the first tier had been validated with real customers twice, refined between sessions based on direct feedback, and stress-tested for feasibility in an internal session. They did not need another round of research before moving forward. They needed refinement and build.
The week also produced something harder to quantify: a shared team understanding of what independent hoteliers need from an agentic product that is grounded in what we actually heard rather than what we assumed. That kind of alignment is usually the product of months of iterative research. We had it by Friday afternoon.
Outcome
A validated, prioritized roadmap of agentic concepts tested directly with independent hoteliers. First-tier solutions ready for refinement and build. A design principle, transparency as a trust mechanism, that now shapes how the team approaches agent interaction design across the segment.