A loan calculator on a website should work out the same things a manager will work out later: the monthly payment, the total cost of credit and the payment schedule, based on the company's actual terms. If the figure on the website and the figure in the contract don't match, the client stops trusting you before you have even met. That's why a good calculator is a simplified copy of your internal calculation, not a widget with sliders.
Below we look at which fields you need, what to show the client, where the rates should come from, and how to make sure the calculation isn't lost once the button is clicked. The principles are the same for bank loans, microloans and leasing.
Why a financial company's website needs a calculator
One evening, a business owner is working out whether they can afford to lease a second truck. It's too late to call, but they want to decide today. On a website with a calculator, they can find the down payment and term that bring the monthly payment within reach, and send an application in the morning. On a website without one, they will most likely go to another company's site to do the sums.
For the company, a calculator brings in better-prepared clients:
-
The first conversation is shorter. The manager doesn't spend the call answering "how much will it be a month?" and moves straight on to the paperwork.
-
Fewer dead-end applications. Someone who can't afford the payment will see that for themselves and won't wait for a call that leads nowhere.
-
It's clear what the client wants. The amount, down payment and term have already been chosen, so the manager has something to work from.
-
You can see demand. The calculator's statistics show which amounts and terms people calculate most often. That's a pointer for new products and for advertising.
Put the calculator where clients make their decision: on the homepage and on the page for each product. On a product page, it should already be set to that product's terms.
Which fields you need: amount, down payment, term, currency
There's one rule: every field must change the result. A field that doesn't affect anything only holds the client up.
-
Amount. The loan amount, or the price of the machinery or equipment to be leased. As well as a slider, you need a field where the client can type the exact amount from the supplier's invoice: getting a slider to land on a precise figure is fiddly, especially on a phone.
-
Down payment. Shown both as a percentage and as an amount. Terms are usually set as a percentage, but clients think about how much money they have to hand over up front.
-
Term. Only the options your products actually offer. If the calculator lets people choose a term that doesn't exist, the manager will have to redo the numbers and explain.
-
Currency. Needed if you really do work in more than one currency. There's no point adding the field "just in case".
If the terms depend on the product — new or used machinery, a company or an individual — let the client choose the product. And limit the values: when a client enters a down payment below the minimum, the calculator should prompt them with the minimum instead of quietly calculating a payment you won't approve.
What a loan calculator on a website should show
-
The monthly payment, first and in large type. That's the figure the client opened the calculator for.
-
The total cost of credit. How much the client will pay on top of the loan amount or the price of the machinery; in leasing this is often called the mark-up. If you hide it, the client will find out anyway, from the manager or from the contract, and then there will be more questions.
-
The payment schedule. Month by month, in an expandable section, with an option to download it. If you offer both equal and decreasing payments, add a switch so clients can compare the options themselves.
-
What the calculation doesn't include. Insurance, fees and other costs paid separately, in one line under the result.
Next to the result you need a note: "This is a preliminary calculation; a manager will confirm the exact terms after reviewing your application." It doesn't excuse an inaccurate calculation, but it honestly explains why the final figure may differ.
And calculate using the rate a typical client gets. If the default is the lowest rate, which only a handful of clients ever receive, that's the one the client will remember, and the conversation with the manager will start with disappointment. Check with a lawyer which disclaimers you need in your case.
Where the rates come from and who updates them without a developer
Rates, the minimum down payment and the available terms shouldn't be hard-coded into the website. Otherwise your conditions change, the developer is busy, and for several days clients go on calculating with the old figures.
It's better to keep the conditions in the site's admin panel, broken down by product and term. The employee responsible for products changes a rate, saves it, and the calculator immediately works with the new figure. A few things matter here:
-
Only authorised staff can change the terms. Access to rates is granted separately from access to news and other sections.
-
Changes are saved in a history. You can see who changed a rate and when, and restore the previous value.
-
The website and your managers calculate the same way. Before launch, run a few examples through both the calculator and your internal calculation. If the results differ, find out why before going live.
This also answers the question of how to build a calculator for a financial company's website. Ready-made calculator builders are fine for a simple formula. When you need several products, limits, a payment schedule and applications passed to the CRM, the calculator is usually built around your own terms.
An application from the calculator goes straight into the CRM
It's a shame when a client has worked everything out, clicks "Apply" and lands on an empty form where they have to enter the amount and term all over again. Some people close the tab at that point.
The button under the calculation should open a form with the parameters already filled in: amount, down payment, term, product and payment. All the client has to add is a name and phone number. The application goes to the CRM together with the calculation, the manager gets a notification and calls already knowing the figures.
Along with the calculation, it's worth passing on the source of the application: advertising, search or a partner. Then you can see which channel brings clients with real amounts in mind and which brings random clicks. We looked at how this link works and where it usually breaks in our article on connecting a website to a CRM.
The calculator is only one of the steps a client takes before applying. The others are described in the article on what clients check on a leasing company's website, and what the CRM itself should keep track of is set out in our piece on CRM for microfinance and insurance companies.
Checklist
-
The payment on the website matches the manager's calculation. Work out the same example in both places.
-
Every field affects the result. Remove any that don't.
-
The calculator won't let people choose terms you don't offer. If the down payment is too low or the term doesn't exist, it responds with a prompt.
-
The payment, the total cost of credit and the schedule are all visible. And below them, what the calculation doesn't include.
-
There's a "preliminary calculation" note. Plus an explanation of what the exact terms depend on.
-
Rates are changed by a staff member, not a programmer. And you know who changed them last.
-
The application reaches the CRM with the calculation parameters. The manager doesn't have to ask for the amount and term again.
If you need a calculator that clients trust and your managers don't have to contradict, take a look at what we do for leasing and financial companies and get in touch. We'll go through your products and suggest what the calculator should work out and how.
