Elliot Svensen

Reducing keying errors

Service & Product design


Habito is a complete home buying service but the core business is brokerage.

Customers sign up and fill in some forms before being paired with a Mortgage Expert who assesses their situation and recommends a suitable mortgage.

If the customer decides to proceed with that mortgage they complete additional forms & upload some documents.

Their case is then reviewed by the Mortgage Expert and submitted to a Mortgage Admin to be keyed into a lender portal.

Rough guide to the Habito submission process


If the Mortgage Admin encounters any issues when keying the case they will pass the case back to the Mortgage Expert, when this happens we waste time.

If the Mortgage Admin does not encounter any issues but the Lender then identifies issues the Lender will send the case back to us and the case will be passed back to the Mortgage Expert, wasting even more time.

This delay is bad for our operations team as it is wasted effort. More importantly, for our customers it’s at best annoying and at worst incredibly costly.

If a Lender were to increase their rates during the delay the customer would end up with a mortgage on a higher rate meaning higher costs for them.

We wanted to understand why these issues were happening so we could prevent them in future.

If we break the keying error data out by issue and look at the instances over time there’s a clear pattern.

We see high instances of an issue, roll out training, see instances drop for a month and then creep back up as training is forgotten.

Top offending keying errors

The Problems

Managing cases between recommendation and submission is not easy. Our Mortgage Experts aren’t told when a case is ready to submit, they need to work it out for themselves.

We needed to clean up the process, in order to make it easier for Mortgage Experts to manage cases, reduce the number of keying errors and ensure Mortgage Admins have easy access to the information they need to key a case.


Highlighting what needs to be done on a case before submission in the UI and enforcing the workflow will lead to a reduction in the number of keying errors we are experiencing.

We can do this by:


Mortgage Experts

I started by working to identify what needs to be done before submission by the Mortgage Experts.

This involved lots of mapping through workshops and shadowing to identify the existing process.

The submission process

I then ran workshops with Mortgage Experts to sort activities by when they need to be completed.

Output of a Whimsical workshop with Mortgage Experts

This enabled me to put together a list of checks that needed to be carried out and a map of the ideal future state of the submission process.

Mortgage Admins

Next I started working on identifying the information Mortgage Admins need to submit to the lender.

This was a massive data mapping exercise achieved through:

Example of some of the Mortgage Admin data mapping

Once I’d produced a set of data I validated this through watching more keying videos and marking missing fields while watching.

The outcome of this was a categorised list of fields needed for keying and variants designed for specific case types.

The solution, the Submission guide & the Packaged case

The Submission guide walks a Mortgage Expert through preparing a case for submission. It will ensure information is reviewed when it comes in and any issues are always flagged in the UI.

Once submission is completed this transforms in to the Packaged Case →

The Packaged case supports a Mortgage Admin keying the information into the lender portal. Information lives in one place, it’s never missing (and hopefully never wrong).

Staggered delivery

Working alongside the Product Manager and Senior Engineer we split the delivery into 3 stages.

The submission guide

The submission guide and packaged case

Redesigning the forms

Our existing forms aren’t easy to digest, there is a lot of vertical scrolling. While implementing the packaged case we had an opportunity to improve the forms and to speed up keying process.

I redesigned our form sections and added tabs and tags to handle repeatable information.

Customer details improvements

Fleshing out the checks

With the actions that needed checking well defined I worked alongside Engineers and Mortgage Expert team leads to define states.

The submission checks

Validating the new process

After launching the first version myself, the PM and the Engineers shadowed as many Mortgage Experts and Mortgage Admins as we could while they worked through the new process.\ \ The feedback was mostly positive except in our remortgage team, we’d created more work for Product Transfers.

We did not store if a case was a Product Transfer in our system and it was left to the Mortgage Expert to leave notes to tag cases when they were.

Product Transfers are far simpler than our other cases and so require a lot less information but, when enforced, our checks would requiring this information was added to the case.

I went back to the Mortgage Admin team and drew up another, smaller set of data we’d require for Product Transfers and worked with the engineers to tweak our recommendation flow to capture when they would apply to a case.

Enforcing the checks

With the Product Transfer issues resolved we could enforce the checks.

There were a few outstanding elements that needed working up, a modal for cancelling cases and handing them back, revised tasks telling the Mortgage Admins to submit the case to the lender etc.

After building these we were ready to go.

Cancellation modal

Submission tasks


We now have a more linear submission flow, we’ve seen a reduction in resubmissions & keying errors and have hopefully reduced the training burden on Team Leads.

The resubmission rate for submission