A second travel brand creates another set of promises your team has to keep. Its website needs the right offers, its enquiries need to reach the right people and its customers need to recognise the business contacting them. Sharing technology can make the work easier. You still need to decide which details travel between brands and which stay separate.

Start with the decisions your team makes every week. Who changes an offer, who approves a service message and who can open a customer’s booking? Those questions expose the operating rules behind a multi-brand travel website setup. Answer them before copying the first site into a second design.

Decide what belongs to the group

A group can share a page structure while each brand keeps its own proposition. You might maintain a common layout for holiday pages, then give a family specialist different advice and enquiry questions from a luxury tailor-made brand. Write down which elements are shared and who can approve changes to them. Avoid leaving that decision to whoever happens to have the editor open.

Vibe’s agency and OTA platform describes separate storefront domains and designs using a shared supplier pool and mid-office. Travelgenix’s website builder describes managing several sites from one dashboard with roles and permissions. These are different published examples of managing several websites. Neither description settles how your own customer records, supplier accounts or staff responsibilities should be arranged.

Prepare a short operating brief for every brand. Include its intended audience, website address and person responsible for keeping the content current. Add the booking and support routes a customer should use. Keep that brief beside the brand assets so a new colleague can understand the business as well as recognise its logo.

Give shared content a named owner

Decide which material can genuinely be maintained centrally. A general packing guide may be suitable for several sites, while deposit wording or an out-of-hours contact may belong to one brand. Before reusing a block, check the claims it makes and the links inside it. A correct paragraph can still send customers to the wrong phone number.

Use a simple change record when central content is updated. Note what changed, which brands use it and who checked the final pages. If a local team can adapt the original, record whether later central changes replace its version or need a manual review. This is a process to agree with your website provider, not a feature to assume.

A useful test is to correct one fictional contact detail in a draft environment. Ask the team to show every place that uses it, including forms and confirmation messages. Then check a page where the brand deliberately uses a different contact. You want the correction to reach the intended places without wiping out an agreed exception.

Keep each assistant’s knowledge accurate

Your website copy and automated answers need the same discipline. Travelgenix’s Luna Chat for groups supports several websites under one login, with each site’s own brand, approved knowledge and inbox. Its published setup also connects each site to its own Travelify booking engine and App ID. These are specific Luna Chat capabilities, not a statement about every product’s access arrangements.

Give each site’s knowledge a reviewer who understands that brand. Check opening hours, booking instructions and the route for questions the assistant cannot answer. If the group changes a policy, identify the affected sites and review their answers. One shared management login doesn’t make the content correct by itself.

Test the same customer question on each brand after an update. Some answers should agree, while others should reflect a different service or contact route. Keep a note of the expected answer before testing. Where a response needs correction, fix the approved source and repeat the check.

Set access around the work people do

A content editor may need to update destination pages without access to booking records. Your central service team may need broader customer access, while a brand-specific consultant needs a narrower view. Write down those responsibilities separately for the website editor, reservation system and customer-management tools. Permissions in one service do not establish the permissions in another.

The ICO’s access-control guidance recommends assessing roles, reviewing access when responsibilities change and removing leavers’ access promptly. Use that guidance to organise your review with the person responsible for data protection. Ask each provider to demonstrate the agreed roles with fictional records. A demonstration helps you assess the configuration; it doesn’t establish legal compliance on its own.

Include temporary cover in the plan. If a colleague helps another brand during holidays, record who approves the access and when it should end. Check that any customer portal shows only the information intended for that account through the provider’s approved testing process. Use dummy customers, including a fictional person who has booked with both brands, to expose assumptions about shared logins.

Follow one enquiry beyond the website

Submit a test enquiry for each brand and follow it through the working day. Check the receiving inbox, the acknowledgement and the consultant’s reply. Then inspect the proposed quote or booking document. The customer should see the correct brand and know how to reach the team handling their trip.

Make reporting useful to the people doing the work. Record which brand generated the enquiry and which team is responsible for it, then decide how the group will review the combined picture. Keep the original brand visible when a central colleague takes over. Bring those requirements to your white-label website discussion so the implementation brief covers the whole customer journey.

Five actions before adding another brand

1. Write a one-page operating brief naming the brand’s audience, content owner and customer support route.

2. Mark each reusable content block as shared or brand-specific. Agree who approves changes and how exceptions are retained.

3. Review permissions separately in the website, booking and customer tools. Give temporary access an owner and an end date.

4. Run a fictional enquiry through acknowledgement, consultant reply and documentation. Check the brand at every handover.

5. Choose one upcoming content change and test it across your sites. Record the result before the next brand goes live.