Hi Lobengula, we've thought about that and we designed our service so that casual travelers can subscribe for only the months they need, at the service level they need, only when they need it. So you can subscribe for a month then set your account not to renew for as long as you like, then reactivate it only when you need it again.

The problem with a metered service with Premium features is that the Flight/Seat Alerts services are not user search driven, the alert checks happen in the background 24 hrs a day. So 100 queries/month would either have to not apply to every time the system checks and alert, or it would, and the 100 queries would be used up rather fast. Since airline data isn't free, and we pay for every search (every class/day is a separate search, we just combine them for you), the first option wouldn't be feasible.

This is why our Basic service, which allows for 250 queries/month but without the alerting services and multi-day/class searching, is only $4.99/mo. Also you have to factor in that the credit card processing fees have a fixed cost component to them, so the lower the charged amount, the greater percentage goes to the credit card companies in fees, making it relatively more expensive to provide a service at lower price points.

Since launching ExpertFlyer in January 2005, we haven't raised our prices once, while continuing to add features and tools to the service. All that being said, we're always open to suggestion so feel free to email us at [email protected] with any suggestions.

I did try some searches filtering for a specific connecting city as I noted in my post. By doing this, I then need to search separately for the outbound/inbound because it is very often that a different connecting city provides the best option (eg. LH via FRA outbound, SK via IAD return).

By removing Interline Connections, then I don't find exactly the type of non-obvious options that I'm hoping to find.

I didn't adjust for time of day of departure, because I want to find the shortest total flight time, regardless of departure time. Normally, I would not choose to depart at 6 am, but if doing so gives me 12-hours total travel time instead of 17-hours, I'll do it.

I'm also curious as to why the filter for "Connection Preference" is either direct/non-stop, or "at least 1 connection" or "at least 2 connections." I cannot select direct/non-stop because I know that doesn't exist on my route, although it would certainly be my preference. But I'd like to filter for "maximum 1 connection" as opposed to "at least 1 connection." Is there a reason that this isn't an option? I'm sure that would help narrow down my search significantly to the options I am most interested in.

I actually thought I had done that in my post. :) I provided the city pairs, and the various non-filtered and filtered queries I tried, and mentioned the flights I did not see that I would have expected to see. Dates are a ca. 3-week trip with departure dates from 30 Oct through 7 November but I'll certainly send an email to customer care - thanks.

I guess what I was trying to say is that if the flights I'm expecting to see are missing, then I don't know what attractive options might be out there that I'm not seeing. I was hoping to find a route or connection that I wasn't aware of - but since even some of the most direct routes are missing (eg. SK on the outbound when filtering for EWR as connecting city), my confidence level in the tool was lowered.

Susan

Following my previous post, I've been playing with EF quite a bit, and wanted to share one of the specific queries to give an idea of why I'm frustrated, and perhaps someone can chime in and say where/how I'm querying incorrectly.

My route is CPH-MCO and return. I know that DL is flying my preferred connection of CPH-ATL-MCO for the last time this season on October 30. So that is my outbound date, since I'll want the CPH-ATL direct flight (DL 69) on the outbound.

So now the challenge is to find a return route on DL or another SkyTeam airline, without connecting through JFK, and preferably also not connecting through CDG, and avoiding the 757 TATL.

If I filter for SkyTeam only, my return options, depending on the date (ca. 15-19 Nov) are to fly (1) MCO-ATL-CDG-CPH, or (2) MCO-CVG-CDG-CPH, or (3) MCO-JFK-AMS-CPH, or (4) MCO-JFK-CPH. But it does not return an option of MCO-ATL-AMS-CPH, which I know should be an option.

Therefore, to force it, I enter AMS as the connecting city. But when I do that, EF only returns options for (1) MCO-JFK-AMS-CPH, or (2) MCO-DTW-AMS-CPH. Yet I know there should be options for MCO-ATL-AMS-CPH, but it will not display them.

