Group Design Project – B202

Product feasibility study

Introduction

Our service acts as a middleman between a venue selling tickets for an event (gig, show, exhibition etc.) and the customer. The customer only has to send a text to us (in a specific format) and they will receive, very quickly (within 5 minutes) a text back. This text has a unique code contained within it which acts as a 'virtual ticket' for that event. The text is simply shown on the door, like a paper ticket and entry to the event is gained.

In order that the code cannot be randomly made up by an unscrupulous customer and shown to try and gain entry, safeguards will be put in place. Firstly the code sent to the customer will be a hash code generated from a unique venue and event ID (chosen by the venue selling the tickets for the event) and a pseudorandom code.

In order to check this code and make sure a code is not used more than once (such as shared between a group of friends) the code will be checked on the door to the venue. The venue will check the code against a database of valid codes issued for that event to make sure it is valid and has not been used before. If these checks fail, the customer can be denied entry to the event.

The check against the database will be carried out through a web interface to our central server, maintained by us. This web interface must have the ability to be used universally by devices, so the venue can choose to use a computer, a PDA, a smart phone etc. (basically any device capable of browsing the web) to check the ticket's validity. This check will be carried out instantly.

This web interface will also be used by the venues to upload the details of events for which they want us to make tickets available. We only act as a middleman to facilitate the selling of the 'virtual tickets'.

The cost to use this service will be free to the venue (in order to get them 'on side' and get venues to join our scheme) but will cost the customer approximately 50 pence (plus the cost of a standard text) to send us the initial text requesting a ticket. This will be taken directly from the customer’s phone credit.
The cost of the ticket will be the same as if they bought it through other means (such as direct from the venue). This should encourage customers to use our service as they are not paying more for the ticket than they would normally and are getting a much higher level of convenience (what could be easier than sending a text?). The 50 pence is a small charge and is transparent to the user, which will cover our running costs and make us our profit.

If the system is successful and venues like our system and would be willing to pay for it, in the future we could start charging the venues a small fee for tickets sold through our service.

The customer will be charged directly to their credit/debit card upon purchasing the ticket. This means they will have to register with us initially to use the service, so that their card details are available to us. Their phone number will be used as a unique identifier which will be tied into their account details.

The other option we had of charging the customer was taking the money directly from their phone credit. However, charging to card alleviates the problem of a customer wishing to buy an expensive ticket for which they do not have enough credit.

Design Requirements

Service Performance Requirements:

There are several requirements that the service must meet in terms of performance and these requirements will directly influence both the hardware and software used for providing the service. The software will have to be able to cope with the service performance requirements set out below, and the hardware must be capable of dealing with the demands placed upon it by the software.

• The system must be able to hold a minimum of 10,000 events for each day without crashing or slowing down. This requirement is important for the expansion of the system in the long term, so any database software used must be able to cope with these demands.
• The time to respond with a ‘virtual ticket’ to an initial text requesting a ticket should be less than five minutes. This means that the ticket should be delivered to the customer’s phone within this time. All database querying, credit card transactions and sending out of the ticket by our system should be done in this time in order for the ticket to reach the customer within five minutes. To meet this requirement, we need to use a service offered by the mobile telephone operators that give our messages priority in times of high load upon the mobile telephone network.
• All of the tickets (100%) that we send out must be guaranteed to be delivered to the customer’s phone, as it is a product that they have paid for. In order to do this, we need to look into solutions provided by the mobile telephone operators that offer guaranteed delivery of the text message. Messages cannot be dropped in times of high network load or when the customer’s phone is switched off or has no signal, so the message must be stored for retransmission later.
• The system must be able to process a minimum of 1000 requests per minute. This is to ensure that the response time stays within the 5 minute bracket even when the system is under a high amount of load.

Service Functionality Requirements:

There is also functionality that our service must have. These requirements are not numerically quantifiable like the service performance requirements; rather they are requirements that must be met. Without these being met the service would only have partial functionality or not work as described.

• Venues must be able to add events to the system in order that our service can make tickets to these events available to the customer. The venue must be able to add details on the events, such as ticket price, date, venue and location (town/city) onto the database stored on our system.
• Venues must be able to remove or edit events that they have previously added onto the system, if the event has been cancelled or details such as date and ticket price have changed.
• Security measures must be taken to ensure that tickets can only be used once, to eliminate fraudulent use of our service. An example would be a group of people all trying to use the same ticket. Venues must be able to mark a ticket as used on our system to avoid this situation.
• Venues must be able to check the authenticity of a ticket presented to them by a customer. In order to do this they must be able to verify the ticket against our system.
• The service must be able to be used by all mobile phones that support sending and receiving SMS messages. Therefore the service must fully comply with the SMS protocol. This means it should be able to receive, and more importantly send, texts that comply with this protocol. This puts certain restraints upon our service. For example, all ‘virtual tickets’ (text messages) sent by us must be less that 160 characters in length and 140 bytes in size.

Use Case Scenario

A good example situation which highlights the value of this service is someone who needs a last minute ticket in a hurry – perhaps they want to attend an event later on in the day but have not got a ticket for the event yet.
In this case the customer will either try to get a ticket in time through normal booking services or have to queue on the door. The customer may also be tempted to try and buy a ticket from a ticket tout. This is risky for the customer, as tickets from unreliable, unofficial sources may be counterfeit.
In order to avoid these problems, the customer can quickly and easily use our SMS booking service. This way of booking a ticket is much more convenient and secure than the aforementioned methods and is ideal for a busy customer who has other pressures on their time.
Another problem our service addresses is that of the customer forgetting their ticket, in the case of a traditional paper ticket. As most people carry their mobile phones on their person at all times, they will always have the ticket on them.

Product Comparison

There are many SMS based services which are similar in function to our service. We have analysed these services and compared them to our own. We have looked at the negative points of other services so that can avoid these problems and improve upon them in our service.

We have also looked at the positive aspects of these services for ideas that we can implement into our own service.
The services we have looked at are as follows:

• Argos product reservation service
• Orange Wednesdays
• Direct.gov.uk text service
• National Express ticket booking

Argos Product Reservation

Argos provides its customers with a text based product reservation system. The customer looks up the product in the Argos catalogue to get the catalogue number of the product they wish to reserve. They then text the catalogue number and store name/number (with a space in between) to a specific premium SMS number. The customer receives a reply from Argos informing them of the product’s availability, current price and gives them the option to reserve it. Once the customer replies to confirm they wish to reserve the product, the product is reserved for them and the customer can go to the store to collect it.

Positive Points:

• Argos does not charge its customers any extra cost (on top of standard text rate) to use this service.
• The reply the customer gets from Argos gives them detailed information about the product including the current cost and availability.

Negative Points:

• The service only reserves the product for the customer until next working day.
• The customer still needs to pay for the product in-store and cannot pay via the text.
• This service will only work when the customer has access to the Argos catalogue since the customer needs to send the product catalogue number and store name/number which are only listed in the catalogue or online.

Comparison to our product:

The only good thing about this service is that Argos does not charge its customers any extra money for the text. Also this product is highly dependent on the Argos catalogue, while we on the other hand do not require any sort of catalogue for our service to function.

Possible Implementations:

We could publish a monthly catalogue of events that will be available via our service over the next month. This catalogue would have details about each event. We could perhaps charge the customer a nominal fee for this catalogue or have event advertisements in the catalogue paid for by the venue and distribute this free of charge to all our customers.


Orange Wednesdays Text

The customer texts “film” to a special Orange number. Orange then sends a text back to ask for confirmation and after having received a reply back from the customer, sends them another text with a pseudorandom code. The customer then shows this second text at the participating cinema’s box office and will get two tickets at the price of one. The cost of each text the customer sends to Orange is 35 pence.

Positive Points:

• The customer gets value for the money – the cost of the texts is outweighed by the free ticket which is worth anywhere between five to ten pounds.
• The response time from orange is usually less than two minutes. The number the text is sent to is short and hence easy to remember.
• The format of the text the customer needs to remember since they only need to send the word ‘film’ in the text.

Negative Points:

• The service only works on Orange phones.
• The service is only available on one day of the week.
• You can only get one free ticket per phone.

Comparison to our Product:

This service does not expect its customers to remember a particular text format to send. This is very convenient from the customer’s perspective. This service is only available to Orange customers. Our service is available to customers of all networks.

Possible Implementations:

