Our blog has been rather quiet recently. For good reasons.
We've been working our heads off on product and business development.
Many new cool features, such as sections, you can discover on our demo.
Our team has expanded - Joren has joined as COO, responsible for business development and managing customer accounts.
And we’ve seen tremendous growth - the usage of seats.io has gone up by a factor of 20 year on year. Let’s hope we can keep that growth rate going.
Also, Ben and Joren will be present at the #TTF16 http://www.ticketingtechnologyforum.com. If you want to meet up with us, give us a shout or tweet us @seatsio.
Just as a FYI, the discussion paper on Protecting Ticket Sales from Bots http://www.ticketingtechnologyforum.com/public_downloads/TTF16-DiscussionPaper05-ProtectingTicketSalesfromBots.pdf illustrates a case study with Quakecon. And we’ll let you in on a little secret: their reserved seating uses seats.io charts.
Last year in june, we learned there’s a very ugly side to using a .io domain name: the people from the British Indian Ocean Territory, or Chagos Islands, don’t see a dime of the profits generated by the hugely popular .io TLD. In fact quite the opposite: these profits go to the British government. The same British government that repelled the Chagossians from their homeland some four decades ago.
In a previous blog post, we explained why we can’t just walk away from our domain name.
But we also promised to donate an amount to a Chagossian nonprofit organisation or cause, every time we would renew our domain name. Well, A promise is a promise, and since we recently bought a renewal for two years, we also donated 45£ to The UK Chagos Support Association .
(More info? Just read this and watch this)
If you’re running or working for a tech startup that has a .io domain name, consider donating to the The UK Chagos Support Association . They need all the help they can get.
We've been shortlisted for the Event Technology Awards 2014 in London in the "Best New Techology Startup" category. As the official online media partner of the awards, EIN publishes a digital online preview on the companies shortlisted.
Our users come from all over, and so naturally English isn’t necessarily the language used by all of our users. And that’s exactly why we recently made it easy to translate a seating chart, and display it to your users in their language.
In this blog post, we’ll show you how.
Translating tooltips
These are labels that the seating chart provides by itself, namely the texts in the tooltips that get shown when a user hovers over a seat or a section.
Right now, a seats.io chart contains only 4 of these:
"This seat is not available” (displayed when hovering a booked seat)
“X of Y seats available” (displayed when hovering a section that’s not fully booked)
“X seats available” (displayed when hovering a fully free section)
“No seats available” (displayed when hovering a fully booked section)
To show these in your language, just pass in a “language” config parameter:
new seatsio.SeatingChart({ ..., "language": "fr" }).render();
We currently support English (“en”, the default), French (“fr”), Dutch (“nl”), German(“de") and Spanish (“es”). You need another language? Please do get in touch, we’d be more than happy to add it!
Your own labels and texts
You also enter your own texts and labels in the chart designer, when you’re drawing your seating chart. You can for example add static texts on the seating chart itself (e.g. STAGE and ORGAN on our example chart), there’s the category labels that get displayed when you hover an available seat, etc.
To translate these, you need to pass in a messages config variable, like so:
(Please note: the keys in the messages object are cAsE sEnSiTivE!)
You can check out a working example on our site.
One more thing..
One thing we didn’t implement yet is the possiblity to change the language on the fly, i.e. **after **rendering a seating chart. Do you think this would be a useful addition? Let us know in the comments!
Today we'd like to share a story from one of our customers, Fleka.me. a design studio from Montenegro.
Fleka built a ticketing application for the beautiful Zetski dom royal theatre in Cetinje, and used seats.io to handle reserved seating.
Here's what Miloš Milošević, creative director at Fleka, says:
For quite some time we were searching for the best possible solution that would allow easy implementation of the seating chart as a service, so that we could feature it in various projects as a base for selling tickets. Our first implementation was for the website of Zetski Dom, Montenegrin Royal Theatre.
The solution presented by seats.io solved all our problems. It is very easy to implement, and managing booking and reservations of the seats is a breeze.
What makes this integration special, and that we needed the most, is the opportunity to get a very simple and easy system of drawing the seating chart, in a way that is most convenient for us. From start to finish, it took only an hour to have a ready seating chart with events for sale.
We would highly recommend seats.io to anybody who would like to implement simple but robust platform for managing seats and will definitely use it in all our other future projects. Keep up the good work!
We'd like to thank Fleka for the trust, and look forward to future collaborations!
We had many talks with you, our (potential) customer, and during those talks, many of you told us that "seats.io is very cool and yes, we need this to offer assigned seating to our customers, but your pricing won't work for us".
We heard you.
When we determined our initial model a couple of months ago, we based it on two assumptions: that most - if not all - of you would be charging a per ticket fee to your customers, and that you would like to pay for our software on a per ticket basis as well. These assumptions naturally led us to charge 8 cents per sold seat. Very flexible, and close to your business model.
Well, it turns out the above assumptions are wrong, and that because of that, many of you are hesitating to start selling reserved seats to your customers.
That's why we're making a radical switch: we decided to get rid of the transactional pricing model, and offer the seats.io in two fixed-price modes instead: as a Service (but priced per month instead of per sold seat), and as standalone software for a one-time fee.
In the SaaS version, we take care of hosting seats.io. You don’t need to worry about scaling under high load, updates or bug fixes. The price is a fixed per-month fee that's lower than the cost of a single developer day.
Next to that, we provide the option to host seats.io as a standalone application on your infrastructure. We'll sell you seats.io, the full application, for a one-time fee that's equivalent to about three years of using the SaaS version. You download the software, follow some easy installation steps and you’re done. We’ll help you if you encounter difficulties along the way. This package is great if you want to be in full control of whether and when upgrades should happen or if you the software to be tailored to your needs.
You can get more details and info on the pricing page of our website. Feedback is much appreciated!
In a recent article, David Meyer describes the dark side of the .io top-level domain. While doing his research for the article, David was looking for opinions of European .io tech startups for a reaction. He asked me whether I was aware of this background (which I wasn't), and after asking for permission, he quoted me in the article:
To us, the .io domain is not a geographical indication, but we took it because it refers to ‘input-output’. And our customers (mostly tech savvy people) understand it like so.
I'd like to explain.
When we started seats.io a bit over a year ago, we needed a name. And in Startuppia, a name is Everything. At the time, it was clear we would be selling reserved seating as an online service. We also knew that our product would be aimed at software developers, so the input/output reference and geeky tech feel to .io was important to us. The .io hype was well on its way by then, and when we found out that seats.io was free, the choice was quickly made.
Would we have chosen a different TLD if we had known .io's background? Probably so.
Should we have done our homework better? Most definitely yes!
Will we change our domain now? Well, no.
Why not change domains?
First, I stand behind the above quote; at least in perception, the .io TLD is not a geographical indication.
Or, to put it differently: nobody actually thinks that seats.io is a Chagossian company. I honestly believe that that's the case for nearly all other .io tech startups out there.
We chose seats.io only "to take advantage of the snappy input/output reference and the relative availability of names", as David puts it in his article. That too, I believe to be true for nearly all other .io tech startups out there.
Important note: This also implies that our usage of a .io domain does not imply approval of what's happened to the Chagossians in any way.
Does that make things right? Of course not, but that's a different matter, one which I'll address below.
A second reason for not changing to another TLD is that it wouldn't help the Chagossian people in any way. We already bought and paid for the seats.io domain name and by doing so already sponsored one side in the conflict. That's done, we can't change that.
Fixing things
The main concern of David's article is that Chagossian people don't profit from the popularity of their country-code top-level domain, that they are being exploited.
Now there's something we càn fix; we can make sure they get compensated for our use of their TLD.
So, every time we renew our domain name, we'll donate the same amount of money to a Chagossian nonprofit organisation or cause. For this year, we decided to support the crowd-funding campaign of the Chagos Islands soccer team on IndieGogo with a "Hat Trick" package. This will help the team with travel costs, practice rental fees and more.
If you have suggestions for other Chagissian causes we could support next, please let us know in the comments below!
Conclusion
I hope I was able to nuance our position a bit beyond the one-line quote; we still like the .io domain for it's geek-factor, but we do understand it comes with social responsibility.
And we hope that the Chagos Islands soccer team reaches its funding goal, perhaps even with support of other .io tech startups.
Best regards,
Ben Verbeken
Chief Everything Officer, seats.io
Categorising tickets may seem like an easy problem, but it really isn’t.
In this post, we’ll explain why this is important for your assigned seating events, and how seats.io can help you solve this.
Ticket prices can be determined by many factors, like the physical location of the seat (e.g. ground floor, balcony), ticket buyer properties (e.g. age, VIP status, … ), the moment of purchase (e.g. early bird tickets) and many more.
Most ticketing applications allow their users to define ticket types. In other words, they allow ticket sellers to determine price levels on just one of these dimensions. And rightfully so: you’ll want to make it as easy as possible to both sell and buy a ticket.
However, once assigned seating comes into the picture, it’s important to realise that pricing could become a matrix, as opposed to a one-dimensional list, simply because the ticket buyer will need to take two decisions at the same time: what age category do I belong to? and do I want ground floor or balcony tickets.
Huh?
Let’s take an example. We’re selling tickets for a concert in a theatre at the following prices:
normal tickets: 45 €
students: 20 €
Now if we want to use assigned seating for our event, we’ll want to adapt our pricing to a two-dimensional matrix, like so:
The point is this: any way you look at it, your ticket buyer will have to make two decisions: whether he’s a student or not, and whether he wants a seat on the ground floor, level 1 or level 2.
How does seats.io handle this?
We make a clear and clean distinction between those two dimensions:
The dimension that is directly linked to the physical location on the chart are what we call seat categories. In the example above: ground floor, balcony level 1 and balcony level 2. Those are defined when drawing the chart, so from within the seats.io chart drawer.
The other dimension, in the above example student vs normal tickets, are what we call ticket types. They are passed in as a parameter when rendering a chart for an event, and so are not stored in the seats.io database. The same is true for the actual ticket prices.
Seat categories
Since they are directly linked to the physical location of the seats on the chart, seat categories are defined when drawing the chart. You can add, remove and edit categories directly from within the seats.io chart drawer: go to category mode in the chart drawer, drag to select some seats and you’ll get this handy popup:
It’s important to note that seats.io only stores a key, name and color for a category. Or more explicitely: we don’t store pricing information at all, but you can pass in prices as an argument when rendering the a chart for a specific event.
Prices and Ticket Types
The exact prices per seat category and per ticket type can vary per event. Therefore, you can pass those in as a pricing parameter when rendering a seating chart for an event, like so:
When you use assigned seating, it’s important to understand you can categorize tickets by the physical location on the seating chart (aka seat categories), and by other dimensions like ticket buyer age (aka ticket types).
Seat categories are defined when drawing the seating chart, whereas ticket types are different for every event and as such can be passed in when rendering a chart for an event. The same is true for the actual prices, whether they are defined per seat category only, or as a two-dimensional seat category/ticket type matrix.
Over the past couple of weeks, we've been redesigning the seats.io chart drawer, today we're proud to be showing off the result.
Of course, you can see and test it for yourself, just head over to our homepage and check the demo.
So, what's new?
Basically it's the same chart drawer, but it looks a lot nicer (or so we like to think :)), and it's a good step forward in terms of usability. We styled and re-styled, removed buttons, added others, then removed some more.
In the process, we also removed some features that were hard to explain and used by very few people.
For example, the background image and calibration of seats have been removed.
Also, you don't have to worry about canvas size anymore. In the new chart drawer you get a huge canvas to draw on, and we'll crop it for you when rendering. Easier, right?
Of course, we can redesign all we want, it's user feedback we're after. So please, let us know what you think, either in the comments below or via twitter or email.
And what's next?
Right now, we're working on some feature requests we hear quite often, like table support. Expect something in the (very) near future!
It's about a year since we bought the seats.io domain name and decided to build a Seating as a Service thingie. It's been an interesting year, with many ups and downs, successes and failures.
And beer, mucho mucho beer.
Then, some weeks ago, EventBrite released their Reserved Seating into the wild. We were baffled. Perplexed by the beauty of it, the simplicity, the feature list. We wept, had fights between ourselves. And drank even more beer than before.
So it's time for a tough decision. If you can't beat them, join them. But if they don't want you to join them, you turn around and go do something else, and that's exactly what we'll do.
We won't throw everything in the bin though. We've got a good team, we're keeping that. Perhaps Matti will leave, or I will, but other than that the team will stay the same.
Second, we worked very hard on the marketing side. We established seats.io as a strong brand; when people hear 'seats.io', they hear 'quality'. So we'll try to transfer the sound of that to our new brand.
And then there's the seats.io logo. We took months to agree on the right color scheme and line thickness of our simple yet state-of-the-art logo. So our new logo would definitely need have those features.
Based on the previous reflections, Matti and I are very proud to announce that as of today, we're be re-branding to seeds.io. We've updated our logo accordingly:
At this point in time, there are many open questions. Like what exactly will we be selling? Will we sell it as a service or a product? Who will we be selling to?
However, we do know that it'll be a hell of a ride, and that we'll have loads of fun.
You probably didn't notice it, but app.seats.io hasn't been offline since 13 feb, not for a second.
This doesn't mean we didn't deploy new versions since then. In fact we deploy all the time, at least a couple of times a week. We just make sure there's no downtime while we're deploying a new version.
How?
We run on Heroku, a platform-as-a-service allows us to just push our git repo to a remote to deploy. We don't need to think about servers or system administration, they do that for us.
The neat thing is they have what they call a preboot feature: whenever Heroku is deploying a new version of our app, it won't shut down the old version until the new one is up and running. There's of course a bit more to it than that, but basically that's what happens.
Why is this important to you?
We talk a lot to people, and one of the concerns we hear all the time is the fact that client apps are dependent on app.seats.io being up: if you can't reach our API, you can't book seats, hence you can't sell tickets. Not good for business, right ;)
That's why we take good care of our code and invest time into the deployment process. And it's paying off: our last downtime was on 13 feb, the last day we deployed without Heroku's preboot feature. Since then: 100%, and we certainly plan to keep it that way.
So you want your customers to draw their own seating charts, without leaving your site? That's entirely possible. And it's easy too!
Create a seats.io account for your customer through our API
Show him the chart widget
Creating accounts
First of all, through our API, you can create sub accounts: user accounts that are linked to your account as parent. Each sub account has it's own collection of seating charts.
The advantage of using the API call is that your customers don't have to create an account on the seats.io website.
For all the details, check out our API documentation.
Showing the chart widget
We offer a widget that you can render on your site in an iFrame (or in a new window, that's up to you).
This widget allows your customers to:
draw new charts
edit existing charts
choose which chart to link to an event
The URL of the widget is https://app.seats.io/widget/manageEvent/login/{secretKey}/{eventKey}
Where {secretKey} is the secret key of the sub account, and {eventKey} a unique identifier for the event, which you can choose yourself. Typically, it's the primary key of the event record in your own database.
When a user chooses a chart, that information is stored in the seats.io database. We create a link between event A and chart B. To sell tickets for that event, you just include the chart rendering javascript in your sales form.
That's it really. In a following blog post, we'll take a look at integrating a seating chart for an event in your sales form.
If your online ticketshop doesn’t offer assigned seating to your ticket buyers, chances are you don’t store individual tickets in your system, but rather track ‘orders’.
For example, if a customer buys 4 tickets for a given category, you’ll typically store ‘4’ in a ‘numberOfTickets' field, instead of creating 4 individual rows in a ’tickets’ table. After all, why would you complicate things?
So, in order to start selling individual places, you’ll need to change your domain model and database structure, migrate your existing data, etc.
Let seats.io track the seats per order
We made a small change to the book/release seats API. As of now, you can pass in an extra ‘OrderId’ parameter when booking seats. If you do so, we’ll keep the link between an orderId and the booked seats on our side.
The best part? You don’t have to store any extra data at all to start offering assigned seating to your customers!
To book seats and make seats.io keep track of the orders, do a POST request to https://app.seats.io/api/book, with the following json body:
Now, suppose your customer can use your software to print his/her tickets. Of course, you’ll want to include the seat information, which is stored on our side.
To retrieve the seats for an order you can just do a GET request on https://app.seats.io/api/event/{eventKey}/orders/{orderId}/{secretKey} (replacing the variables in the url, obviously)
We’ll respond you with an array of all seat IDs, like so :
[“A-3",”A-5"]
Editing an order
Perhaps you allow your customers or an administrator to change an order after booking. To keep things in sync, you can just keep booking and releasing seats through the seats.io api as before.
To remove seats from an order, just release them (see the API docs). So here is what will happen, e.g. :
book A-1, A-3 and A-5 with orderId 'order555'
get seatIds for 'order555' results in ["A-1", "A-3", "A-5"]
release A-5 (no order id necessary!)
get seatIds for 'order555' results in ["A-1", "A-3"]
You can also book additional seats on an order, just by doing a call to the book api (again, see the docs), using the same orderId.
book A-1, A-3 and A-5 with orderId 'order555'
get seatIds for 'order555' results in ["A-1", "A-3", "A-5"]
book A-7 with orderId 'order555'
get seatIds for 'order555' results in ["A-1", "A-3", "A-5", "A-7"]
Conclusion
We believe this small change may make a huge difference to you in terms of development time, especially if you weren't storing individual tickets already.
Note: we want to stress that this is a purely optional feature. If you decide to not use it, that's fine; everything will work as before.
Should you have questions or remarks, get in touch or use the comment section below!
Feature highlight: Snap to grid & Background images
_Note: this blog post is obsolete since we released our new chart drawer. Background images were dropped for the time being_
We just released a new version with some new features and improvements, and want to highlight two of the features that will make your chart drawing simpler: snap to grid and background images.
Snap to grid
We've added a 'snap to grid' checkbox. It's checked by default, but if you uncheck it, your cursor won't get stuck in the grid, and we won't show you helper lines either.
This should make it easier for those of you who are trying to get their seats positioned pixel-perfect on a background image (see next section).
Background image on rendered charts
Originally we built the background image feature to ease the chart drawing process. Typically, you already have a scanned version of the seating chart somewhere, and want to draw the seats over it. So we allowed you to link up a background image, dim, scale and move it, and draw seats directly over the image.
Now it seems some of you want to actually use this feature to show the rendered seating chart for an event on a (colored) background as well. To make this possible, we've added a 'show on rendered charts' checkbox. When checked, your seating chart for an event will be rendered over the background image you selected.
A small caveat: we're just storing the URL to the image, not the image itself. Whether we'll do so in the future is still under discussion. Feel free to comment below!
Until next time!
Ben
PS: We'll be regularly posting more tips 'n tricks, tutorials and feature highlights on this blog from now on. Requests for specific topics are welcome of course.