So I change the query from CPH-MCO connecting AMS, to just CPH-ATL connecting in AMS. This time, I get two options for ATL-AMS-CPH, one departing ATL at 17.40 and one departing ATL at 21.35. One is on an Airbus 333 and the other on a 777. So these are definitely flights I would consider if I cannot find a better option with only one connection.

I know for a fact that there are plenty of DL and SkyTeam flights that fly from MCO-ATL that will get me to ATL in good time for both of those departures. So why, when I query for MCO-CPH via AMS, does it not return any of these options?

Susan

To be honest, and I am a loyal EF subscriber, I would tend to use ITA for this sort of search. If you learn the ITA route language, this is easy to do, and the graphical results display is particularly useful. Try:

from: mco:: atl ams
to: cph

or, if you prefer to show the DL TATL flights only:

from: mco:: dl atl dl ams
to: cph

Hi Susan, I think we can help you.

Yes. The reason we don't have "maximum 1 connection", and why it won't help you if we did, is because the GDS returns flight in order of connections anyway. So non-stops come first, then directs, then 1 stops, then 2-stops. If, like you said, there are no non-stop or direct flights, then the results would be exactly the same, as the 1-connection flights would be shown first in either case.

The reason for the "at least" options is because it helps users planning mileage runs to force the GDS to return connection options where only non-stop or direct flights would show.


Thanks, it was the dates that were missing, we need to make sure we're seeing what you're seeing to help.

That's why we have 2 connecting airport boxes. You can specify both ATL and AMS as connecting cities to force the return of the MCO-ATL-AMS-CPH options. The request should look like this:

Departing MCO on 11/15/10 12:00 AM for CPH
Flying DL
Connecting at ATL AMS

In doing this, we just discovered a bug where if you specify SkyTeam instead of a specific airline the search will fail with both connecting cities specified. It's a GDS bug but we can work around it from our end, give us a couple days to post the fix. In the mean time, specifying DL should give you the flights you're looking for. If you specify a return date in the search, the system will reverse the order of the connecting cities for the return search.

Also, since these are 3-segment options, only a maximum of 4 will be returned for any search since the GDS can only return a maximum of 12 flights total per search.

It would be perfect if it worked this way, but I'm seeing 2-connection flights in a query where I know there are 1-connection flights that are not displayed. That's why I thought being able to limit for "max. 1 connection" might assist.

Even if I query just for SK, as another example, I don't get all the SK 1-connection options, but only a small sample. I'll have to run this again to see if the limit is due to the 12-flight option, which is possible. I know that sometimes it will return several options with the same TATL flight, and then just a longer layover on the connection, instead of giving a different connection option.

Thanks! Ahhh, the 12-flight maximum seems to be the major limiting factor then.

I really appreciate your quick replies and willingness to help. It does sound like EF is more suited to the traveler who knows precisely what airlines / alliance / connecting cities one wants and not necessarily a tool to identify lesser known options to answer questions like "what are the 1-connection options with the best itineraries for getting from point A to point B."

Fair enough, it was built with frequent flyers in mind who usually know what they're looking for. And that's how I've been using it for 3+ years (to find Z upgrades on DL when I want to purchase an M fare). I guess I'm trying to find a needle in a haystack here, and that wasn't its purpose!

Cheers,
Susan

It does work that way. If there isn't a 1-connection option being shown, there is a reason for it. Please email us the exact search you are doing, with date, and the exact 1 connection flights you think should be shown for that search and we'll look at it and explain what is happening.

If the amount of flights returned = 12, then that's what it is.

We have the ability to adjust the valid connection times of the flight returned, both min and max. Please also email us this exact example and what flights are missing and we'll see if manipulating the request can lead to better results. It needs to be via [email protected] so we can easily share with our developers, thanks.

Seatmaps
 

