Run a one-trip WingStack pilot with your charter broker

Choose a manageable first trip

Select a trip with enough lead time for setup and a clear coordinator on both sides. Avoid making the first test depend on a complex itinerary, several unfamiliar teams and an urgent departure at the same time. Complexity can come later, once the ordinary handoffs are understood.

State the pilot’s purpose in one sentence. For example: ‘We want the planner and traveler to know where the current itinerary lives and how to raise a trip question.’ That purpose is concrete enough to test and narrow enough to prevent the pilot from becoming an undefined migration project.

Agree on roles and boundaries

Decide which work will happen in WingStack and which existing processes remain in use during the pilot. Confirm who creates the trip, invites participants, reviews requests and communicates confirmed changes. Keep the authoritative location for each type of information explicit.

Use a joint walkthrough to check access before adding real passenger information. Ask each participant to show what they can see, not merely to confirm that they received an invitation.

• Planner owner and backup contact.
• Broker owner and urgent contact route.
• Traveler experience and access method.
• Location for the current itinerary and open requests.
• Process for confirming a change.
• Any pricing or commercial questions to resolve before use.

Test a change before testing the whole platform

Use fictional data to request a schedule adjustment or add a planning note. Follow it from the planner’s view to the broker’s response and the updated itinerary. Check who receives a notification and who requires a separate message.

Also test recovery. If a person cannot open their link or is looking at an old export, they should know where to get help. A small amount of preparation here is more useful than demonstrating every feature without testing an ordinary failure.

Review the pilot with evidence

After the trip, compare the result with the original purpose. Note where the team found the current information, whether requests had visible owners and where people still fell back to disconnected messages. Treat those observations as the basis for improvement.

Continue only with an agreed next scope. You might add another planner, a more complex itinerary or another part of the workflow. Keep the relationship with the broker central: the platform should support the service they provide and the coordination you need.

One-trip pilot review
Purpose we agreed to test:
What worked:
Where information was unclear:
Any access or notification issue:
Change needed before the next trip:
Owner and date:
Continue, revise or pause:
Next agreed scope: