A mobile itinerary for travellers works best as one link, not an app. It opens in the phone's browser, shows the trip day by day in each place's local time with every voucher and who to call, and keeps working without signal once opened. Build it from the documents you issue, so the phone never contradicts the paper, and decide who sees it and for how long.

What the traveller needs from the phone, stage by stage

A trip page is read in short bursts, often in a queue. Design it for the question of the moment.

Stage What they look for What the page must answer
Before departure "Is everything ready? Is there anything I must do?" Every document, the terms to accept, a proposal to answer, the last day a service can be cancelled free
Travel day "When is the pick-up, and who is meeting me?" The flight, the pick-up time, the driver's name and phone, the meeting point
At the destination "What is today?" Today first, the hotel address to show a taxi driver, the venue's phone, the local time
When something changes "What is different since I last looked?" What was updated, and a notification if they asked for one
Something goes wrong "Whom do I call, now?" Your 24/7 line at the top, or the local line for where they are
After the trip Nothing, usually The link stops working on a date you chose

Notice what is missing: prices. The person holding the phone is often not the person who paid.

An app asks a traveller to find it in a store, install it and remember a password, for a trip that lasts ten days. Many will not, least of all the grandparents or a tour leader with forty people to look after.

A link asks for nothing. It arrives by WhatsApp or email, opens in the browser the phone already has, and wears your brand, not a store's. When you offer notifications, the page can also be installed on the home screen like an app, under your name. On an iPhone or iPad it must be installed before notifications can be turned on, so say so when you send the link.

The more important reason is upkeep. A separate app is a second copy of the trip that someone has to keep in step with the vouchers. A page built from the documents you issued cannot drift: issue a voucher again and the page shows the new one, marked as updated since the traveller's last visit.

Local time and no signal: the two traps

The clock

After a long flight, the phone may still show home time, and "pick-up 07:30" means nothing until the traveller knows whose 07:30.

  • Print every time on the place's own clock, with the zone named: WITA, IST, CET, or an offset such as UTC+04:00.
  • When a day crosses zones, a flight day, name the zone on each line rather than once for the day.
  • Show the time at the destination now, so the traveller can check their own phone against it.
  • Write dates in words, in the reader's language. 03/04 is a different day in different countries.

The page is the itinerary you issued; for writing one that reads well on paper and on a phone, see the travel itinerary template.

The signal

Signal fails where travellers need their papers most: airports, ferries, mountain roads.

  • The first open needs a connection. After that, the page, every document it links to and the files you showed the traveller are kept on that phone and open without signal.
  • The page says when it is reading the saved copy, and from what time.
  • A re-issued document replaces the old one on the phone the next time it connects.
  • A withdrawn link deletes the saved copy the next time the phone reaches it.

The practical advice for your traveller: open the link once on Wi-Fi before leaving home.

One page for the trip, one per traveller, one for all their trips

A family of four can share one page. A group cannot always.

  • The trip page shows the whole party's plans. Send it to the lead traveller or the organiser.
  • A page per traveller shows only the services that person goes on, plus everything shared. Use it when plans differ: two people leaving early, a corporate group on different flights.
  • "Show: everyone / name" on the trip page lets the organiser look at one person's plans without a second link.
  • All of a person's trips on one link suits a repeat client with several trips booked: each trip with a live page, upcoming first.

When a trip is booked through a partner agency, the traveller is theirs. Papers issued on the agency's behalf carry its name, logo and colour, never yours, and so does the trip page; a traveller's link is made for the agency to forward.

What you can switch on, and what each needs from you

Everything beyond the basic page starts off. Turn on what your team can keep up with.

