Not long ago I asked a few questions of the team behind the LSO Pulse project about how the project had gone and the lessons learned. But for this particular project, it wasn’t the end because a brand new project, Student Pulse, has been born straight from the successes of the Digital R&D Fund project.
Nico Koepke, CEO of KODIME, the tech company involved in the LSO Pulse app programme, talked me through the evolution of the new project. The original Pulse project finished late in the summer, and with the program’s objectives having been achieved (and generally positive feedback from all involved on the pilot’s outcome, Nico tells me) the LSO suggested to other orchestras and venues in the capital to expand the student offer, under a new joined brand, Student Pulse.
“KODIME was appointed to create a new version of the app on iPhone, Android and the mobile web to enable multiple orchestras to list and manage their events,” explained Nico. “And to provide a central support service to both the participating orchestras, venues and the ultimate customers – the students buying tickets – We have launched the new program and app in September, and so far it is working well.
“More than 50 student events have been listed to date by the nine participating organisations, and more than 1,000 students are already registered in the program, buying tickets for events and venues from the Barbican via Southbank Centre to Cadogan Hall.”
Does the LSO Pulse app and mobile site do the job it’s supposed to? Looks like it, with the next concert already sold out as far as student tickets are concerned. Admittedly, there is a smaller contingent of tickets available for this one at St. Luke’s but still good to see it working without any hard pushing at all.
That next event will also be the premiere of the complete paperless ticketing process, and we’ll update with results here post the concert.
Last night was the second of the student events promoted in the LSO Pulse app. The web application which processes the scanned tickets had been tweaked a little to make for a better user experience. The screen flicker which had been present on scan for the first event is gone.
There was also a clear improvement in how comfortable the scanner operators were in using the system. The process was more efficient than it was last time and there were no issues for any of the students.
Our next event is at a different location, LSO St Luke’s, where the set up is quite different, with new challenges and limitations, so we are spending some time on delivering in that scenario.
As part of the LSO Pulse app project, we had our first evening of mobile ticketing with our target audience of students.
Having developed and built the mobile app and mobile site to facilitate the tickets and benefits of the Pulse program, this event was selected to pilot the complete circle of ticket purchase through to ticket redemption.
As a headline number, 100% of the tickets sold to students for this event were correctly identified, claimed and handed out on the night, with the details broken down below.
The overall process went very well, with only minor glitches and queries that would be expected at the introduction of any such complex technology into the ticketing process.
A maximum of 100 tickets were allocated at student discount prices for this first event. It was decided by the team to only allow mobile app or mobile site ordering for this event, to test the validity of the proposition.
Tickets sold were 64, bought by 26 individuals for themselves and their friends (part of the Pulse program is to encourage group purchase), meaning an average number of tickets pp. of 2.4.
The largest order was made on the Mobile Site for 8 tickets in 1 transaction (maximum allowed is 9).
Here the distribution of Mobile Channels used to buy the tickets:
The Mobile Site caters for Blackberry and similar smartphones where no dedicated app exists. From KODIME‘s experience, this distribution is logical, iPhone users are the biggest group of active smartphone owners, and also like to download and use apps more than any other mobile platform.
Conversion App Download to Purchase
Of around 90 downloads of the app in the two weeks after release up to March 14th, we generated 18 transactions, which is a high conversion rate of 20%. We would expect to see no more than 2% based on the experience other mobile commerce projects.
On the Night
We set up at the venue at 5.30, and trained the LSO student coordinators Tomoyo and Callum over half an hour on how to use the scanner and web app (see below).
Tickets were scanned and redeemed between 6.00pm-7.30pm, with the last handed out at 7.35pm – after the concert had begun!
QR Code Scanning
The QR Code scanning with the manually operated barcode scanner worked flawlessly. There was the occasional issue of needing to focus the scanner in the right distance to the QR Code, but otherwise the decoding worked with all screens of different sizes as well as the paper printouts presented (see below).
In order to read and process the tickets, checking for validity and seat information via the QR Code, we had built a LSO Pulse “web app”, a website with interactive features. This worked well on the night, however we noted some user interface issues (web browser related) which we plan to improve for the next event.
We do not have tracking of all the social share options (email excluded), but 3 shares of “I have bought my ticket via the LSO Pulse app” were made to facebook and Twitter. This is out of the 18 app users, so not bad. Again need more data/events here to evaluate.
After the Event
The App provides for automated Push Notification to ticket buyers to complete a Survey the day after the Event. Our test handsets successfully received this notification and records show it went out to all applicable users. We do not have control over their settings; iPhone users increasingly disable these alerts. Of the 26 handsets pushed, only 1 started and completed the survey so far. Surveys generate additional reward points for users, and we plan to use a text message to re-prompt the users to complete their survey. Will need to monitor this over the next few events. One other reality is that users are generally reluctant to complete multi-screen data entry on the small screen, unless there is compelling reason (such as having to provide address or credit card data for an order).
We are very pleased with the results so far – we only released the app two weeks before the event, and outside of a few queries had no issues with the reasonably complex chain of mobile marketing, transaction, ticket delivery and redemption on the site.
The next events (starting from April 12th onwards) will be used to
– optimise existing process and systems based on outcome from first event
– test additional layers, example ticket PRINTING and entry management
– gain more data from users for deeper analysis
Watch this space!
We’ve been a bit quiet this year so far, but fear not – it’s all been for a good reason, namely to get our app finalised and released! It’s been an intense, but throughout positive journey, with some hard pushing especially during the last few weeks to make our tight deadlines.
So the first part of what we set out to do is delivered, and live in iTunes and Android Market, as well as on the Mobile Web. The LSO team will be properly launching the new app and offer with a campaign to its student audience over the next few weeks, and we have the first live event featuring mobile tickets on March 15th. Still figuring out the ticket scanning software, but we’ll get there I hope!
Have a look at the summary presentation, and of course download and check out the app from iTunes and Marketplace, search ‘LSO Pulse’. Any feedback, ideas, suggestions etc welcome, please email us on email@example.com
Bit more news from us in the pre-Christmas rush.
Last 2 weeks have seen further work under the hood, meaning backend platform changes. In order to drive the app content and user profiles, we need a set of API calls (such as “Get Ticket info #23ac for user ID #6567, in simple terms) and this function list is now finalised and being coded.
The app user interface has moved to design stage, and early January we’ll post some screens here.
When we have a minute here at KODIME, we like to play with new tech (sad isn’t it). And with this NESTA project, there is some cool stuff happening such as NFC which is “near field communication”. If you’ve used a contactless credit card or Oystercard, you’ve experienced NFC. It allows a device to “ping” its identity to another device “over the air”, and the actual NFC chip can be very tiny and almost flat – hence the use in credit cards and of course mobiles.
Google think this will be massive, especially for mobile payment, so it’s certainly worthwhile exploring for the rest of us. To create NFC applications, you need sample cards, software, mobiles, all available as part of a development kit, see photo. YES it involves hardware, which gets us software guys reasonably excited. NO we DON’T suggest you give one of these to someone for Christmas!
Have a peaceful festive season and a fantastic 2012!
We are now working off agreed wireframes and user flows. The LSO team has provided quality feedback at all stages, which really helps.
This week has been focused on code details, how to make the app work with the realities of the ticketing process. A good example here is the use of local “caching” inside the iOS or Android device, meaning saving content locally.
With mobile devices being in and out of networks all the time, relying on a great 3G connection when a user is trying to view or show his/her ticket details at an event is not an option. We need to save down the event details and related fields as well as the mobile barcode that is the actual “ticket” locally to enable ticket redemption even where there is no mobile reception. As the creation of each ticket is happening server-side (backend), and can involve one user for one event ordering multiple tickets (for friends), with each one having to be generated and sent back and saved reliably on the app for future use – seamlessly and hidden from the user – not a trivial coding task.
PS: In this context I was amused to read so much this week about the “superfast 4G” trials by mobile operators in London, such as O2 – are these the same network operators that still can’t ensure a basic consistent 3G coverage in such remote locations as Wimbledon or Ealing?
Below a further screenshot from our project, this is from Survey Module and “work in progress”.