beelocal

beelocal (Trading as High Street United) launched in Autumn 2009 in the south lakes region of Cumbria offering a local produce delivery service. In Spring 2008, e-volve were contracted by a new start up company called High Street United to develop the various systems required to fulfil their new business model.

The basic concept of High Street United is to support local producers and provide a means for them to reach a larger sales population. Over recent years, the growth of the major supermarkets has been exponential, and unfortunately, this has resulted in local high streets becoming less used and producers being price-pinched.

Thus, when attending a summer BBQ where the host was apologising for the inferior quality of the meat, one of the founders of HSU thought ‘Wouldn’t it be great if we could have some local, high quality meat delivered from one of the local butchers?’. Apparently, the host of the BBQ had been unable to get to their local butcher, and had therefore picked up some raw meats from a local supermarket.

A new company (HSU) was quickly formed, and a business plan was put together. However, it was soon clear that to make a valid offering for the customer, many complex systems were going to be required, and it was at this point that e-volve were contacted.

At the same time, HSU started contacting local suppliers (South Lakes region) to gain their support and commitment, and started specifying the requirements of the entire system.

Project #1: beelocal.co.uk

First and foremost, HSU required a web application that customers could easily navigate and purchase goods from various suppliers. e-volve immediately started by designing flow process wire frames and designing logos which would be required for stationary.

It was expected that the greatest proportion of website users would be professionals/semi-professionals or put simply, people who didn’t have time to get round all their local suppliers. However, the management at HSU wanted the website to appeal to a broader cross-section than that, and hence the design and flow had to be kept simple and easy to use.

Various designs were provided to HSU until the current design was eventually settled on.

Regions

Early in the project, it was decided that fulfilment of the service would be regional. We at e-volve argued that it would be best to build the system(s) based on a regional format – we stated that the work involved in regionalising the system would be much less at the start, than splitting up an already complicated system at a later date. The management at HSU agreed with this.

All of the suppliers, customers and warehouses are therefore directly linked to the relevant region (South Lakes, Kendal to be precise).

Regionalising the system meant that a series of postcodes need adding to the system. When a customer enters their address(es), the postcode gets checked, and the system determines whether or not we can deliver to the customer. If we cannot deliver, a collection only option is always available.

Hubs and Collection Points

Since each region could be large in area, multiple collection points were enabled on the system, each of which is fulfilled from one central hub. Again, this was future-proofing the system.

A collection point is essentially a location where a customer could go to, to pick up their shopping. The shopping would be delivered to the particular collection point on the day requested by the customer.

