Alexander’s Blog – The Making of LetMeGo

We just made public RRápido: The Torrenegra Web Development Methodology. The Merrcury Engine, LetMeGo’s core, is being developed using RRápido.

You can check it out here.

Alexander Torrenegra

Last Friday, while trying to figure out the future of Mercurry’s customer service, interaction systems and processes, I had an “aha” moment. This occured as I went over Mercurry’s ticketing system. Before I tell you about it, here is some background information on “ticketing systems”, CRM, and “customer experience”.

Ticketing systems are software packages commonly used by organizations customer support centers to create, update, and resolve issues affecting their customers.

Customer Relationship Management (CRM) is a term applied to the processes involved in a company’s handling of their communications with their customers. Thus, CRM software supports these processes, storing information on current and prospective customers.

Customer experience summarizes a customer’s experience over the entire duration of his/her relationship with a supplier or service provider. It can also be used in reference to the experience of a single transaction with the supplier or service provider; the distinction between the two is usually clear in context.

In Merrcury, as in any other e-commerce web site, human interaction will take place through a dedicated customer service team. In some cases, it will be triggered by the customer while at other times, by us. In both scenarios, a subsystem is required so that other subsystems, as well as customers, have the ability to create tickets for the customer service team for follow-up and resolution. In the past I have used several ticketing systems, such as LivePerson and Mantis, amongst others. For Merrcury, however, I wanted something better than just a ticketing system. I wanted a full CRM system. This is what we’ve called the Cockerr Scope.

German started working on the Cockerr Scope several weeks ago. He just finished the alpha version, which includes, primarily, a customized version of SugarCRM along with a set of XML interfaces that allow it to communicate with other Merrcury subsystems. (Thank you German!) Soon after German announced the completion of the alpha, I started playing around with it.

I had never invested a significant amount of time using full CRM systems like SugarCRM or SalesForce. This was my first time trying to understand, in depth, the most important features of these applications. I had mixed feelings. SugarCRM seems to be very powerful, but it lacks some basic functionalities commonly available in ticketing systems such as queue management, amongst others. I then went on to try SalesForce. I found SalesForce, in my inexperienced opinion, way more robust than SugarCRM. It seems to be capable of working as a ticketing system while offering all the other benefits of a full CRM system. So, we should switch to SalesForce, right?…

Well… Not really. I think I made a mistake by expecting the Cockerr Scope to be a CRM system. After thinking about it for several hours, I figured that it doesn’t make sense for us to implement a full CRM system as part of Cockerr. Why? Because the Merrcury engine is, as a whole, a CRM system! You may ask: How? Well, while it is true that the largest part of the customer experience in Merrcury will be fully automated, it doesn’t mean that Merrcury lacks CRM. In fact, the Merrcury Engine is going to include some of the most advanced CRM features ever seen in the Lodging Industry. Moreover, to build the customer experience we’re aiming for, every subsystem in Merrcury should be CRM oriented: each scope should have a little (or a lot) of CRM.

We shouldn’t try to make the Cockerr Scope “THE” CRM subsystem of the Merrcury Engine. Instead, we should just try to make it a very good ticketing system, period. We haven’t decided yet which ticketing system we are going to use. We may still use SugarCRM or change to SalesForce, LivePerson or OTRS. The decision will be made next year as we get ready to release the beta version of LetMeGo.

What about the “aha” moment, then? Last Friday, after thinking about all of the above, I was taking a look at Merrcury’s subsystems. Three of these subsystems are called “support scopes”: the Morrison Scope, in charge of email communications; the Web Scope, in charge of web interactions; and the Cockerr Scope, which is the ticketing system. All three of them are used by other subsystems to interact with “the outside world”. The “aha” moment came when I suddenly realized that the Cocker Scope is nothing else than the subsystem that allows Merrcury’s customer service team to communicate with our customers. For LetMeGo.com, human interaction is the complement to email and web interactions. These three subsystems, that we used to call “support scopes”, are in fact Merrcury’s customer interaction subsystems. Although very simple, this realization may help us look at the engine from a new perspective.

By the end of the week, everything was much clearer to me:

• Each subsystem of Merrcury will communicate with our users in four possible ways: via web (Web Scope), by email (Morrison Scope), via XML (engine core), and through our customer service team (Cockerr Scope).
• Customer experience is at the root of the Merrcury Engine.
• Each subsystem of Merrcury has CRM and business rules that will try to provide the best possible experience to our users.

Most corporate executives may not agree with me, at least for now. After all, they have all they need in their “SalesForce”. Don’t they?

Alex Torrenegra

P.S. Luis Henríquez, co-founder of the Language123 project and Agora International, helped me on the writing of this entry. Thank you Luis!

The Merrcury Engine is the set of software and hardware that will power LetMeGo.com. The engine is being built using service oriented architecture. Each major block in this architecture is called a scope. The word “scope”, as used in Merrcury, is the combination of a subsystem residing on an independent server, plus all the web and email interfaces that it uses to communicate with its users. For example: The Mozarrt Scope includes the server where all the messages exchanged by users of LetMeGo come and go. It also includes the web interfaces required for those users to write and read those messages.

The Merrcury Engine is going to originally have 13 scopes. Each scope is going to be very innovative by itself. The combination of all of them working together will be awesome:

• Hendrrix Scope: Allows users to manage their account. Includes, for example, the functionality to create user accounts, sign in, sign out, etc.
• Mozarrt Scope: Includes everything related to messages being exchanged by the users of LetMeGo.com
• Sinatrra Scope: One of the most complex scopes, it allows lodging owners and managers to update information about their lodging in LetMeGo.
• Arrmstrong Scope: This scope will allow us to manage (add, edit, remove) the destinations where travelers want to go.
• Mastrropiero Scope: The search feature.
• Charrlie Scope: Will allow us to manage marketing email campaigns for our users.
• Web Scope, Morrison Scope, and Cockerr Scope: These three are support scopes. They include subsystems that other scopes will be using constantly. The Web Scope relates to the web interface, the Morrison Scope relates to the email (sending and receiving) interface, and the Cockerr Scope is the CRM (customer relationship management) interface.
• Kubrrick, Waterrs, Echeverri, and Starr Scopes: The objectives of these scopes are secret. Their functionality will be revealed as we get close to launch.

Last week I finished documenting the use cases and users interfaces for the most complex scope of all: Kubrrick. The Kubrrick Scope, which objective is secret for now, is going to be the place where most of the action of LetMeGo.com happens. It took me eight weeks to complete the documentation after going through several refactoring cycles. The result is 19 use cases and 125 user interfaces, some of them quite long and complex. We haven’t defined who will be working on this scope, but it is likely that many of us will be coding it. Hopefully, its lengthiness and complexity won’t affect our release schedule.

Alexander Torrenegra

On July 11th Henry’s wife, Evelyn, just released their Version 2.0: Tomas Canastero. Although Tomas has had limited exposure to the public, I was able to grab a screenshot!

When asked if there are plans for additional releases, Henry said: “We are not like Microsoft. We will not release new versions ‘just because’. Don’t get me wrong: we will continue doing plenty of research and development. Nevertheless, it will be done under highly controlled circumstances that will not allow us to expose new code to the public.”

Alexander Torrenegra