Redefining the agents handheld experience


We noticed a trend that some of our clients were dropping the ball. The bigger problem is that our platform was allowing them to do it. Now, not every agent fell into this category but, a majority did. There’s too much noise in their daily lives and without a concise list of what to focus on, they were scattered.

The question we asked ourselves initially was can we enable all agents to work more efficiently?

The mobile landscape was an interesting beast for us. We had tried a few proof of concepts internally but, never moved one to general availability. The biggest hurdle that we ran into was: we didn't have an API that would allow us to access the data housed in our CRM.

Designing the Experience
We started from scratch on a device that we’ve never shipped an app on before. But, we knew the type of behavior change we were hoping to drive would be well suited or an app. Our product offering is unique in that we have a few layers of roles. We chose to focus on our largest role - The Agent. Early in the process, our cofounder wrote on the whiteboard:

Have More Conversations; Respond Faster; Qualify More Leads; Set More Meetings

These were almost inadvertent values for the app. It allowed us to come back later and guide our decision making process. Does this really help an agent respond faster? Does this really help an agent have more conversations?

We kicked around various types of navigation, flows and information architecture. A concept that stuck early on was a feed or a list of things that were “waiting” on the agent to tend to. This would be a good place to house clients reaching out to the agent via a form, email, text, call, etc. This became our first and most important tab: Waiting on You.

Our workflows in the CRM are very action oriented - meaning almost all of these actions have a to-do created for the agent for them to work through. Call this person, email that person, set up this appointment, etc. Since that was so prominent in the CRM, it made sense that this was our second tab: To-Do’s.

The third was an evolution of the traditional CRM. We have a feature called The Opportunity Wall. We’re bubbling up opportunities and insights to the agent that they should act on. Some examples include: If a user comes back to the site after being gone for a long time, a user calculates a mortgage, if a user updates their profile - these are all great times to check in with the user. It also lets agents see how “alive” their client pipeline is. This represented our third tab: Insights.

Building the API
I’d like to say that this was an easy, straight-forward process but, it was not. That said, I don’t think we could or would have done it any other way. The facts were: we didn’t have an API and we didn’t have a mobile app. In order to get both of those done, we ended up running the app development and the API development in dual tracks. While the foundation teams were plumbing the data, the mobile teams were working on the app design and functionality. In a perfect world, the API would have come first but, we ended up having an API that was directly tailored to the app itself. This informed the structure of the data and kept API calls lower than integrating an existing API.

Another potential downside to parallel development in a large project like this, is that both sides of the project look like they’re really far along until… you connect them. Once the data starts flowing into the app and once the app starts calling the data, things get real. We were able to get a handle on bugs and quirks pretty quickly. However, we learned that getting your QA environments as close to production as possible will help cut down on random production race conditions. The very nature of a QA environment is different from production so, this is hard to do in practice.

waiting on you

Rolling this thing out to our client base was a large challenge that took us weeks of refinement. Since we just created both the API and the apps from scratch, we were also debugging both the apps and the API. Luckily, iOS was ready for primetime ahead of Android, at least we were able to focus on one platform. We utilized several VIP clients who are known for great feedback and could get their agents to adopt the app pretty rapidly. Luckily, all the homework we put into the design phase, helped agent adoption. If we were also battling something that was not sticky for them, this probably would have been the demise of the app.

We continued to ship in batches to customers. Both to load test the API and keep a handle on the amount of bugs we’d be able to handle at a given time if we needed to. This was not an overly buggy product but, any greenfield development is filled with it’s own set of quirks. One of which was the load of production itself. We have a number of clients who have been with us for years which means - they have a lot of data. When you log in, we’d queue database syncing and notify you when it was complete. But, for clients who had a large influx of leads or inquiries, the amount of DOM that was loaded on the device was too much for it to handle. This was a quick fix but, took us a while to pin it down given the nature of how many moving pieces we had.

Once we had the app out to customers, we collected feedback for about a month and continued to improve and iterate on the existing product. The app has been the most successful product we've launched to date and continues to grow in adoption month over month. The amount of sweat and tears we all poured into it, paid off. Want to see the real thing? Check it out on the App Store or on Google Play for Android.

lead profile

DAU: ~7,500 (higher than desktop)
MAU: ~18k
Avg Lead Response Time: ~2mins (desktop is over one hour)

The Team:
Chad Engle - Design Director
DJ Fullante - Product Designer
Nate Lacy - Product Designer
George Mountis - Product Owner

Huge shout-outs to all teams: Product, CRM, iOS, Android, Foundation, Project Management, Client Services, Support and Product Marketing.


Designing for Devices

Read It