Feature What the traveller sees What you do first
Route map The trip's stops on a map, with directions to each Switch it on, then issue the itinerary again
Weather The forecast at each stop for the next nine days, never printed Switch it on, choose °C or °F
Good to know Your notes per country or place, in the traveller's language where you wrote one Write the notes; a switch also prints them
Packing list A list with boxes to tick, kept on their own phone Write the lists; a switch also prints them
Meals per day Which meals are included each day Switch it on
Country facts Plug types, voltage, emergency numbers, side of the road Switch it on
Message us A form to write to your team; your answers appear on the page Switch it on, and decide who watches Messages
Notifications "Notify me about changes" on the page Switch it on
Flight alerts Delays, cancellations and gate or terminal changes before take-off Bring your own flight-status key, switch it on, set the delay worth telling
Messages from you "Your documents are ready", tomorrow's times the evening before, "your documents were updated" Switch on each one you want

The map, and anything printed, is fixed when an itinerary is issued, so issue it again after changing those switches. The weather is read fresh each time, because a forecast is not paper.

A trip page is a public link, and it will be forwarded. Treat it that way.

  • It shows only what the traveller's copies print. Your cost, margin, net rates, supplier references and internal notes never appear, and the page itself shows no amounts. Passport numbers never print on a traveller's copy.
  • It is not for search engines. The page asks not to be indexed, sends no referrer when a link on it is followed, and is not kept by caches.
  • It has its own random token, separate from every document's QR code, and answers only on your account's own web address. Each voucher on it still carries its QR for the hotel desk; see voucher QR verification.
  • It stops after the trip: 14, 30, 60, 90, 180 or 365 days after the last day, your choice, with 90 as the starting value.
  • You can withdraw it at once. The old link stops answering, the phones that asked for notifications are forgotten, and the trip gets a new link you can send again.
  • You can see whether it was opened: first time, last time and how often, counted from a real browser.
  • Messages stay private. Each traveller's own page has its own conversation, which no fellow traveller reads.

A group trip, worked through

Say six friends travel for seven nights: three in one town, four in another. Four fly home together on the last day. Two leave two days early.

What you issue Who it is for
One itinerary for the whole trip Everyone
Arrival transfer, both hotels, a day tour, the transfer between towns Everyone
Departure transfer on day 6 The two leaving early
Departure transfer on day 8 The other four

You set who goes on each departure transfer, send the trip page to the organiser, and a page each to the two leaving early. Their pages show the cards for the shared services and their own departure, not the other four's; the itinerary itself stays the whole trip's.

Both turned on notifications on their own pages. On the evening of day 5, with the evening message switched on, they get tomorrow's pick-up time on the local clock. Their flight, typed on their departure transfer, is then delayed by 45 minutes. With flight alerts on and a 30-minute threshold, they are told on their phones before take-off, the person looking after the trip is told, and the transfer is flagged "pick-up may need to move" until someone edits it. The organiser's trip page covers the whole party, so phones that asked there are told too.

How iTravel Vouchers builds it

In iTravel Vouchers the trip page is built from the traveller copies you issue: the itinerary day by day, a card per service with its time on the place's own clock, the address with a map, the venue's phone, the driver or guide with a number to call, and every voucher to open or download. Your 24/7 line comes first, today is marked, and "Before you travel" lists the terms to accept, a proposal to answer and the last day to cancel free. The page reads in any of 32 languages, right to left where the language is, and a service nobody has confirmed yet shows as awaiting confirmation. Which paper carries what is in tour vouchers, hotel vouchers and the itinerary, what the hotel's own copy needs in what a hotel voucher must show, and how the confirmation numbers on those vouchers stay right in the hotel reconfirmation process. The product as a whole: travel voucher software.

  • [ ] Issue the itinerary and a voucher for every service; the trip pack names any service still missing one.
  • [ ] Where plans differ, set who goes on each service, and make a page per traveller for those who need one.
  • [ ] Check your 24/7 line, and the local line for each destination if you keep one.
  • [ ] Decide which switches you want, and issue the itinerary again after changing any that print.
  • [ ] Write good-to-know notes for the countries you sell most, once.
  • [ ] Tell the traveller to open the link on Wi-Fi before they leave, and, on an iPhone, to add it to the home screen before turning notifications on.
  • [ ] Choose how long links live after a trip, and know who on your team withdraws one.
  • [ ] For a partner agency's trip, send the link to the agency, not the traveller.
  • [ ] After any change, issue the paper again: the page shows it as updated.