Hacking Our Back End Systems

3 months ago, we turned on the Hotels.ng call-center. The decision was quite quick, so we did not have any software for the back end. All calls were logged on A4 papers and filed in a cabinet.

This obviously was not a good method, so I introduced desk.com to log all customer complaints. The call center staff would use Desk.com when I was around, and whenever I was not there, they would use paper. Then transfer the calls to Desk.com at the end of the day.

After observing this for a while, I told them to go back to using paper. I asked them to use a ruler and make tables and structure the paper in the manner that would be most helpful to them. They came up with 3 sheets – Missed Calls (a grid), Inquiries (a grid), Incoming calls (a list), Bookings (an A4 sheet with all the booking details). They started using these sheets regularly and happily, and we would file them. We have 5 big folders filled with these sheets of papers.

I and my developer Iulian then sat down with these sheets of paper and recreated them using twitter bootstrap. We added things like displaying the numbers of the hotels, allowing them edit rooms and so on, but it was basically the sheets of paper transferred to the system.

When I introduced the system to the team, they switched and were using it in 5 minutes. They never touched paper after that. Within a day, I had 10 requests on what should be added to the software systems. The bookings team basically designed the back end systems themselves in a manner that integrated with their workflow.

Now we regularly get people asking to come look at our back end systems to see what aspects they can copy and use for their own companies.

I’ve been asked how I came up with the design. I always reply that it was not me – it was a group of specialists that did!

This post was originally published on Mark’s Medium.

Mark Essien is the founder of Hotels. Follow him on Twitter here.



  • Abiola Omoniyi says:

    great post, shows the power in collaborating with end users to build a system with them for them, rather than foist something on them which they are almost certain to resist using or worse, not use at all. Nice one.

  • This will make a good change management case study. The more complex a solution is and the further away it is from existing processes, the higher the chance of failure. That is why over 60% of major ERP implementations fail.

    So what did you replace the drawers with in terms of database?

  • Totally loving the creative and practical approach to code that you’ve brought to bear here. It’s great to know that some of us actually write code to solve our own small problems instead of depending on already established frameworks and sacrificing our specific needs to conform to their limited feature sets.

    I’m not advocating re-inventing the wheel here or anything like that, because frameworks are great. I’m just saying that there’ll be times when we just need to roll up our sleeves and tackle some questions that still don’t have answers within our own specific context. Besides, someone had to create frameworks in the first place…and they probably did it to solve THEIR own problem.

    It’s not until you’re working on arcane, mammoth, enterprisy software projects that will save the world that we’ll know that you can code. It’s the little things like these that matter, flexible and disruptive thinking at work here.

  • Bhose says:


  • Lovely post!

    Software shouldn’t be more work than the manual process it should be replacing.

    This is the problem with many complex applications in the Enterprise space, with their bosses paying large sums on licenses for solutions that their teams hardly touch.

    The measure of any good business software is how easily and frequently people use it to improve business process and save cost.

    Except you are Apple or Steve Jobs (“..people don’t know what they want”), this is how business software design should be approached.

  • Saheed says:

    Lovely post. Absolutely lovely.

  • ajibz says:

    This is exactly how it should be done. It is hard doing this while working for 3rd party companies, too much overhead in communication.

Comments are closed.