Dashboard
The "home" page of funnel.travel is a configurable dashboard. Available gadgets are:
The video below illustrates how the dashboard can be configured:
The corporate post-booking travel management tool
After signing up for funnel.travel, there are a few optional steps to refine the setup
Also, some points regarding your account you need to be aware of:
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 even 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. 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 |
| Contact email | |
| Code | The account code is mainly used internally, eg. in URLs |
| Financial settings | |
| VAT ID | If present, the VAT ID is printed on the invoice. Some countries have restrictions regarding tax handling and require a VAT ID to be printed on the invoice. |
| 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. |
| Use arrangers | If activated, arrange-specific fields on user / organization are visible. |
| Smart booking merge | If activated, funnel.travel will merge separate bookings for the same traveler into one trip. See Matching to an existing. |
| 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, 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.
While an account gives you some global settings, the main entity defining your corporate structure is the “organizational unit”. Users are connected to an organizational unit, and - by proxy - so are trips. 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 could 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 add corporate information to a trip. 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 |
| Data type | 'String' or 'Number' |
| 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'.
|
funnel.travel holds a global list of travel providers. Additional contact information and a comment field are available per account.
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.
| 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:
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.
The AERTiCKET extension processes Matrix XML from AERTiCKET.
| Execution trigger | Needs to be set to "TIME", as XMLs are fetched from the AERTiCKET server. |
| Agency number | Provided by AERTiCKET, also referred to as "KIM". |
| Customer system | The AERTiCKET extension allows to read a customer reference from the AERTiCKET "Interne Vorgangsnummer". If set, the customer number will be set using the provided 'customer system'. This is relevant for any downstream extensions looking for a system-specific customer number. Example: if sending data on to Gestour, the agent can enter a Gestour customer number, and configure "Customer system" to "Gestour". |
| Only invoiced | If set, unticketed flights are discarded |
Further processing rules:
This extension provides custom field values:
| branch | Taken from AFW2BRANCH remark, if present |
| invoiceNumber | Taken from the latest AER XML |
The "Amadeus AIR files" extension allows to read PNRs from files created by the Amadeus ProPrinter. The extension can work both as "pull" or "push".
If you'd like the extension to "pull" AIRs, you need to set up an SFTP server with username/password access. Configure the extension with "Time" event, set your desired CRON expression, and configure the SFTP properties. Per execution, the extension will read all available files, and subsequently delete them from the SFTP server..
If you'd like to "push" files to the extension, configure the extension with "Webhook" event and leave the file store controls empty. Once the extension settings are saved, funnel.travel provides you with a webhook URL. Upload files as multipart (using 'file' as parameter name). An example Windows Powershell script which uploads files can be found here.
| Process ghost segments | If checked, GK segments will be included in the generate booking data |
| Include travel preferences | If checked, seat and meal information will be included in the generate booking data if present in the PNR |
| Include passport data | If checked, SR DOCS will be included in the generate booking data |
| Include remarks | If checked, AIAN/RM/RX will be included in the generate booking data |
The Atriis extension uses the Atriis "Get Trip" to periodically fetch new and updated trips.
| Execution trigger | Needs to be set to "TIME", as Atriis has no "push" mechanism. |
| Currency handling |
|
| Discard from sources | Allows to list Atriis source systems for which services should be dropped. E.g. setting "Amadeus" will then discard all travel services booked in the Amadeus GDS. Multiple entries should be separated by comma or semicolon |
| Discard flights only | Allows to restrict above 'Discard from sources' setting to service type 'flight' only |
| Allow cross-modifies | If set and configured together with other producer extensions such as e.g. Sabre WS, funnel.travel will allow modifying an Atriis-generated booking by a Sabre PNR import. |
| Access credentials | Agency ID, endpoint, username, password and "shared key for credit card" will be provided by Atriis |
Further processing rules:
The "Bexio" extension allows to create and update quotes, invoices and purchase records in Bexio.
| API token | Access token generated in Bexio |
| Create quote | If set, the booking will be mapped to a Bexio quote |
| Create retail invoice | If set, the booking will be mapped to a Bexio invoice |
| Revenue account | The default revenue account number (usually 4 digits). Only needed when creating invoices. |
| Create purchase invoice | If set, the booking will be mapped to a Bexio purchase entry |
| Expense account | The default expense account number (usually 4 digits). Only needed when creating purchases. |
| Default customer | Identifies a default customer for quotes/invoices. Syntax is
<searchfield>:<searchterm>
see the Bexio documentation for possible 'searchfield'. Typically 'nr' is used, as in 'nr:123456'.
|
| On customer multi-match |
If the booking has a customer reference which results in multiple customers being found, should the system:
|
The "CETS WDM files" extension allows to read XML files from CETS created by the WebDataMover (WDM). The extension can work both as "pull" or "push".
The behavior and handling is identical to the Amadeus AIR files extension.
The cytric cCBD extension allows to receive booking updates from the "cytric Companion for Booking Data" (cCBD)
While the setup of cCBD in funnel.travel is straightforward, the required setup in cytric is not trivial, so please contact us if you're interested in connecting cytric to funnel.travel.
Also see the funnel.travel Using cytric blog post.
The Data Filter extension allows to selectively delete parts of a booking, usually in combination with a downstream consumer extension.
| Delete services with system reference for | Comma-separated list of systems (Service > References) which indicate a service should be deleted |
| System match | Matching logic for the systems listed above
|
| Delete only type | Optionally restrict delete logic to a certain service type |
| Delete priceitems matching | If non-empty, deletes price items with a description matching the regular expression |
| Overriding keep remark pattern | If non-empty and the booking contains a remark matching the regular expression, processing of the entire booking is aborted. |
The "Confirmation E-mails" extension connects to an IMAP email account, reads all emails for a given folder, and uses a third-party provider to parse the email.
| E-mail server (IMAP) | A server name, optionally with a port number (default is 993). The connection uses SSL/TLS. | ||||||||||||||||||||
| Username | Username for the email server access | ||||||||||||||||||||
| Password | Password for the email server access | ||||||||||||||||||||
| E-mail folder | Foldername, use INBOX for the root folder | ||||||||||||||||||||
| E-mail parser | Third-party system to use for the actual parsing:
| ||||||||||||||||||||
|
|||||||||||||||||||||
As an alternative to providing access to your own email server, we're also happy to provide you with a dedicated email address on our server. With this setup, it is your responsibility to forward any confirmation emails to the provided address.
Using this extension can be GDPR relevant, please make sure all the necessary approvals are in place before activating.
The "Galileo MIR files" extension allows to read PNRs from files created by the Galileo Print Manager. The extension can work both as "pull" or "push".
The behavior and handling is identical to the Amadeus AIR files extension.
The Gestour extension allows to push booking data to the Amadeus Gestour 360 midoffice.
| Agency code | Provided by Gestour |
| Default customer | Allows to set a default customer to receive bookings. Valid syntax is
JM84D2
|
| Brand | Optional, provided by Gestour |
| Ticket stock code | Provided by Gestour |
| On customer multimatch | Defines how customer handling should be the intial
customer search finds zero or more than one matches
|
Further processing rules:
Gestour has various settings which need to fit the bookings running through funnel.travel. This table gives an overview of the most common errors.
| Message | Cause |
|---|---|
| Problème d'enregistrement, la clé d'un item inséré est manquante. | A coded entry of the booking is not known in Gestour. Typically this is either an airline or a destination code. |
| Type de prestation du segment 0 incompatible avec son contenu | A fairly general-purpose error indicating that the Gestour segment data is deemed inconsistent. Check the booking data in funnel.travel for empty fields such as airline or destination. |
| Le montant RTU doit être inférieur ou égal au montant client | This error indicates a negative ticket amount. While this could occur when importing a refund for which the original ticket is missing, leading to a negative total amount. If the booking seems to be consistent, contact us so we can investigate. |
| Il manque le montant | This might occur on exchanges with a price 0.00. Make sure Gestour accepts a zero amount. |
| Erreur pendant la création d'une émission de titre | General-purpose error message that the booking couldn't be processed. Contact Gestour to get more information. |
The "File dump" extension allows to export trip data as JSON or XML to a remote server.
| Target URL | The target URL of your server. The server must be publicly accessible. While the URL format does allow for adding username and password, use the additional fields in order to prevent exposing the password. Allowed protocols are ftp, sftp and https. Use of FTP is discouraged. |
| Username | Username for authentication to your server |
| Password | Password for authentication to your server |
| File format | One of: 'XML', 'JSON' |
| Pattern for target file | The target filename can use a date pattern like
tripdata-${yyyyMMdd-HHmmss}.xml.
|
The Midoco extension uses the Midoco "AnnounceBookingMessage" to create and update bookings in Midoco.
| Include unconfirmed | If set, all booking data is sent to Midoco. If not set, only status 'CONFIRMED' and 'CANCELED' are sent. |
| ABM strategy | Allows to specify a custom strategy to create the AnnounceBookingMessage towards Midoco. |
Be sure to whitelist funnel.travel on the Midoco webservice user, activate the web service support, and to allow imports on the org. unit.
The Midoco ABM import extension allows to import booking data using the Midoco ABM format. Configure the extension as a webhook, and communicate the endpoint as SOAP endpoint to the producer of the ABM.
If configuring locators such as org. unit locators, be sure to use "MidocoImport" as source and not "Midoco", as the latter is used for the ABM export.
The Myclimate extension takes flight data and adds CO2 information.
| API URL | Provided by Myclimate |
| Username | Provided by Myclimate. Note that Myclimate typically only offers access if there is also a compensation scheme in place. |
| Password | Provided by Myclimate |
The Nezasa extension provides a webhook for Nezasa to trigger booking imports.
| Distribution channel ID | One or several distribution channels (separated by comma or semicolon) for which funnel.travel will register webhooks. |
| API URL | Usually https://api.nezasa.com/ |
| Username | The username of the Nezasa API user. |
| Password | The password of the Nezasa API user. |
| Tripbuilder URL | Optional URL of your tripbuilder. If present, funnel.travel will attempt to retrieve additional travel service information. |
| Preferred reference system | If set, funnel.travel will import agency and supplier information with a preference for the configured external system. If using this setting, make sure your reference data in Nezasa is adequately maintained. |
Nezasa webhooks: Nezasa notifies attached system of bookings and booking changes via a webhook call. funnel.travel registers webhooks for the booking status "booking_completed", "booking_change_completed" and "cancellation_completed". Note that there is no trigger for a booking in status "booking_initiated". This means that purely offered/quoted bookings will not be pushed to funnel.travel.
The "Sabre IUR files" extension allows to read IURs from files created by the Sabre Printing Module (SPM). The extension can work both as "pull" or "push".
The behavior and handling is identical to the Amadeus AIR files extension.
The "Sabre Webservices" extension allows to read PNRs from a Sabre queue.
The behavior and handling is identical to the Amadeus AIR files extension.
The Slack extension allows to set up notifications using Slack web hooks.
| Webhook URL | The URL your Slack admin setup in https://api.slack.com/incoming-webhooks |
| Displayed username | Slack notifications display a username. If this field is left empty, the default username defined on the web hook will be used |
| Message | Like most extensions, the Slack extension receives a full booking data structure.
Explore the structure at the funnel.travel API definition
to compose messages. Some examples:
|
| Channel | Webhooks have a default channel (used if this field is left empty), but can post on any channel. |
| Emoji icon | Any emoji code supported by slack (https://www.webfx.com/tools/emoji-cheat-sheet/). If left
empty, the extension default :airplane: is used. |
The Umbrella.net extension allows to push booking data to the Umbrella.net midoffice.
| Agency mapping | Allows to influence the origin and agency ID sent to Umbrella.net
|
| Default agency ID | Default / fallback agency ID. funnel.travel will attempt to match the incoming booking to an organization and use the agency locator from that organization. The "Agency ID" is used if that process fails. |
| Only confirmed/invoiced | If true, only confirmed and/or ticketed services are sent to Umbrella.net |
| EMD-A as ticket | Allows to define whether EMD-A should be imported as "ticket" in Umbrella.net, or as a simple price position. |
| Remark processor | Setting a 'remark processor' allows for processing Atriis
|
| Low cost service code | If set, "Non-BSP flight" services will use this product code |
| Smart modify | If set, bookings changes which do not affect Umbrella.net are dropped |
Further processing rules:
This extension provides custom field values:
| ship.route | Writes B2B 'route' on ship service |
| ship.accommodation | Writes B2B 'accommodation1' on ship service |
There are several more extensions being developed or in pilot-phase. If you're looking for a specific extension, contact us.