Software Redesign: IRCTC Website – How to Speed Up Tatkal Ticket Booking

Software Redesign: IRCTC Website – How to Speed Up Tatkal Ticket Booking

 By Venkateswar Jayanthy

Booking train tickets for travel Indian Railways through IRCTC’s Tatkal (Immediate) system has been a nightmare for many users in India. Even after the recent system upgrade, the improvement is not so great. I think unless the whole system is redesigned and revamped, the user experience on system will remain nightmarish.

I have thought of a new approach to the booking of tickets, particularly for Tatkal, as the system opens for online booking only one day in advance at 10am and typically all tickets get sold by 10:30am. A zillion users try to log in to the system to purchase tickets, but only a handful of them would be lucky because of the short window.

Skewness in the existing system:

The existing system is skewed towards users who have high monetary capacity and who have the ability to speedily enter the data. Consider this:

If you are buying tickets for your family of 4 or 5, a failed transaction might end you up with a debit to your bank account or a credit card account. If you want to buy again, you will have to shell down additional money, though the money paid for earlier transaction would be returned to the user in 4-5 working days, sometimes even earlier, but never immediately. There is no Tatkal here! If there are two consecutive failed transactions, the user will have a double debit, but no ticket!

Further, because of the short window for booking Tatkal tickets – only one day before the date of journey (and only for half-an-hour), the ability to speedily enter the data gains paramount importance.

Imagine the plight of older people, or people with difficulty in using computers trying to buy Tatkal tickets online. 

• The other option for them is to stand in the queue at the railway reservation counter and wait for their turn to buy the ticket.
• There again, the touts rule the roost, as was experienced by me in Begumpet station in Hyderabad some months back.

After a tough experience in booking a Tatkal ticket for my daughter, I was pushed to think about how to redesign the ticketing system and make it more user-friendly and friendly even to computer-non-savvy people, who have difficulty in entering data fast. Besides, my aim is to reduce the transaction failures, which typically happen at the payment authorisation level.

My ideas on redesigning the system are given below. All ideas, counter-ideas, comments and suggestions are welcome.

Please note that I am not a software programmer/ engineer or a hardware guy. I am a finance professional with significant interest in computers, system design. I have some interest in system design as it is in my nature to maintain some orderliness in whatever I do!

1. Existing System:

In the present system, the user first selects the stations, date of journey, train, class, and then enter passenger details and later the payment details in that order. This method I feel slows down the process of booking transaction.

Further, if a transaction fails, the user has to re-start (maybe after logging in again) by entering all the above details, which is time consuming.

Besides, the existing system favours only the persons who are ‘keyboard-savvy’ who can type or key-in the information fast. Others are bound to lose the chance to buy the ticket, particularly in Tatkal.

With many Captcha at various points of the transaction, the process is further decelerated.

2. For improving the speed of booking, I suggest the following method:

The entry of information (data entry) and actual booking should be segregated.

The information we enter can be divided into Fixed Information (F-Info) and Variable Information (V-Info).

     A. Entering Your Information / Data Entry:

F-Info: Of the information we enter for booking a ticket online, the following items of information are required. They however are normally pre-decided for a particular journey and hence can be treated as F‑Info for a booking transaction:

1. Names of ‘From’ and ‘To’ Stations
2. Name(s) of Passenger(s), age(s), food preference(s), ID card type & No., berth preference(s)
3. Payment option
4. Payment Details (e.g., if the payment option is credit card, its No., name on the card, expiry date, CVV no. etc.)

The train name, Class of travel and date of journey may be V-Info, but could also be considered as F-Info in the case of some users, and hence could be made part of F-Info as optional items.

Under the proposed method of booking, to speed up the process, the user will first enter all the details F-Info (including the Optional items if that is the user’s choice) upfront.

This F-Info is stored temporarily on IRCTC’s system with a specific file name given to the user.

The important thing is to do this activity of Data Entry before the time for Tatkal starts. Only then the user gets the benefit.

     B. Actual Booking of Ticket – Proposed Method:

When Tatkal time starts, the user logs into the system, selects the F‑Info file stored earlier. This will open an appropriate screen. On this screen, he chooses the train, date and/or class (if they are not already a part of the F-Info) and clicks on ‘make payment’ and the system uses the stored information to complete the transaction till the last leg of payment process, i.e., entering the OTP or IPIN etc.

For a more efficient system, IRCTC may enter into an arrangement with the providers of payment gateways whereby the user is accorded a pre-approval when the credentials including OTP or IPIN are entered upfront.

However, the user’s account will be debited only when the user clicks the ‘make payment’ button.

This will detach the process of going to the gateway provider’s website for authorisation of payment and coming back to IRCTC’s website after successful payment. This process is akin to hotels abroad swiping your card at the time of checking in but not debiting your account. The amount will be debited at the time of checking out. If you settle the bill with traveller’s cheques or cash at the time of check out, the amount blocked on your credit card will be released.

This makes the process of booking very fast and more tickets can be booked in the system within a given time.

Once the ticket is booked successfully, the F-Info file will be automatically deleted with a display of confirmation of the same on the screen as well as an email to the user.

     C. Failed Transactions and Life of F-Info File

If the user chooses not to book the ticket or when a transaction failed, he would get the following options:

1. The First Option from the system is to delete the F-Info that is temporarily stored in the system and then log out.
2. Second Option to choose to retain the F-Info on the system till the end of the day and then log out. The system will store the details only for that day and will automatically delete the file after 23:59hrs. The user can subsequently log in before the deadline and book a ticket using the same details.
3. Third Option to choose to retain the F-Info on the system till the end of the week and then log out. The system will store the details only till 23:59hrs on the ensuing Saturday (or Sunday as IRCTC might like to program it) and the details will be deleted after the deadline, automatically.

In all cases, the system will send an email to user after the file is deleted.

The above process I am sure is better than storing credit card numbers etc. Further, with the pre-approval process suggested above, IRCTC will probably have less number of refunds to make for there would be fewer failed transactions, which normally occur more at payment authorisation level.

The existing system is akin to buying tickets at the counter wherein the user starts filling up his form on reaching the window while keeping everyone behind him waiting for his transaction to be over. The system suggested above removes this anomaly.

IRCTC may also think of adopting the system as above for actual users and the existing system for the agents. Besides, it can impose a cap on number of tickets booked per user ID, IP address and credit card or debit card numbers and a combination of these three.