The corporate post-booking travel management tool
After signing up for funnel.travel, there are a few optional steps to refine the setup
Note: After signing up for funnel.travel, an e-mail with a verification link was sent to the e-mail address provided during sign up. Failing to verify will result in the account getting locked after 3 days.
funnel.travel has a fairly simple structure. The sections are:
The dashboard shows business trips as they progress from "departing soon"” to "currently away" to "recently returned". The home button navigates back to the dashboard
Most pages show a search bar. The search term(s) entered cover all searchable properties, ie. searching for "jackson" on the user page will search for "jackson" in the username, first and last name etc.
<=, >=, <, >
There are two input field types which support auto-complete. References to other funnel.travel entities always offer autocomplete, while regular input fields for dates (or date/time) will also expand the entry to a valid date
funnel.travel shows your name, organization and account name in the navigation bar (top left). For users with the authority to manage multiple organizational units (arrangers, client admin) or accounts (community admin, system admin), the displayed organization and account name switch to a dropdown on hover.
The "home" page of funnel.travel is a configurable dashboard. Gadgets can be added and arranged to immediately get an overview of the current status. Available gadgets are:
The video below illustrates how the dashboard can be configured:
A billing account serves several purposes:
Is the entity funnel.travel will invoice. Defines a set of rules for password security. Allows for adding a logo and/or changing some CSS styles Also, described in extensions in detail, the billing account holds the core extension setup.
| Company name | Company name, max. length is 128 characters |
| Address | the address printed on the invoice |
| Country | The country relevant for invoicing. Note that each organization has a separate location/country |
| Code | The account code is mainly used internally, eg. in URLs |
| System behavior | |
| Default locale | Locale used for new users |
| Max age returned trip | Trips with a return date older than the set value (in days) are deleted. Set to 0 to disable. |
| Delete idle user after | Users with a 'last returned' older than the set value (in days) are deleted. Set to 0 to disable. |
| Allow duplicate sources | If activated, funnel.travel will accept incoming booking payloads which are identical to the latest payload already received for the same booking. This setting should usually be inactive, but some scnearios require re-sending the same data (e.g. changing setups) |
| Smart booking merge | If activated, funnel.travel will merge separate bookings for the same traveler into one trip. See Matching to an existing. |
| Use arrangers | If activated, arrange-specific fields on user / organization are visible. |
| Traveler handling |
When receiving booking data from a producer extension, funnel.travel attempts to assign a traveler based on email address. If no traveler is found:
|
| Password fields |
These fields allow for adjusting the password security:
|
| Profilesync system | Allows for connecting funnel.travel to a traveler profile suite |
| Next trip ID | The next value for the funnel.travel trip identifier. Update with care, as setting to a lower value might result in the system attempting to generate trips with an already used identifier. |
| Look & feel | |
| CSS / Logo | See Look & feel |
Some extensions might require traveler profile data which is not present in funnel.travel. By connecting to a traveler profile suite such as Umbrella Faces or Amadeus Cytric, funnel.travel can retrieve traveler profiles and feed that data into the configured extensions.
| Profiletool system | Umbrella Faces | cytric cCPS |
|---|---|---|
| Profiletool endpoint | URL of Umbrella Faces server | URL of cCPS endpoint |
| Profiletool API key | API key provided by Umbrella | CLIENT ID |
| Profiletool group | - not used - | cCPS system name |
| Profiletool secret | API secret | CLIENT password |
The password security fields allow for defining password guidelines which are in line with your corporate standards.
funnel.travel allows for two basic means of adjusting corporate identity. A logo can be placed at the upper left corner, the logo height is limited to 50px. Furthermore, a custom CSS can be uploaded, with all the styling power which comes with CSS.
The main entity defining your corporate structure is the “organizational unit”. Users and trips are connected to an organizational unit. Thus, whatever structure defines your travel rules (budget, expense limits) and/or processes (eg. arranger assignment) should reflected as organizational unit. The name was chosen to be very generic, because organizational units can be many things:
Organizational units can have a parent organizational unit, which allows to map a hierarchy. Child organizational units inherit from their parent.
| Name | Name of the unit, max. length is 128 characters |
| Parent organization | By setting a parent organization, hierarchies can be defined. This is especially useful when working with organization-wide travel arrangers |
| Location | Geographical location of this organization unit. This location is used when processing trip data to determine what is the "home base" |
| Description | A free-text description of the organization unit, max. length is 128 characters |
| Locators | Travel agency locators such as a CETS agency ID, Amadeus OID or Galileo PCC. If the activated producer extension(s) have a status "source", locators can be used to assigned generated trips to organizations (and consequently consumer/modify extensions can be called with overriding settings). |
| Extension setting overrides | If the account has activated extensions which allow for per-organization settings overrides, those settings are listed here |
An organizational unit is linked to a billing account. It's noteworthy to point out that not all organizations of a hierarchy need to have identical billing accounts. While these are exceptional cases, funnel.travel allows for a travel arranger to access trip data in a organization hierarchy while the underlying usage might get billed to different accounts.
The structure illustrated above allows for a variety of administration mappings:
Users in funnel.travel are held to a rather minimal data structure. Note that funnel.travel is not a traveler profile management tool. Users are identified by email address, which is this expected to be unique per user.
Apart from the typical user fields such as username and password, funnel.travel defines:
| First name non-APIS | First name used for non-APIS bookings. e.g. Robert Brown might book hotels as Bobby Brown |
| Arranger / Arranger type | If 'arranger' toggle is enabled, individual travelers or entire organization units can be assigned to the arranger (depending on arranger type) |
| Technical user | If activated, this user is used to assign organizational units via email lookup. |
| Identifiers | Agent identifiers such as an agent sign or email. |
Two additional users can be merged. This functionality is mainly used when "Auto-create participants" is enabled on the billing account, as this might occasionally produce multiple entries for the same user.
When merging a user Jonny to another user John:
Custom fields can be defined to hold additional information on a trip, booking or travel service. Typical examples are a cost center or invoicing guideline. Custom fields are always linked to a specific account, but can be further restricted to individual organization units.
| Name | Name of the field, which will be used to dislpay on the trip UI |
| Granularity | Defines on what level the field applies: 'Trip', 'Booking' or 'Travelservice' |
| Data type | 'String', 'Long string' or 'Number'. Both string options can hold the same amount of data, the difference is merely in the UI representation |
| Edit directive |
|
| Remark pattern | A regular expression which must contain exactly one group. The group value will be used
as custom field value.
AFW2BRANCH-(\d+)
for a remark AFW2BRANCH-22 will store the value '22'.
|
| Names per extension | The "Names per extension" allow to create a link between extensions. Check the extension documentation on possible field names. |
funnel.travel holds a global list of travel providers. Additional contact information, a comment field and extension-specific mappings are available per account or community.
funnel.travel maintains a hierarchical list of mappings:
To resell entire bookings under your own supplier code, use the "Own account (use for reselling)" supplier and add incoming and outgoing identifiers. The video below illustrates how provider mappings can be configured:
Find the supplier in the list, check if there is already a global mapping for TravelC (and add if not), then add the TravelOperations vendor code:
Take the "Own account (use for reselling)" supplier, add the Nezasa distribution channel(s) as incoming, and the default package code for Midoco:
| Producer | Consumer | Setup |
|---|---|---|
| Sends fixed supplier ID | Expects fixed supplier ID | Add custom provider mappings for the producer and consumer system name |
| Allows for "external supplier IDs" | Expects fixed supplier ID | There are multiple options:
|
| Sends fixed supplier ID | Allows for "external supplier IDs" | There are multiple options:
|
A key consideration is where supplier management takes place. We typically recommend to configure as much as possible in the surrounding systems.
funnel.travel allows for exporting both configuration data as well as trips to JSON files.
Extensions are where things get interesting. There are three kinds of extensions
Without at least one producer extension, all trips would need to be entered manually in funnel.travel. Without at least one consumer extension, trip data would reside in funnel.travel only.
Producers deliver trip data into funnel.travel. There are several delivery mechanisms:
All producers share a basic configuration (and then additional, custom configurations per extension):
| Purpose | Free text field to describe the setting, eg. "Import Amadeus PNR" |
| Execution trigger |
Can be either "Time" or "Webhook"; the former represents a "pull" mechanism, the latter a push. When choosing "Time", two additional settings are available:
|
| Override retries | Allows to override the default retry behavior |
| Override notifications | Allows to override the default notification behavior |
| Include travel preferences | GDPR-related setting to indicate whether traveler preferences should be processed.* |
| Include passport data | GDPR-related setting to indicate whether passport data should be processed.* |
| Include remarks | GDPR-related setting to indicate whether booking remarks should be processed.* |
* Whether or not to activate these settings depends on the data stream, ie. the activated modifiers and consumers. Only enable processing for data elements which a modifier and/or consumer extension needs.
Modifiers read trip data from funnel.travel and send trip data back. This can be to augment booking data with eg. flight statistics, but can also execute a ticketing robotic and thus modify the PNR.
Modifiers have the same set of common configuration as Consumers, see the field table there.
Consumers read trip data from funnel.travel. There are two delivery mechanisms: "Event" and "Time".
All consumers share a basic configuration (and then additional, custom configurations per extension):
| Purpose | Free text field to describe the setting, eg. "Feed Viselio API" |
| Execution trigger |
Can be either "Time" or "Event". When choosing "Time", an additional setting "Time expression" is available:
|
| Limit execution | "Once" will only process a booking once, "Unlimited" will consume the booking whenever the execution trigger fires. |
| Override retries | Allows to override the default retry behavior |
| Override notifications | Allows to override the default notification behavior |
| Process bookings from | Allows to limit modifier/consumer to selected producers. |
A common mistake is to choose an "Event"-based execution with "Created / modified" in order to process new bookings as well as modifies, but then to leave "Limit execution" at "Once". This effectively disables the modify, as the booking creation will trigger the single execution, after which no more processing occurs.
When using an "Offset to booking event", funnel.travel will create a PENDING extension processing entry (visualized as an hourglass) with an entry date. A background process then regularly checks for PENDING entries with an entry date older than the offset, and process any matching entries.
A key point to note is that any producer updates will cause the entry date to be re-set. Thus if a producer continuously updates a booking, the delayed processing get pushed back repeatedly.
| Scenario | Setup |
|---|---|
| Simple producer + consumer | No special settings needed |
| Producer + modifier + consumer | The consumer will only be called when the modifier was executed.
|
| Multiple modifiers | Modifier extensions are daisy-chained, in the order they appear in the extension setup. A subsequent modifier is only called once the previous was executed. |
| Multiple consumers | Consumers are called concurrently, so no consumer can count on having available the processing result of another consumer. |
Upon entering funnel.travel, extension states are stored per booking and configured extension. If the extension is only triggered in the future, the states remains as 'PENDING' until execution time is reached.
For calls which resulted in an error:
funnel.travel has a simple but powerful retry / notification configuration in case of extension errors.
| Defaults for error handling | |
| Retry on error | If enabled, funnel.travel will re-try calling the extension periodically (about every 15min). If disabled, the ERROR state can only be resolved manually. |
| Retry for how many hours | Only relevant if "Retry on error" is set. Describes the maximum time span since the first call attempt during which retries should be attempted. |
| Notify via channel | Currently available options are: NONE | EMAIL | SLACK | RINGCENTRAL | TEAMS |
| Channel | For 'EMAIL': the email address the notification should be sent to. For 'SLACK': the Slack webhook the notification should be sent to. For 'TEAMS': the Teams 'Incoming Webhook' URL |
The default settings can be overridden per extension. The workflow is:
The trip detail view gives an overview of the travel services, the bookings, a change log and the status of extensions related to this trip. Action buttons on the top right allow for switching to edit mode, or download the trip as a JSON file.
funnel.travel takes a trip-centric view to customer management. Each booking can hold address and contact information for one customer, this is typically the invoiced customer (i.e. not necessarily the traveling customer). Customer data is not sync'ed across bookings, so if Max Mustermann has several bookings, his address information is duplicated per booking
Apart from address and contact data, funnel.travel can hold 0..n customer reference numbers. These are useful when a producer extension can send a customer reference relevant to a downstream consumer extension.
Travelers are managed according to the "Traveler handling" setting on the billing account. If traveler profiles are kept in funnel.travel, a profile can be assigned to the booking traveler. A very common approach is to use an external profile system tool and manage profile locators in the booking. With this apporach, no traveler profiles need to be kept in funnel.travel.
Additional to the standard search options, the trip search offers a few special keywords:
For a new trip, funnel.travel will assign the trip to an organizational unit based on the following criteria:
For an incoming, new booking, funnel.travel will attempt to locate an existing business trip which to append the booking to. An existing trip will be used based on the following criteria:
When using the web client to edit trip data, an internal technical reference (UUID) is used to determine which data entries are to be updated. This approach is deterministic and always yields an updated trip (and the bookings therein) matching the data edited on the screen.
When receiving a booking data update through an extension, however, there typically is no technical reference to work with. In such cases, funnel.travel attempts to locate existing entries based on identifying properties which are assumed to be immutable. As consequence, a change in these identifying properties leads to deletion of the "old" entry and insert of the "new" entry.
Example: given an existing trip with a flight ZRH - EDI, flight no. LX123, departing June 6th at 10.15am. If an extension now sends booking information for a flight ZRH - EDI, flight no. LX123, departing June 6th at 2.20pm, funnel.travel will match this to the existing flight and update the departure time. If an extension then sends booking information for a flight ZRH - EDI, flight no. BA999, departing June 6th at 10.55am, funnel.travel will not match this as the flight number is expected to not change. Consequently, the existing LX123 flight is deleted, and BA999 is added as a new flight.
There are only very few data issues which influence data processing in funnel.travel
Trips with data issues are listed on the dashboard in the 'Issues' column
If an extension call resulted in an ERROR, the call can be retried manually by clicking on the 
icon.
If a traveler profile suite is configured (see billing account setup), funnel.travel will attempt to augment booking data with extended profile data per passenger. In the following sequence, there is a distinction between the 'booking traveler' and a 'funnel.travel user'. The former is bound to the booking, and contains only data provided by the producer extension which created the booking. The latter is a user. Each booking traveler can be associated to a funnel.travel user, but it is common practice to work only with booking travelers and not maintain a funnel.travel user base.
The lookup hierarchy is:
While funnel.travel does not hold credit card numbers, it does allow to pass on tokenized data from an external payment provider. On the Extension setup page a callback link is displayed. For payment providers offering a webhook callback holding payment transaction data, this URL can be configured in the payment provider system. funnel.travel will then receive the transaction data, link it to a booking via transaction ID, and make the form of payment data available to downstream extensions.
funnel.travel offers a very basic built-in reporting. For any more advanced reporting, an extension should be used to export data in the desired format.
