Kaizen

Following from my last blog, once the decision was made to remove the need for business premises, I wanted to make sure the process we used to receive bookings was efficient. The process used in 2005 was different to what we use today – mostly because of the volume of work we now manage. The technology we employ was a little different back then too.

Over time, our process has changed, improved and evolved in to the efficient system we have today. The Japanese have a word for this process of constant gradual improvement and it is known as Kaizen. Initially, there were benefits to using online booking forms but I didn’t really think about how the information we received would be used to communicate and what the full process flow of that information would be. For example, I didn’t really think about invoices in too much detail. I never thought about tracking customer trends, or Key Performance Indicators.

Going back to day one, we had an online booking form that would send a formatted email with a customers journey details. This would include the date, pick-up times, number of passengers etc. The information from that email was then copied manually in to a spreadsheet and while there was only myself as the driver, this worked fine. Things began to change though as the volume of bookings increased and the number of invoiced accounts improved. Imagine how long it would take at the end of each month to sort out all the bookings for one single client and then put them on an invoice. From here, there were a number of steps I went through to build a system that could manage the administrative side of the business – in a later blog I plan to talk about vehicles, drivers, chauffeur etiquette and all sorts of things about being out on the road but first, it is essential to get the foundation in place.

A business cannot operate efficiently unless it is managed appropriately. The first step in the chain was to move all bookings from a spreadsheet and in to a database so filters could separate information and group specific details together for invoicing – journeys for customer A, B or C between dates X and Y. Next, the reporting function of the database was used to construct a formatted invoice that could be exported to a recognised file format and emailed to a client as an attachment (printing everything out became a nightmare as our volumes increased, there was paper everywhere).

I realised a filter could be used to produce a list of future journeys that a driver had planned. These journeys could be listed in a report, then exported as a web page and uploaded to a secure area of our web site. Now a driver only had to check on their own web page to see which jobs they had coming up. This was great if we were all working different shifts and asleep at different times. I also realised that if a drivers journeys could be filtered, exported and uploaded so too could a customers journeys.

At this point, things really started to become much more technically involved and we approached our first software developer. He linked the email through some clever programming and it put the booking from the web page straight in to our database system thus automating the bookings and reduced the need for manual copying (which incidentally removed the opportunity for errors to occur).

The database system we now had made our entire operation much easier to handle. If we had an enquiry from a customer who travelled two years earlier, we could retrieve all the details within seconds. However, there was still one major problem and that was that we could not alter a journey unless we were sitting in front of the computer. The next improvement introduced “remote desktop”. Eventually we felt we developed our system as far as it would go and the next stage was to hand it over to a professional software company.

They could make it a web based booking system – basically a database that runs on a web server that drivers and customer can access 24 hours a day. The added bonus with this is that our manager’s had a new interface which meant they now manage bookings directly from their mobile phone (in real time).

Lean

In my last blog, I wrote about Toyota and how their principles focus on eliminating waste or “Muda”. When I first set up DrivenByQ, I wanted it to be lean – for there to be no waste. In order to do this it was important to understand how a conventional company operated and to analyse its procedures. For example a conventional private hire company has a phone line and a member of staff to answer it.

A member of staff is typically operating a radio 'base' station or data system. That system needs an aerial to communicate with the vehicles. The radio system needs tall premises to mount a large aerial on top. The building needs electricity and it incurs other costs like rent, rates, insurance, furniture, stationery and even things like fire extinguishers. There is also a cost for cover during staff holidays or sickness.

Most offices these days have computerised despatch so there are IT costs to add and hardware eventually needs replacing too. The data heads, or radio equipment in the cars are costs which must also be included too! The office has only one way of recovering the costs in relation to fare paying passengers and that is by charging their drivers a rental fee for a radio (known in the industry as settle - typically between £100 and £120 per week). The driver then works a number of shifts and what they earn in fares is what they keep (minus their fuel, insurance, servicing costs, etc).

An office typically needs 17 cars just to break even each week. With all these factors in mind, I set about analysing the work flow related to receiving a booking - right the way through to despatching a car. I questioned each stage of the process and asked if it could be reduced? I also asked if there was a newer technology that could assist in the process. It took no time at all to realise that using an online booking system would instantly negate the need for a member of staff as the customer could input their details directly in to a web page.

Without a member of staff, there was no need for a fixed phone line or the associated costs. A booking page enhanced the quality of information received too as web forms would not submit until all the key information was acquired. The submitted booking from our web site sent an email notification directly to my smart phone - eliminating the need for radio equipment. Without the need for a member of staff, a phone line or radio, the premises themselves become obsolete and so did all the associated costs. This was just the start of process improvement and elimination of Muda in our organisation and the beginning of lean.