Unlike usual demanding suggestions I would now like to suggest that seatmap comboboxes should already have certain values by default (I think starting from the lowest class would suit most of the people; anyway now everyone has to do some unnecessary clicks).

That in my understanding of webforms does not cost a penny.

Seatmaps-2
 

Hi, SQ 388 flights do not seem to have economy in seatmaps (eg SQ334 on 08-Jan-11). But they have first class (non-suites) which in fact does not exist on this flight.

Connections
 

If possible, adjusting max connection time would benefit to those searching for cheapest inventory (where married segments should be used) in case an overnight stay is OK if that significantly reduces the cost. The system does not seem to include long overnight connections so far [24 hours should be considered as MAX].

Adjusting the form doesn't cost anything, but the searches do. Each cabin is its own search, and each search has a cost to it. So if we pre-populate the cabin boxes with cabins that you may not be looking for, it adds to the cost to the search that otherwise wouldn't be the case.

We took a look at that seat map and it exactly matches what we see here: http://www.seatguru.com/airlines/Sin...irbus_A380.php Did I miss something? That flight does have the First Class Suites (because it's publishing an R class) and as we state at the top of the page for an SQ seat map result: "SQ Does not publish Y class seat availability."

Yes, and we do, but only when at least one connection airport is specified. The way the GDS search works is that we can specify a max connection time, but the system only accepts that parameter with a specified connection city. It is currently set at 16 hours. We are looking for a way to specify a max connection time even when no connection city is specified, however if it's not possible, our asking for it won't amount to much.

Try the search again with a connecting city and let me know if the connection you want to see still doesn't show up.

The seat map prepopulation thing annoys the snot out of me too, and I would also vote to add the economy cabin as the default selection. You know that when someone clicks on the seat map icon, they are going to select at least ONE seat map, so prepopulating one wouldn't increase the number of queries EF pays for. I would humbly suggest that rather than dismissing a suggestion outright due to cost concerns, a small-scale test could be conducted. You might find that the increase in cost is marginal or negligible. In my case, EF's cost might even go down, since the lack of any prepopulated values has "trained" me to use the keyboard to select First and Economy cabins every time (F, tab, E), even when I only care about one cabin.

While we're on the subject of prepopulation, I would suggest adding a default name to the "Save Query" text box to allow easy 1-click saves. I often have a handful of queries saved so I want to give them names that distinguish them by date and destination (eg "2010-08-28 SEA-ORD"). A default name that included this info would save a lot of redundant typing. (Using the date format above means that the queries are sorted by date in the saved queries list, too, allowing for easy access later.)

I apologize if I gave the impression that we were dismissing the suggestion outright, that's not the case. We've been asked this before and we decided a long time ago that we weren't going to do it. One persons default may be another persons annoyance that they have to change. However we will gladly revisit the issue after our current round of changes are complete.

Same for the Save Query text box. What you suggested may work for you, but we've seen all manner of different descriptive names and labels for saved queries. What if the search is airline, or in the case of an Award/Upgrade query, class specific, when do we decide to add that in too? Some users may like such a feature, some may dislike it because now they have to clear out the default so they can type what they want. Again, we'll gladly take another look, but in general we try to shy away from these universal defaults.

Well, I thought GDSs have flat subscription rates unless you use premium services like low fare search in Amadeus. So, that there my suggestion came from (that is I did not even think of increased costs possibility).


I agree, I forgot SQ does not publish Y seatmaps (only there website does, or at least did it). Anyway, there is no "First Class" which is shown as option, only "first class suites". I noticed further that sometimes classes in the list do not match the classes available on a specific flight. So this should be a bigger issue, but personally I don't care for this bug as long as I get more important information.

If only... the low fare searches are even more expensive then the basic and regular fare searches, all are pay per use, on top of additional fixed fees.

No worries. The options in the Cabin combo boxes don't change for every flight, they are per airline and represent all possible cabins for the airline. So that flight may not have a regular First cabin, but other SQ flights do.