We have just released an integration with Intercom to see if we can push our customer support experience to the next level. When you click help in the app from now on you will be presented with a dialog showing you all the communication you’ve ever had with us, and the ability to contact us with questions and feedback.

Intercom also gives us the ability to communicate more easily with our users. With Intercom we can broadcast notices to keep you up to date with what we are working on, let you know about new features, give tips on how to better leverage Guestlist, and more.

We have also released an Advanced Settings tab to give you more control over your events. There are some settings for events that don’t often need to be changed but are sometimes important.

The first setting we are making available in this section is order limit. This will restrict how many tickets of each ticket type can be purchased within an order. We occasionally receive requests for this but never saw it as something a most users should need to make decisions about. While we don’t want to burden users with unnecessary choices we also don’t want to limit needed functionality so we will be tucking away such options in this tab.

If you want to give us feedback on what we should be working on now would be the perfect time to give our new help section a try. Finally, support@guestlistapp.com will of course continue to work as before.

Have you ever wondered how people find out about your events? Are you better off promoting them on Twitter or via email? Starting today you can find out thanks to our new Google Analytics integration. Now you can drop your Web Property ID into Guestlist and gain access to all of the valuable visitor data you need.

Adding it is easy. Click “+ Add new profile” in your Google Analytics account and create a profile for the domain guestlistapp.com

Next, take the new Web Property ID (the code that looks like UA-12345678-9) and drop it into the Google Analytics pane in your Guestlist event settings.

That’s it! In a few hours the first visitor data will start showing up in your Google Analytics account.

We’ve just released our first take on coupon codes. This was one of our most commonly requested features so we are excited to see how people will make use of it.

As usual we’ve built a simple but flexible implementation that should accomodate a wide variety of use cases. We currently support percentage and fixed value discounts.

We have also thrown in a handy Generate Random Code button that will add a new coupon based on the last coupon created, and assign it a random code. This lets you quickly and easily generate a whole batch of coupons.

Up next we will be spending some time polishing interface elements and investing in performance improvements.

Now that the Rails 3 upgrade is behind us we can get back to iterating upon our user experience and feature set. There is still much that can be done to improve it and the most obvious case of this was probably the ticket types dialog.

Ticket descriptions

We noticed that a lot of people where cramming quite a bit information into the ticket name so we added a ticket description field.

The ticket description is the perfect place to put any qualifiers or clarifications that you may have regarding the ticket. Things like bonuses you get from buying this ticket or special requirements you may need.

The infamous Qty column

Other than PayPal, our biggest topic for support questions has been the ticket type dialog. There was a lot confusion as to what the Qty column was referring to. We had intended for it to indicate the number of tickets available for sale, but many people interpreted this as the number of tickets available per order. So some event hosts put a 1 or a 2 here and then became confused when their event sold out after only one sale.

Well, no more! We’ve renamed it “# to Sell” which is much clearer and also added a “# Sold” column as well.

Ticket statuses

Stopping sales on a particular ticket type used to be more difficult than it should have. One had to reduce the Qty field to below the amount already sold which, by the way, was also not so easy to find out. We’ve cleaned this up nicely by adding a status which can take one of three values:

Selling This is the default and behaves as you would expect. Tickets will be available for sale until the # to Sell equals # Sold.

Sold Out When a ticket type is marked as “Sold Out” we cut off sales and display it identically to actually sold out types on the public event page, regardless of how many tickets are remaining. This is good for hiding early bird tickets after the deadline has passed.

Hidden Hidden cuts off sales and completely hides the ticket type from the public event page. This is useful if you need to keep some of the ticket types for special use such as sponsorships or if you have made a price change that you do not want to be publicly visible.

Custom fields

And so much more…

We also fixed a myriad of small issues such as disabled dropdowns not looking disabled (they do now!) and the Guestlist fee dropdown being hard to understand (so hard in fact that we were frequently confused ourselves).

These are all minor changes but we feel it is important to address small points of confusion if you want to build a really solid user experience.

You might have noticed that it has been a little quiet around here of late. We haven’t gone anywhere and we certainly haven’t stopped improving Guestlist. On the contrary, we’ve actually rewritten it.

A little while ago Guestlist quietly cut over to a shiny new Rails 3 application. We did this without downtime and without anyone even noticing.

Wait, Guestlist wasn’t already Rails?

Many people probably thought Guestlist was already a Rails application. This is *almost* true. We built the original Guestlist using Merb, a Ruby framework that emphasizes modularity and performance. Because the Ruby web framework community is so fantastic we were able to make use of many Rails components even though we were using a different framework.

Why?

While the two frameworks were originally competing for mindshare, over time Merb became an important influence on Rails. In fact, the projects ended up merging and a number of core Merb committers did a huge amount of the work involved in making Rails 3 a reality. We were incredibly pleased with how well Rails 3 turned out and decided that we should invest the effort in upgrading our app in order to take advantage of all it has to offer.

How we did it

We were able to make the upgrade seamless by leveraging many of the great libraries that the Ruby web community has produced. We had Guestlist running on Rack and Unicorn even before they were part of a stable Merb release. We had been very early adopters of Bundler from back when it was still a Thor script that came packaged with Merb. Over time we replaced many Merb components with Rails-compatible Rack middleware. In early February we started swapping out major parts of the infrastructure, getting our large automated test suite to pass, and repeating.

When it came time for the final release we made our Merb and Rails deployment environments identical. This included the database schema, Nginx and Unicorn configurations along with all of the daemons, watchdogs and other monitoring infrastructure. We already use Unicorn for seamless, no-downtime upgrades so rolling out the Rails rewrite release was no different than a bugfix deploy.

Some stats:

• 242 commits, 903 files changed, 18771 insertions, 32006 deletions.
• 26 gems added, 23 gems removed, 33 gems upgraded, 27 gems unchanged.

It has been a lot of work but we’re very pleased with the results. We are already starting to make use of many Rails 3 goodies and will be announcing some of the great features we are building on them shortly.