We could try and make our text format more user-friendly. A good idea could be to allow the user to assign names to tickets they buy frequently. To order the ticket repeatedly, they would just need text us the name they previously assigned to that specific ticket.


Direct.gov.uk Text Service

Direct.gov.uk is an official government owned website that is produced for the general public to provide information about public services. Some of the services it includes are health care (Local GP) and motoring (MOT and travel) and much more. The government has also extended this service to mobile phones which is called ‘Directgov on your mobile’. To use this service the customer has to have an internet enabled mobile phone then the customer can text MOBILE to a premium number and this will give them a link to the website. The customer can text key words like ‘JOBS’ and ‘TRAVEL’ to the number and they will receive a text back with a link to the information that they want.

Positive points:

• The customer can receive a large selection of information.
• The text message is only charged at standard rate, there is no extra charge for the text message.
• The system is user friendly because the customer can text memorable short words and numbers.

Negative points:

• The customer would need an internet enabled phone to make use of this service.
• If the customer’s mobile phone is internet enabled anyway, this makes the text service slightly redundant as you could always use the website’s search function instead.

Comparison to our product:

The customer will not need an internet enabled mobile phone to use our service but they do need to in order to use Directgov’s services.

Possible implementations:

We could have a website holding a wide range of information on upcoming events.


National Express ticket service

This service allows the customer to book coach tickets online and have them delivered to their mobile phone using SMS. They can also check for travel updates and delays concerning their journey directly to their mobile phone, also using SMS. The ticket, called the ‘M-Ticket’ costs 50 pence to be sent to their mobile phone. There is usually a delay of between three to five minutes before the text is received. The text contains a unique mix of letters and numbers which then has to be verified by the driver when used.

Positive points:

• It is convenient to the customer to receive their ticket and travel updates directly to their mobile phone.
• It is secure because of the random code on the ticket that must be verified by the driver.

Negative points:

• The customer has to book the ticket online and not using SMS.
• There is a 50 pence charge to use the service.

Comparison to our product:

The booking of the ticket is done online and not via SMS, whereas our service allows the user to book the ticket using SMS. This means they do not have to have access to a computer every time they need to book a ticket. This makes our service much more convenient. Our service charges the same price of 50 pence like National Express and uses a unique code for the tickets like this service.

Possible implementations:

We could give the customer the option to buy their tickets online on our website, and have them sent to their phone. For this a small convenience fee will be charged. Also on the website, we could let them choose to receive information on upcoming events that they are interested in.

Concept Diagram

Key Cost Drivers

The following cost drivers are those which we believe will have the most affect on the cost of providing the service. They are listed in the order from most significant to least significant.

• Transmission Costs:

  Our main running cost will be the transmission costs of sending out the tickets to our customers. To do this we will need to use a premium SMS service which will guarantee timely delivery of our texts. We will need to pay our network provider a fee for this service, but we can negotiate this cost with our network provider at commercial rates. Due to the large number of texts we will be sending out, this will amount to the largest running cost.
  

• Cost of software development:

  We will need to get software developed that will automatically accept customer’s requests and send out the tickets. The software will also need to handle any errors that may occur in a graceful manner. This software will need to conform to the requirements set out earlier in this document regarding speed and processing capability. The development of the software will be a one-time initial cost, but will need routine maintenance, patching and updates, for which a software developer will be required.
  

• Data Centre/Server running costs:

  At this stage we have two options available to us. We can either have our own dedicated data centre run and maintained by us directly or we can hire rack-space for our hardware in an external data centre. This data centre will be run and maintained by a third-party company for a monthly or annual fee.
  If we choose the latter option, then all staffing and maintenance costs will be included in the data centre’s fee. If we run our own data centre, we would then need to hire staff to maintain our servers and other related networking equipment. This could be more costly, but also more secure.
  If we do decide to run our own dedicated data centre, very few staff will be required as most of the processing will be carried out by the automated software. However, staff should be available to fix any errors should they occur and monitor the service for problems.
  

• Cost of hardware:

  The cost of the server and networking hardware will be a one time initial investment. We will need to choose hardware which is capable of running the software at an acceptable rate in performance. In is not anticipated that the cost of hardware will be more than the software development costs, and so is the lesser of the two initial costs. However, extending the service later on because of an increase in demand or a need to increase capacity will also be a substantial cost.