Client

An entrepreneur from Switzerland commissioned Elinext to develop food ordering software for landline phone calls.

Challenge

Landline phones are still actively used in Switzerland, and consumers expected restaurants to keep that in mind while adopting delivery during the pandemic. But available technology for quick and effective order processing didn’t comply with the national landline system and its specifics. And restaurants struggled.

One entrepreneur set out to lend a hand to the industry. He conceived a web application that would empower restaurants to meet customers’ needs and benefit from latest technological advances at the same time.

The entrepreneur had been subscribed to our newsletter, so he chose to try us. We quickly sourced the specific Swiss modem that was required for building the application and put together a demo version. Impressed by our swiftness, the entrepreneur outsourced the job to us.

Process

We began with essential research. Our business analyst interviewed the client, who had experience as a restauranteur, and narrowed down the initial scope of work.

Our client hadn’t done much research into the target technology himself or provided us with a lot of specified details. He aimed to check his business hypothesis by building a minimum viable product (MVP) and testing it with restaurants first. But all he had back then was an outdated app that didn’t work with the FRITZ!Box Modem, the default landline technology in Switzerland.

So, the best way to organize the work was by using Agile/Scrum practices. We worked in sprints, talking to our client at least twice a week, and gradually adopted more of the Agile methodology.

The MVP

It took us around nine months to build the MVP. Throughout this period, we created a database structure for the product and early versions of the two applications making up the system. Our client guided us as the primary beta tester, providing feedback and feature suggestions.

At some point, the MVP was ready for restaurants to try. But when they did, customers showed little enthusiasm for adopting the new approach. To overcome this obstacle, we simplified the functionality, removed anything that could lead users astray and improved user experience.

At first, our client had been reluctant to add a professional UI/UX designer to the team but we changed his mind. And he has never regretted that since. Not only did our designer upgrade the visuals — he also helped develop a glossary of German terms and add them into the user interface.

The FRITZ!Box Modem

Using the FRITZ!Box Modem was a prerequisite to the development. And that put some limitations on the process, especially when it came to testing.

A modem like that needs to be connected to a leased phone line. So, to test the software, our QA specialist had to be physically present close to the device and the landline phone. And when that person was away, someone had to take their place to help them gather feedback.

Refining Requirements and Specifications

Our client overloaded the list of features with new ideas, and incorporating those additions became a challenge.

To get everyone on the same page, we singled out a workflow for processing, refining, verifying, testing and tracking project requirements. This was organized as a separate business analysis board in the project tracking system. Using it, we were incrementally turning the pile of ideas into actionable user stories.

Expanding the Product

After we fitted the product to the market, restaurants adopted it more willingly, providing us with valuable feedback. We used this feedback to build new features and completely redesign the software, rolling out a new, fully operational version of the product.

Before that, we had tested the software manually. But that wasn’t enough anymore, and we brought in unit and automated testing. With that strategy, we could run all the most common user scenarios and see how the software responded.

Product

The software we built enables restaurant administrators to take delivery orders from landline calls. It comprises two web applications: a web portal for managing restaurant details (e.g. menus or staff) and a desktop app for processing orders.

Restaurant Management

The restaurant management interface supports two user types. First is the superadmin who acts on behalf of our client. They onboard new restaurants, edit their statuses, manage the restaurant staff and generally manage the system.

The second user type is admin and is designated for restaurant managers. They can do a lot of things including the following:

• set up menus by adding, editing, categorizing and removing items;
• view current and completed order details and monitor them by status (e.g. accepted, cancelled or pending);
• track incoming and missed calls;
• view order history for each customer
• configure price calculations from delivery areas and order types;
• set payment methods;
• track taxes;
• view auto-generated reports on daily restaurant performance.

The chosen configurations will reflect in the order processing.

Order Processing

The order processing application is a desktop interface for restaurant administrators. Here’s how it works.

When a customer calls the restaurant, the administrator sees a notification on the computer screen. And once they’ve picked up the phone, the application will show the customer form based on their number.

If this customer has ordered before, the form will include their address, email and previous orders details. The latter can be replicated or used as a basis for a new order. And if this is a new customer, the administrator can fill in the details for further use.

As the caller goes on to order, the administrator can choose menu items for them. They start by specifying the category, after which a list of accompaniments and size settings are displayed.

The administrator adds all the items to the virtual cart and specifies parameters like the payment method, service type (delivery or pickup), date and time. If necessary, a note can be added.

Once the order has been placed, the administrator can save it as pending or accepted. The receipt will be sent to the customer’s email if that has been specified in the form. Otherwise, after saving the order, the administrator will see a notification. And the receipt will be printed automatically and to be handed to the customer or courier alongside the order.

The main screen features all the current orders accompanied by statuses. Any order can be edited or cancelled until the scheduled delivery or pickup time. And for easier navigation, orders are sorted on the dashboard by status (pending, accepted or cancelled).

Another useful feature is the call history tab. This tab allows the administrator to browse all of the current day’s calls (including any missed ones) and view all related details.

Results

We helped the Swiss entrepreneur develop a slick web solution that allows restaurant administrators to process more orders per shift and leaves customers happy. And we continue improving the software.

Our future scope of work includes automating remote updates for restaurants, enabling CSV reports, integration with Microsoft Power BI for actionable analytics, receipt redesign and more. Even further into the future, the client has conceived an upgrade into a self-sufficient virtual call center for order processing.

This project has been very informative to us. On the one hand, we’ve learned how to manage client expectations and requirements efficiently. And on the other hand, we've collected some very specific domain knowledge about restaurants and food ordering — especially in Switzerland.