As well as being a collection point, a hub is a warehouse from which the HSU management work, and from which all collections/deliveries are routed. (See Project #4 for more information)

Deliveries

An important offering of the service is for the customer to have their shopping delivered at a requested date and time slot. Hence the system had to manage these time slots, including specifying prices and managing availability, all on a regional/hub basis. It was due to these problems that the system quickly became complicated. However, the management at HSU were always guided in the right direction in terms of specifying the functionality from the development team here at e-volve.

Suppliers and Products

New suppliers were initially added to the system by the staff at HSU. This was due to the need to set up the system with correct and thorough information. New suppliers can register their interest at any time, and they will become responsible for the management of their own section of the website. However, for startup purposes, we wanted to ensure that the website was entirely populated.

Products are managed by the individual shop, and are displayed on the website either via their categorisation, e.g. Food > Meat > Beef > Steak, or via the particular shop that owns the product. Each product can have ethical attributes added to it in the management application, e.g. Organic or Free Range etc. This provides us with an additional level of categorisation, and has proved to be a popular aspect the website. Categorising the products in these ways has 2 advantages:

1. It allows the customer to find products that they know and trust from a particular supplier.
2. It allows the customer to find a group of similar products through a logical shopping process, from which they can compare options and pricing before making their choice.

Managing stock for all products linked to the supplier is the responsibility of the supplier. However, beelocal.co.uk itself holds a small offering of essential items that does require stock management (total in stock, margin made etc).

Shopping Cart Process

As mentioned earlier, the system had to be as simple to use as possible. This was hugely important in the shopping process. The shopping cart model is based on other cart systems that have been developed by e-volve, but with 3 major differences:

1. A customer can either have their shopping delivered OR they can collect it from a specified collection point. Should the customer wish to have their shopping delivered, the system must determine whether or not the delivery postcode is within the boundary of the delivery zone, if not, then the customer is asked to select a collection point. The system is also set up to allow multiple delivery addresses to help speed up the shopping process, and hence the postcode check must be performed at regular intervals throughout the system.
2. A customer can save their credit card details within the system. This meant that the sensitive data required encrypting/decrypting where necessary.
3. Unlike many other e-commerce applications, payment for the goods is NOT actioned at the point of sale. In this case, a customer enters their payment card details and we request an authorisation to take the funds. Should we receive a positive authorisation, we create a Deferred Payment and the order continues as normal. At the point when we fulfil the order (which may be up to 4 weeks later), we then Release the payment and take the money from the payment card.

To make the shopping process as quick and easy as possible, we encourage the customers to store their delivery/billing and payment card details on the system. Note: all systems are hosted by e-volve, and therefore Payment Card Industry (PCI) Compliance Testing is performed on the domains which we host every 3 months.

SagePay

As with most web applications developed by e-volve, SagePay VSP Direct was integrated, only this time using the DEFERRED method of payment.

Blog

To help communicate with their customers, a blog was added to the website. Through this, customers can comment on any popular topic, and the staff can promote various aspects of their business.

In addition to the blog, a Facebook account was set-up and a new page created on the website showing all of the ‘friends’ of beelocal.

Project #2: Management System

The Application Manager is essentially the ‘brains’ behind the system. Through this software, the management of HSU can monitor all aspects of their multiple systems. In short, the development of the Application Manager was one of the largest and most complicated tasks ever undertaken by e-volve.

There are many facets to the Application Manager, some of the more important aspects are detailed below:

Users

As with many systems, a hierarchy of user was required, each of which only has access to need to know data. For example, customers only have access to the front end website (www.beelocal.co.uk), drivers only have access to the warehouse system, shop keepers only have access to the shop system and administrators have access to everything.

To preserve the continuity of the data, any changes made to the system have the user and the date modified assigned to the change. This provides traceability for the management, and is particularly useful when monitoring the change in prices of products.

Regions

A region is essentially a set of postcodes. However, any particular region can be split into multiple delivery zones, so in terms of the system, the postcodes are linked to the region through a set of delivery zones.

Each region has the usual Search Engine Optimised page copy (headers, titles, paragraphs and images). In addition to this, a pair of coordinates are linked to the region for use with Google Maps.

Shops are displayed within the region by way of a manual ranking system which is edited within the Application Manager by HSU staff.

To provide the customer with more information regarding the region, separate locations are available within the system, again, these have their own SEO page data. These pages are essentially landing pages for Search Engine traffic, but help in providing confidence to the customer.

Delivery Zones

In order to manage a region effectively, the region is split into multiple delivery zones. This was done for 2 reasons:

1. It enables HSU staff to get round all of their morning collections in an efficient manner.
2. It enables the HSU staff to get round their afternoon deliveries in an efficient manner.

Each delivery zone has a name, a colour code (for crates) and can have multiple delivery slots, e.g. 12:00 – 14:00.

Delivery Slots

Each delivery zone has multiple delivery slots. A delivery slot is basically a cost for the service, and an allocated maximum availability. Managing the delivery slots allows HSU staff to fulfil orders (including delivering on time) effectively. As the business grows, more delivery vans can be added, and therefore more slots can be made available.

Warehouses

Produce from local suppliers is collected each morning and returned to the regions warehouse. Within the warehouse, the items are scanned and packed into an order specific crate. Drivers then deliver the shopping from this base. beelocal.co.uk also sells its own range of ‘essential’ items. These are generally the basic items of everyday shopping that are not sold by the suppliers registered on the system. Stock for these items are stored and shelved within the warehouse. Each product has its own warehouse reference.

Retailers

A retailer is basically an owner of a shop. The retailer is specified in this way to enable us to allow multiple shops on the system for one particular owner (again this was a future proofing measure specified at the onset of the project). Each retailer can have multiple shops, and hence staff allocated on their system.

We record various pieces of information against the retailer, namely company registration number, VAT number, bank details (for payment purposes) and primary contact details.

Retailers receive payment for the produce that they supply by means of HSU self invoicing. By this, I mean that the system generates a list each month of products sold, products supplied, products rejected and products refunded. HSU management then pay the supplier via bank transfer the amount generated. These self invoices are displayed in the shops application (Project #3).

Shops

Each shop has multiple properties. The usual page data exists, but along with that, the system forces the input of:

• Shop Type, e.g. Butcher, baker etc
• Location
• Collection Zone
• How do we display their products
• Commission Rate and Scheme
• Dymo Printer properties
• Does the shop deliver goods to us or do we need to collect
• Plus others

As well as the above, each shop has its own calendar on the system. This allows the shop owners to specify the days that they are open/closed. Doing this means that when a customer requests a delivery or collection, the system can check the shop to ensure that they are open on the day requested. If any particular shop is closed, the system notifies the customer and asks them to either change their date, or to remove the item(s) from their basket.

Products

The most fundamental object within the system is the product. With this though, comes a huge amount of required information. When developing the system, the management of HSU had to have multiple meetings with Health & Safety Officers (the system effectively sells other peoples food produce and hence falls under different packaging regulations) which resulted in many additional elements being required to specify an individual item.

For example, as well as the usual naming, pricing and categorisation of a product, we also had to request some or all of the following:

• Is the product pre-packed (if not we need to label it correctly)
• Is the product frozen (if so we need to look after it properly)
• Does the product have any ethical properties (Gluten Free or Organic for example)
• What is the unit of measurement of the item (e.g. 250g)
• How is the item sold/ (Bottles/bags/can etc)

Further to the above, should we need to create a label for the item, then additional information is mandatory depending on the items, for example, we may need to request ALL ingredients that constitute the product (the item might be a steak pie) including the percentage contained within. Also, there are many ingredients that are allergenic, and hence the label MUST display that trace items exist.

You might think that that would be enough – but no! Labels might also require use by or best before dates, or, should the item contain beef, then where was the animal reared, slaughtered and cut. Alternatively, if the product contains fish, then the label would need to show how the fish was caught, was it wild or farm reared, plus many other attributes.

Each product then needed classifying for VAT purposes, and various other attributes selecting. I am sure you can imagine; this was quite a task to monitor and force only the required information. In the end though, the management of HSU were thoroughly delighted with the system provided by e-volve.

Orders

Any successful order enters the ‘Orders To Go’ process and sits there until the date of fulfilment.

On the day of fulfilment, the warehouse drivers will collect all products from all of the different suppliers in the morning. On returning to the warehouse, the vans are unloaded and the products are scanned and then placed into the correct crate (see Project #4).

Once all orders are ready, the drivers re-load the vans with the deliveries, before setting off on the delivery route.

Logistic Process

The logistic process is a means to ensure quality control on the fulfilment of the orders. It has many steps:

1. Generate Collection Route: On the day of fulfilment, a route is generated by the system which highlights the pick-up points. This route is circular in nature and is intended to reduce the mileage that the driver must travel.
2. Products to Pick Whilst the drivers are out collecting the produce, other warehouse staff use a products to pick list to place relevant beelocal.co.uk items into the correct crates.
3. Scan into Warehouse: Items are unpacked from the van and scanned into the system. Any errors are highlighted by a ‘Needs inspection’ flag.
4. Inspection: Any orders needing inspection are dealt with and processed.
5. Payment Release: Once all orders are ready, payment is processed and funds are taken. Should there be a problem with a payment, the HSU staff contact the customer to deal with it.
6. Generate Delivery Route: A circular delivery route is generated by the system detailing where and when a delivery should be made.
7. Generate Collection List: A detailed list is generated by the system showing who will be collecting on any given fulfilment date. All collections must be signed for.
8. Release Crates: All orders that have been delivered must have their associated crates released and put back into the fulfilment process. Any orders that could not be delivered/collected will remain in their crates and the customer(s) will be contacted.

Any successful order can be refunded via the complaints procedure (what, why, how etc). The system does not cater for replacements.

Reports

Due to the strict regulations governing the labelling of products, multiple reports were created to highlight missing or inaccurate data. For example, it is much easier to display a report showing all Beef products and their required attributes. Doing this allows HSU staff a mechanism to quickly diagnose problems.

All of the usual margin, vat, sales, availability, stock level reports were also provided.

HSU Products

As mentioned earlier, HSU stock a range of essential items within their warehouse. These items require all of the usual e-commerce functionality, e.g. warehouse locations, stock levels, product batches, offer prices, stock adjustments and suppliers. Hence, in essence, e-volve had to create two distinct parts to the administration system.

Project #3: Shop Login System

Since the retailers must manage their own pages and products on the website, a new web application was developed which is essentially a subset of the Application Manager. Many of the required elements of a product are only required to be input by HSU, hence many options are omitted.

As well as the products, the shop system manages all page copy and images.

One of the most important elements of the shops system is the integration of the Dymo label software. When an order is due to be fulfilled, each shop receives a prompt requesting them to login to the system. Within the system they see a list of products that will be collected by HSU staff the following day. It is the responsibility of the shop to ensure that the items are packed and ready.

Shop users must print all relevant labels via the shop system. We developed a small Windows Service that was installed on each of the shops PC’s. When a user clicks print on the shop system, the windows service receives a prompt to print the label. Once it receives the label, it prints it via a Dymo Label Printer supplied by HSU (and procured by e-volve). (See Project #7 for more info on the Dymo software) These labels must then be placed on the relevant product.

At that point, the shop has fulfilled their obligation on the system.

Previous invoices are available to view.

Project #4: Warehouse System

The warehouse system is a relatively basic web application. It is used by warehouse staff to scan the products into the system. After an item has been scanned, the system displays a colour-coded message notifying the user of which crate the product should be placed in.

Within the warehouse, different coloured crates are assigned to different delivery zones, thus making it far easier to avoid mistakenly putting a product in the wrong crate.

As well as building the warehouse web application, e-volve also procured all hardware and software, and installed all the kit prior to the system launching. As you can tell from the photo - it was usually Andy and Dave doing the work while Matt does his usual 'taking the photo's'!!!

e-volve provide support to for all HSU systems.

Project #5: Web Services

This web application is used to expose various web references to the public. It is essentially used as a means to generate html emails.

The windows service (Project #6) and the Dymo Application (Project #7) request information from the database via these web methods.

Project #6: Windows Service

The windows service runs on e-volve’s dedicated server. This service executes blocks of code at specified times throughout the day, and generally is used to either perform administrative tasks (database or file system tidying) or it is used to send block email notifications (products returning into stock, shop has new order, customer feedback requests).

Project #7: Dymo Application

Each shop was supplied with a Dymo label printer. In some cases, different sized labels are required (depending on the product being sold), therefore single label printers or double label printers where provided where appropriate.

When a shop receives a new order, they are prompted to print the relevant labels for the products. However, the printer connected to their PC is NOT directly connected to the server hosting the web applications. Therefore, e-volve developed a small windows service which was installed on a PC inside the shop.

This service essentially listened to the hosting server by way of some exposed web methods made available via Project #5. When the shop user clicks the print button, the web application pulls all the relevant data together which comprises the particular label. A flag is the set within the database notifying the Dymo Application that a new label is awaiting printing. The Dymo application identifies this flag and pulls the data down to the PC before outputting the label through the printer.

Each label file is only ever generated on the shop PC, with only raw data being pulled down from the server.

e-volve staff can upgrade the software dynamically by highlighting that a new version exists.

As mentioned earlier, if you wish to speak to someone regarding any or all of the above, please don't hesitate to contact us. We appreciate that there is a vast amount of information to take in, and it is so much easier to discuss this in person.