THE'' PREMIUM'' STORY
It started as an idea in a workshop held at NAIR,Vadodara. The then DG posed a query: "How serious are you in making passenger segment profitable?" He knew the obvious answer! What followed was two gruelling days of bouncing ideas in all fields of passenger marketing, including innovative systems of increasing earnings. Some of them sounded absurd, some hilarious, some thought-provoking, and some depressing. For me, it was a challenge.
Returning to the mundane office routine, a series of meetings with key 'doers' began to give shape to the idea propounded within the pristine surroundings of an academic institution. The general consensus was: "it is doable, though not easy." The second was the danger of tampering with the logic of a successfully operating PRS system. Thirdly, was it acceptable to the customers. Detailed deliberations led to a synthesis of views. We decided to take the plunge.
The work progressed on two fronts. In the office, where a broad framework of instructions was written and circulated; in the CRIS centre, where the software application was studied and a programming team was created. The target was to make it happen and the difficult part was to achieve the same within a short time frame to reap the benefits during the ensuing 'busy' season. We were now fighting 'Time' rather than the 'Concept.' Heated discussions told us that, although possible, it was not going to be easy. The concept, however, was still too nebulous.
The first 'cut' was made by the CRIS's (CRIS-is?) Management Team when they made a presentation regarding the direction to be taken and the logic to be followed for writing the software. A Proof- of -concept type of thing. It would be based on the principle of ''deviation count'' and increasing fare depending upon the period of Advanced Reservation Period [ARP]. Another series of meetings followed. Approvals were given for the direction to be followed. However, we were running against the clock and running out of time.
Some key decisions taken were: would this be for only confirmed reservation or even waitlisted/RAC passengers?; would the tickets be sold only for end-to -end passengers or even en route passengers?; will there be refunds allowed or not?; in case all the tickets are not sold out, will there be last minute booking from 'current' counters at the station?; what would be the rate of increase of fare?; etc. The questions were endless - time was not. The philosophy of 'Airline-type' booking methodology was being laid out. It still needed to be tested in the "lab"/computer system in CRIS.
Some key decisions taken, the first 'formal' presentation came a few days later. The software was in place. A trial was made of a fully AC type Rajdhani train between Mumbai and New Delhi, i.e. 1st/2nd/3rd AC coaches only. This was arrived at, in the office, by a detailed analysis of all O-D flows from the PRS database including wait-listed passengers. A set of 17 such pairs were noted which had a substantial wait-list round the year.[Incidentally we were running 17 special trains on an average daily, not necessarily between the same OD points].That is how we chose the route of the first train. The first decision had been taken.
The second was about refund and last minute ticket sale through booking windows, called current booking counters. Data, however, showed that the existing train services were already overbooked. Hence, the fear of vacant berths appeared unfounded. Yet price remained an issue, meaning, would the train be fully patronized even when fares keep rising or some berths will remain vacant. We decided to test our database once again keeping in mind the paying capacity of the travelers from that area. Decision was taken that the tickets would only be sold through the internet-based ticketing system with no refund permitted, unless the train was cancelled. No ticket was to be sold from any booking counter. RAC was permitted based on experience. Effectively two decisions were taken: the train will have no refund mechanism; the train will run only if the ticket sale would justify-not as a regular service, even though time-tabled. It was to be a purely financial decision. The corollary, therefore, was that the train was to have no concession passengers - not even pass-holders.
A philosophy for the type of train was beginning to unfold. It was to be a fully reserved train where the customer was willing to pay a premium for better service including a confirmed reservation. Hence, the speed of train was crucial. There was to be no booking from the counter and only through the internet-based ticketing system along with no refund. This would ensure genuine passengers who would not go through a middlemen/ agent/ tout. To avoid being categorized as 'elitist', the train would be an additional service on a route where an existing service was available; in effect giving a customer a choice. It would add not subtract. It would also not be a 'regular' service but driven only by demand making it a financially viable proposition for Railways and useful for the customer. The philosophy started to go beyond this as we struggled to find the right fit. Time was, however, of the essence since that was the basic philosophy. We were now struggling, arguing and yet deciding.
The difficult part came with the way the ''dynamic'' pricing was to take place. Beginning with the base fare which was decided as Tatkal fare since the confirmed reservation concept was envisaged. The fare was to be progressively increased with each ticket sale triggering a deviation count. This brought us to the problem of different pricing for each member of a family within the same ticket. This appeared ridiculous at the outset. Hence it was decided to allow the price to hold for each ticket/group. This introduced a concept of 'bucket' in the deviation count. Now the deviation would be read by the computer, bucket by bucket and fare revision would be calculated accordingly. The next issue requiring decision was 'what-if' the sale of tickets tapered or the capacity would remain unutilized. In effect, would the reverse pricing be also dynamic, like the Airline system. Theoretically it was possible. The decision taken was a "no." In the current rail sector demand, such an eventuality was theoretical. That is the reason we decided to call it ''premium'' pricing and not ''dynamic''. Next, came the most difficult part. A presentation showed that the price of AC sleeper fare between the two defined points, Mumbai and Delhi, could be as high as Rs.37000-more than even airfare. This was just not acceptable, it would make the scheme a non-starter. So a concept of ''cap'' on fares was decided for each class of travel. A sleeper fare would only increase to one and a half times its base fare and then remain constant. So also for other classes, a peak was identified. Now pricing was to be linked to rate of sale of tickets, read in buckets, and capped to a maximum for each class of travel. This was the "premium" pricing so envisaged and finalized. It now had to be tested for all scenarios and implemented in the field. The 'core' group got into the act and finalized it within hours of the deadline. We had fought against Time and won. It was no mean achievement.
Now came the most difficult part- implementing it in the field. The first 'premium' train was announced and booking opened. We were monitoring hourly sale and the deviation. We were also monitoring low cost airline fares. The system did have a few glitches but it held and worked. The train was fully booked [as assumed] and the premium price was achieved to the 'cap' level. Against anormal Rajdhani's earning potential of Rs. 19 lakhs this train earned Rs. 30 lakhs. The public response was overwhelming. The press went gaga over this concept, the passengers were highly satisfied, and the demand was to extend it to other routes as well. We had established our bona fide. The philosophy had prevailed.
Now that proof of concept[POC] was established, the philosophy on which we started was still wrangling my mind. Why can't this concept be extended to intermediate stations also. What would be the methodology to ensure we had more long distance passengers than short distance ones-after all, the longer the distance, the higher the earning. Could the present application architecture permit this. Other questions also followed: the need and type of catering; the speed of travel, hence number of stoppages enroute; ticket to be sold only from intermediate station to intermediate station or any combination; could a train be 'premium' from one direction and a normal service on the return. The possibilities were becoming bigger and all because of the basic underlying philosophy of an additional service providing confirmed reservation and allied premium service. The CRIS website was now indicating a premium train for desirous passengers.
So having established this philosophy, what next. Another idea which is developing is implementing the concept of a 'clone' train. This would mean a premium train would automatically get announced on the net/ on the system whenever waitlisted passengers went up beyond a point- one way or both ways. The only difference would be that passengers would have to pay a 'premium' if they wanted to avail of it. We are now at that stage- and I think in the right direction. Let's see how fast we can implement it. Wish us luck!