Burrito Reviews, Rankings, and Burrito Debt Collections

The Challenge

The Agiloft implementation team is home to more than a few breakfast burrito enthusiasts. Some weeks, there would be a breakfast burrito run almost every day of the week, and other weeks there would be at least one or two a week.

However, as time passed and as we worked our way through trying several dozen different breakfast burrito vendors in the area, it grew very challenging to keep track of which ones were winners and which ones were losers; which ones were good value, and which ones were overpriced with little to offer. On top of this, burrito debts also became hard to manage, as different people would make runs on different days, and no one could really remember who owed who, or how much.

The Solution

One of the members on our implementation team who is an avid breakfast burrito connoisseur, Jennifer Ross, thought it would be a fun idea to build a “Burrito KB”. It started off as a joke, but quickly became a darling side-project we would work on improving during lunch or after work hours.

We built a system that ultimately fulfilled all of our needs, consisting of the following tables:

Burrito Analysts (People): Users who could access the system and submit reviews/ratings.
Restaurants: A repository of all restaurants serving breakfast burritos in the immediate area, with links to menus, pricing information, ingredients lists (i.e. if they have options for avocado, extra cheese, types of meat, add-ons, etc.), address information, a list of ratings given along with an average, and its overall ranking relative to all other restaurants in the repository.
Reviews: A table that stored individual reviews from different analysts.
Debt Ledgers: A table that stored records of each burrito that was purchased by one analyst for another. These could be easily created via conversion from the Restaurant record, allowing one analyst to select multiple other analysts to say, “I bought burritos for these 5 people, so add $8.50 to each of their burrito tabs”. These would then be summed up and displayed in the Analysts table as two separate embedded tables, such that you could see all Debts Owed by a particular analyst, as well as their Burrito Accounts Receivable.

While we didn’t expand too much on the Debt Ledger component, it could have easily also been upgraded into a debt collection system by adding periodic notification logic to remind burrito debtors to pay their debts to their burrito creditors if, for example, their debt had accumulated beyond $25 or some other threshold.

The system quickly became a robust repository that housed a wealth of knowledge about the best breakfast burritos in town that any implementer could access at the click of a button, with rankings, average ratings in different categories, addresses, and pricing information. It was one of the funnest implementations that motivated us to make spontaneous enhancements and improvements as we thought of fun ideas and nice-to-haves at random times, but it also surprisingly sparked some interesting design challenges and lighthearted discussions on the best way to build something (there were several ways to handle the debt collection aspect).

At the end of the day, while it was a fairly simple and low-effort implementation and started as only a joke, the system we built more than overcame the initial challenge, and unexpectedly had a very positive impact by enriching the day to day lives of the implementers at Agiloft; not only as a source of useful information and inside jokes, but also one of irrational and unjustifiable pride.