A seasonal product can return with a familiar name while the service behind it has changed. A pickup zone may be smaller, a supplier may use a different meeting point, or a lunch arrangement may no longer be included. Copying last season’s listing can preserve those old promises long after staff have adopted a new plan.
This article proposes an editorial reopening process for activity operators. “Seasonal” can mean a recurring period of operation, a temporary suspension or a planned restart. The checklist does not determine whether an activity is safe or authorised to operate; those decisions remain with the appropriate responsible people and requirements for that activity.
Define the reopening as a product version
Give the restart a clear effective date and a named product owner. Record what is being reopened: product, options, departures, languages and channels.
A useful internal label might be “Coast Walk, November operating version.” It does not need to appear in the guest-facing title, but staff need a way to distinguish it from the previous service.
Keep a short change summary with three parts: what changed, which service dates it affects and which bookings need review. “New season ready” is too broad to help a colleague.
Do not overwrite the old operating information without retaining the relevant history. Staff may still need it to understand a past booking or a guest who reserved before the revision. Follow the organisation’s normal record and access arrangements.
Verify the underlying service first
Ask each responsible team or supplier to confirm its part of the service. Check the route or venue arrangement, available departures, staffing, transport, equipment and included services that matter to the product.
Distinguish an intention from a confirmed arrangement. “We usually use this restaurant” is different from an agreed meal service for the new dates. “The guide may be available” is different from a staffed departure.
Record evidence in a practical form: a supplier confirmation, approved operating document or named owner’s sign-off. The purpose is to let the product owner see which promises are supported.
Where access, permissions or activity-specific operating requirements apply, have the appropriate responsible person verify them. A listing editor should not infer readiness from last year’s calendar or a destination being generally open.
Check the dates as a complete set
Define the first operating date, last operating date, regular operating days and exceptions. Check the year, local date and time zone wherever systems require them.
A common reopening error is correcting the start date while leaving an old end date or weekday rule. Another is opening the main option while an associated departure remains blocked.
Include public holidays or special closures only after verifying what the operator will do on those dates. A general holiday calendar does not by itself decide the product schedule.
For products with different seasonal options, record the boundary explicitly. If one route ends on 31 October and another starts on 1 November, staff should know which service applies to a booking around that transition. These dates are illustrative, not a recommended operating season.
Review the guest promise line by line
Read the current listing as if you were the guest. Highlight every concrete promise: places visited, duration, group arrangement, language, transport, meal, equipment, pickup, return point and included admission.
For each promise, ask whether the new operating version still supports it. Keep confirmed details, revise changed ones and remove unsupported wording.
Pay particular attention to “included,” “all,” “every” and “guaranteed.” These words can remain unnoticed inside familiar marketing copy while changing the guest’s expectation substantially.
The private-tour route approval guide covers changes to an individual itinerary. A seasonal product revision is broader: it affects what future customers can buy and what existing customers may already have been promised.
Recheck pickup and meeting information
Confirm the pickup zone, excluded areas, meeting-point name, map pin and the guest instructions used for each option. A correct product description cannot compensate for a voucher that still sends guests to the old place.
Compare the address with the physical meeting arrangement. Ask where a vehicle can stop and where staff will actually stand, rather than relying only on a landmark name.
If the pickup zone has changed, identify existing reservations outside the revised area. Handle them through the appropriate booking process; do not silently assume the new zone rewrites a previously confirmed arrangement.
Use the pickup-zone exception workflow for hotels or locations that need a separate decision. Keep those exceptions visible to the team handling guest communication.
Confirm inclusions with quantities and conditions
Meals, transfers and admissions deserve a specific check because they often depend on another business. Confirm what is included, for which guest categories, on which departures and under what agreed arrangement.
A seasonal change from a set lunch to an optional meal affects the listing, voucher, guest message and operational order. Updating only the headline description leaves several routes for confusion.
Review child and infant arrangements separately when they affect portions, seats or included items. The meal-count guide explains why those quantities need their own confirmation.
Avoid keeping an old photograph solely because it looks attractive if it prominently shows an inclusion no longer offered. Visuals can make promises too, even when the text has been corrected.
Map every place the product is sold
List the operator website, agent sheets, booking channels and other active sales surfaces. For each, identify who controls product text, availability and confirmation messages.
A connected channel may receive some information from a reservation system while still keeping other details in its own portal. Establish the actual source for each field instead of assuming one edit updates everything.
GetYourGuide’s cutoff guidance illustrates this distinction: connected products can use a cutoff sent by the reservation system, with portal settings relevant when that value is not supplied. Other systems have their own arrangements.
Keep a channel checklist with the revision date and reviewer. A completed website update should not stand in for a completed agent-sheet update.
Set availability from operating capacity
Only open the dates and quantities the confirmed service can support. Check capacity at the correct option or departure level, including any shared operational constraint.
An operator may have enough nominal places across products but use the same vehicle, guide or equipment for several departures. The responsible operations team must account for those shared resources.
GetYourGuide’s availability management guidance distinguishes adjusting vacancies from blocking slots. It also notes that blocking new sales does not remove existing bookings. Treat those as separate tasks in the reopening process.
Do not shorten booking cutoffs simply because a channel allows it. Use the preparation time the actual departure needs, then configure the relevant system according to its current documentation.
Review bookings already held
Pull the reservations for the affected service dates before opening further sales. Compare each with the new operating version.
Look for differences in route, start time, pickup, language, inclusions and guest categories. Identify which bookings match, which need clarification and which require a formal change process.
Assign an owner to contact affected guests or agents through the appropriate channel. State the proposed difference clearly and record the outcome. Do not assume a website update communicates a change to someone who booked months ago.
Keep unresolved reservations in a visible queue. Reopening can still be staged around resolved departures where appropriate, but a product-wide green status should not hide guests whose confirmed arrangements remain uncertain.
Test one realistic booking journey
Choose an ordinary case that reflects how the product is actually sold. Check the service date, option, party categories, language and meeting arrangement through the relevant guest or agent path.
Review what the customer sees before purchase and what the team receives afterwards. Does the confirmation carry the revised meeting point? Does the operational record show the correct departure? Are essential instructions easy to find?
Use an authorised test method supplied by the system or your organisation. Avoid creating a chargeable live booking merely to see what happens.
Record the case tested and the result. One successful path does not prove every option works, but it can reveal inconsistencies before further sales. Test additional paths where a different option uses materially different information or systems.
Work through a fictional reopening
Imagine a shared coastal walk returning in November. The new version uses an earlier start, a smaller pickup zone and lunch purchased separately. Last season’s agent sheet still includes lunch and a wider transfer area.
The product owner first confirms the new service with operations. They update the website, channel description, agent sheet and guest instructions, then configure the correct departures and cutoff source.
A review finds three existing reservations under the older arrangement. A named booking owner checks their terms and handles the proposed changes through the appropriate process. Those bookings remain visible until resolved.
An authorised test confirms that the revised meeting point reaches both the guest instructions and the operating record. The owner records the result before opening the approved availability. This example is fictional; the sequence illustrates coordination rather than a rule for changing existing contracts.
Prepare the team’s first-day brief
Give staff a concise briefing that focuses on differences from the previous version. People familiar with the product are particularly likely to rely on remembered details.
Include the effective date, revised route or timing, meeting arrangement, changed inclusions and the contact for unresolved questions. Link the full current operating document rather than copying fragments into several chats.
If messages are supplied in different languages, verify the operational details in each. Use the guest-message translation checklist to preserve names, dates and meeting points.
Make the superseded material clearly identifiable within the team’s normal document process. Staff should be able to find the current version without comparing several nearly identical attachments.
Check the first departures and close the revision
Review the first operating days with the people delivering the service. Ask which guest questions or mismatches occurred and whether the listing describes the experience accurately.
Separate a service problem from a communication problem. If a meeting point is correct but guests cannot recognise it, improve the instruction. If the promised inclusion is not being delivered, resolve the underlying service before polishing the copy.
Keep a short revision record: issue, decision, owner and date. Apply any correction to every affected channel, not just the one where the problem was reported.
Close the reopening project when the operating version, sales surfaces, existing reservations and team instructions agree. Continue routine monitoring through the operator’s usual process.
Questions operators often ask
Can we copy the previous season’s listing? Use it as a starting document, then verify every concrete promise and practical field against the service being reopened.
Does blocking a date cancel its bookings? Do not assume so. Review the actual system behaviour and handle existing reservations separately through the applicable process.
Who owns the restart? Assign one product owner to coordinate evidence and updates, with the relevant operational and booking staff responsible for their decisions.
How much testing is enough? Cover the meaningful booking paths and any options that use different details. Record what was actually checked rather than declaring the whole product tested.
What should staff read first? The concise change brief with its effective date and a link to the current operating document.
Sources and workflow notes
Primary platform references reviewed on 22 October 2026: GetYourGuide’s availability management and cutoff settings. These describe that platform’s controls only. The reopening sequence, product-version method and fictional example are original editorial guidance. Adapt them to the operator’s systems, agreements and activity-specific requirements.
