A destination website procurement can spend pages specifying design components and very little space describing what visitors should be able to accomplish. The result may look excellent while leaving trip planning, local booking and member reporting as separate projects. A useful RFP starts with the journeys the DMO wants to support, then asks vendors to show how they will make those journeys work.
This checklist is for destination marketing organizations, regional tourism groups and visitor centres preparing a website rebuild or an add-on procurement. It is vendor-neutral: your answer may combine an existing CMS, an itinerary layer, merchant booking systems and engagement tools. The right architecture depends on your members and operating model.
Considering a planning layer for an existing destination site? Loop's AI Trip Planner is designed to help visitors ask questions, save trips and reach local booking options. The RFP below helps you compare that kind of capability with your broader website requirements.
Write outcomes before features
Start with three to five visitor tasks. For example: plan a car-free weekend, find a family activity open tomorrow, save a two-day food itinerary, reserve an experience and return to the plan while travelling. Include at least one task with imperfect information, such as an operator that only accepts inquiries.
Then add member outcomes. A small tour operator wants qualified traffic and a workable booking path. A restaurant wants visitors who know when it is open and can reserve a table. A DMO wants to show which content, itineraries and campaigns sent useful activity to members. These outcomes make it easier to evaluate proposals than a list of software labels.
Ask vendors to demonstrate each task using sample content from your destination. A generic demo with famous landmarks may conceal problems with your actual geography, seasonal businesses and member data.
Define the role of the existing website
Decide whether the project replaces the whole site or adds a planning and booking experience to it. If you have a capable CMS and strong editorial pages, an add-on may be simpler. If the current site has fragmented content, slow mobile pages or no clear ownership, a wider rebuild may be justified.
Document the systems you already use: CMS, event calendar, member database, analytics, maps, email platform and any booking or ticketing providers. State which are contractual requirements and which could change. Ask vendors to describe data flow and responsibility for each integration, including what happens when one source is unavailable.
Keep procurement language focused on visitor and staff needs rather than prescribing a particular technical method too early. That gives you room to compare credible approaches.
Ask how visitors will plan a useful trip
A trip planner should take a visitor's constraints seriously: dates, interests, party type, mobility needs, budget, transport and available time. The output should be editable and savable, not merely a static list. Ask how the system handles closed venues, impossible travel times, uncertain information and requests outside the destination's supply.
Require a demonstration of the visitor asking a follow-up question and changing one part of a plan without losing the rest. Test whether the mobile experience remains clear. Ask where the plan is stored, how a visitor resumes it and what data the DMO can use with consent.
The destination data checklist lists the hours, durations, locations, accessibility details and booking routes needed to support realistic recommendations. Include a data-readiness phase in the project schedule.
Treat bookings as a mixed ecosystem
Most regions have merchants at different levels of maturity. Hotels may use property-management and distribution systems. Restaurants need table availability. Tours may have timed capacity, while small attractions may still take phone inquiries. An RFP should ask how visitors move from a plan to each merchant's actual next step.
Require vendors to distinguish an external booking link, live availability display, embedded booking flow, inquiry and completed transaction. Ask whether merchants keep their existing system, what happens when they have none and who owns payment, refunds and customer service. Do not ask for a single checkout unless you have a real business case and the team to manage it.
The region-wide booking guide and merchant-system integration guide provide useful scoping questions. A small operator without software could assess Loop's free time-slot booking tool; restaurants have a separate table reservation tool.
Specify how members participate
Ask how businesses submit and correct information, receive referrals and see results. A member dashboard is only valuable if the data is understandable and appropriately attributed. Define who approves listings, who fixes broken links and how urgent changes are handled before a holiday weekend.
Include a pilot with different member types: accommodation, food, tours, attractions and a small operator without online booking. A proposal that works only for the largest merchants will not serve the whole region. The existing DMO partner engagement guide covers the onboarding challenge.
Also consider how visitor participation continues during and after a trip. Digital Passports can support trails, reviews, photos, rewards and cross-visitation. Specify whether this is part of the website project or a later phase.
Ask for a reporting model you can defend
A DMO should not describe every outbound booking click as a booking. Require separate reports for visitor questions, plans created, saved trips, merchant views, booking clicks, confirmed transactions where available and participation after arrival. Ask vendors to show exactly how each event is counted and which systems supply it.
For member reports, request clear source definitions and a way to filter by period, campaign or business. Include privacy and consent requirements for saved trips and contact details. Ask what data can be exported if the contract ends. The destination booking measurement guide explains why fair attribution matters.
Set a baseline before launch. Without current website usage, referral and booking data, a new system can produce an impressive dashboard without proving improvement.
Include accuracy, accessibility and governance
Ask how the system handles incorrect answers, stale event dates, inaccessible experiences and member disputes. Require a human correction route and a log of material content changes. Define what the planner may say when it lacks a reliable fact. It should not invent availability or claim an experience is accessible without verified information.
Include normal website accessibility requirements and a test with real visitor tasks. Ask for mobile performance and readable page content, not only a screenshot of a polished desktop design. Google's AI search guidance says useful, crawlable content and ordinary SEO foundations remain important for AI features; no special AI file is required. Google's guidance can inform the discoverability section.
Require the vendor to explain data protection, access control, retention and how visitor questions are used to improve the service. Make sure staff can update the most important information without a developer ticket.
Compare the total operating cost
A low setup fee can hide ongoing staff work, per-member charges, transaction commissions, paid integrations, content migration or support costs. Ask for a three-year cost model with assumptions. Include training, seasonal updates and support during events or high-demand periods.
Score proposals against outcomes, not just feature counts. A simple matrix might give weight to visitor task completion, member inclusion, booking continuity, reporting quality, accessibility, operating burden and total cost. Ask references about implementation and support, not only launch-day appearance.
Run a small proof of concept
Before committing to a broad rollout, give shortlisted vendors a representative sample: 25 businesses, one event, one trail and several booking routes. Ask them to demonstrate a family weekend, an accessible activity request, a rainy-day change and a bookable itinerary. Have destination staff and two member businesses evaluate the result.
Record where facts were wrong, links failed, travel times were unrealistic or reporting was ambiguous. This exercise reveals the work your DMO must do regardless of vendor. It also helps distinguish a product capability from a presentation slide.
Questions to include in the RFP
- How does a visitor save and revise a trip?
- Which merchant booking systems can remain in place?
- How are unbookable or inquiry-only businesses represented?
- What data must the DMO supply and maintain?
- How do members correct a listing or booking link?
- What can we report as a confirmed booking versus a click?
- How are accessibility and seasonal changes verified?
- What data can we export, and what is the three-year operating cost?
Frequently asked questions
Must a DMO replace its website to add trip planning? No. A planning layer may work with an existing site if the content and integration paths are sound.
Should every merchant use the same booking system? Usually the region is better served by connecting working merchant systems and helping smaller operators who lack a route.
Is a chatbot enough? A conversational interface can answer questions, but the RFP should test saved plans, accurate data, member actions and measurable outcomes as well.
What is the best first procurement test? A proof of concept using real businesses and imperfect data will expose more than a generic vendor demonstration.
Next step: Use the checklist to evaluate the AI Trip Planner for DMOs alongside your CMS, merchant booking and reporting needs.
Shortlist the right layer: use the planner widget vs chatbot vs map comparison, then test Smartvel and Wander Maps against this RFP. Explore Loop AI Trip Planner for the product scope.