A trip planner that sends people somewhere other than the famous three trailheads

The situation

On a summer Saturday, the lots at the region’s three best-known trailheads were full by 7:30 AM. Cars lined the shoulders. Land managers had asked the organization to stop promoting those hikes, residents were writing letters, and the website already said, politely, “consider an alternative.”

Visitors didn’t read that line. Many never reached the website at all. They asked an AI assistant for the best hike near town, and the assistant, drawing on a decade of top-ten lists, named the same three trails.

The board’s request was simple: an AI trip planner, like the ones other destinations had launched. The staff’s request was harder: a planner that would spread visitors out, rather than add a fourth channel pointing at the same parking lot.

What we tried first

We began with a conversational planner grounded in the organization’s own content. The prototype was friendly and accurate, and in testing it recommended one of the famous three in seven of the first ten conversations. The content itself was the problem: those trails had the most pages, the most photos and the most superlatives. A planner built on that content learned the same bias the assistants had.

Site analytics told us the other half. A planner on the website would reach a minority of trip planners. Visibility in assistants wasn’t a separate project; it was the rest of this one.

What we built

Alternatives with the same character. “Less crowded” is not a reason anyone chooses a hike. We profiled each trailhead by what visitors actually trade on, so the planner could offer a genuine sibling to a famous trail, not just an emptier one.

Crowding as a routing cost. Route Engine treats predicted trailhead load as a cost by the hour. It can move a start earlier, swap in a sibling trail, or reorder a day so the famous viewpoint lands at a quiet hour. Every suggestion carries its reason in plain language: “Similar climb and lake views; this lot usually has space before 10 AM.”

The same planner, reachable by agents. Through Agent Gateway, assistants that support the Model Context Protocol can call the planner directly and get the same dispersal-aware answer the website gives, with attribution and a link back. It is read-only. Partners keep selling on their own sites.

Content assistants can quote. The visibility work rewrote high-traffic pages around the questions visitors ask, added structured data, and published closures in a form that updates within minutes instead of days.

What changed

With dispersal on, 27% of summer-weekend itineraries started at one of the famous three, against 58% in the holdout. In an opt-in post-trip survey (312 responses), 44% of planner users said they had hiked a trail they hadn’t heard of before planning.

In the prompt test set, answers citing the organization rose from 9% to 34%. More telling than the number: assistants began repeating the organization’s own wording about closures and early parking.

The staff’s conversations changed too. The board stopped asking whether there was an AI planner and started asking what the assistants were saying, which is the more useful question.

What we’d do differently

Rotate the alternatives from day one. By week nine, one sibling trail had become the new busy one; the planner had done its job too well on a single option. We added rotation and a load ceiling per trailhead. Both belong in the first build.

Bring land managers in early. Staff knew which places they wanted to protect; land managers knew which were fragile. A joint session in week one would have saved two rounds of revisions.

Ship the survey with the planner. We added the post-trip survey in week six, so the early weeks have no comparison. Next time, it launches on day one.