Building a custom CRM comes down to seven steps: confirm that a custom build is the right answer, write down the daily tasks it has to support, design the records and how they relate, build a small first version, migrate the old data, launch it with the people who will use it, and keep improving it afterwards. Most failed CRM projects skipped one of the first two. This guide takes each step in order and ends with a hypothetical example.<\/p>\n
HubSpot, Zoho, Pipedrive and Dynamics cover the ordinary case well and cost a fraction of a build. A custom CRM is justified when the way your business sells or serves customers does not fit their model: records that must link to jobs, sites, assets or contracts; quoting with many steps and approvals; a regulated workflow; or a core system no vendor connects to. If two subscription products have been tried properly and both fought the business every day, that is the signal. If nobody has tried one, try one first. Our guide to hiring a CRM developer<\/a> covers the question in more depth.<\/p>\n Not features; tasks. “Log a call against a customer.” “Send a quote from a template and see when it was opened.” “See every job for this site.” “Get a list of contracts expiring next month.” Five to ten of these, written in the words of the people who will do them, is the whole specification for the first version. Everything else is detail that can be decided during the build. Ask three staff to each list their tasks and you will find the list converges quickly.<\/p>\n This is the part that makes a custom CRM worth building. A standard product gives you contacts, companies and deals. Your business might need customers, sites, assets at each site, service contracts on each asset, scheduled visits, technicians, and invoices, all connected. Draw the records as boxes and the connections as lines on one page. If it fits on one page, the system is buildable. If it does not, simplify until it does, because the first version should carry only what the daily tasks need.<\/p>\n Decide the source of truth for anything that lives in another system. Customer names probably come from the accounting package; the CRM should read them rather than keep its own copy.<\/p>\n The first version does the daily tasks, has one or two user roles, connects to one system (usually the accounting package), and has one or two reports. Eight to fourteen weeks with an experienced team. It is deliberately incomplete, because the business will discover what it actually needs by using it, and that discovery is cheaper after launch than before. Resist the urge to add “while we are at it” features; write them down for version two.<\/p>\n Technology choices belong to the developer, with two conditions: the system is hosted in Australia on a mainstream cloud platform, and the code is in a repository you own. Beyond that, a sensible web application framework, a standard database and a plain, fast interface will outlast anything clever.<\/p>\n Your contacts and history live in spreadsheets, an old system, email and people’s heads. Getting them into the new system cleanly is a project inside the project: duplicates merged, formats standardised, missing fields filled or accepted as missing. Plan a fortnight for it on a small business and longer for an old database. Do a trial migration before launch, let staff look at their own customers in the new system, and fix what they find. Migration is the step staff remember, because it is where they decide whether to trust the new system.<\/p>\n Run the new system alongside the old one for a week or two with a few staff, then switch. Train by task, not by screen: “here is how you log a call”, in the order of a normal day. Make one person in the business the owner of the system, the one who collects the list of improvements and decides what goes in next. Switch the old system to read-only on launch day so there is one place to work.<\/p>\n A custom CRM is never finished, which is its advantage over a subscription product as well as its cost. After launch, small improvements monthly on a retainer, larger additions as the business changes, and maintenance because the systems around it change. Budget roughly 15 to 20 percent of the build cost a year for running and improving it. Security is part of this: the CRM holds personal information, and under the Privacy Act’s APP 11 the business must take reasonable steps to protect it, which the OAIC’s guide to securing personal information<\/a> sets out: access per person, multi-factor authentication, backups, audit logs, and destroying data when it is no longer needed. The Australian Cyber Security Centre’s small business cyber security guide<\/a> covers the practical minimum.<\/p>\n Want this as a one-page checklist?<\/strong> Seven steps and ten checks for building a custom CRM, on one A4 page.<\/p>\n Download the checklist (PDF)<\/a><\/p>\n<\/div>\n This is a hypothetical, not a client. Take a Darwin pest control company with 18 staff. Its work links customers to properties, to treatment plans with scheduled visits, to technicians, to chemical records that must be kept for compliance, and to invoices in Xero. Two subscription CRMs were tried and neither handled properties and treatment plans. Step one is therefore settled. Step two produces nine daily tasks from the office and the technicians. Step three fits on a page: customers, properties, plans, visits, technicians, chemical records, invoices. Step four builds those nine tasks with two roles and the Xero link in eleven weeks. Step five migrates four years of spreadsheet records, which takes a fortnight and finds 300 duplicate customers. Step six runs the two systems in parallel for a week with two technicians, then switches. Step seven adds customer reminders and a compliance report in the following months. The staff’s verdict six months in is that it is the first system that works the way the business does, which is the only reason to have built it.<\/p>\n High10 builds custom CRM systems<\/a> for Australian businesses in exactly this order, and tells you at step one if a subscription product would serve you better, in which case we configure and automate HubSpot<\/a> or connect CRM automation<\/a> instead. First versions are scoped to the daily tasks, you own the code and data from day one, and every project is quoted in writing after a scoping call.<\/p>\n Low-code platforms can get a simple system running for one team, and they are worth trying before a full build. They tend to struggle with complex record relationships, integrations and more than a few user roles, which is exactly the territory where a custom build is justified. If the one-page record diagram is simple, try low-code first.<\/p><\/div><\/details> A first version covering the daily tasks, one or two roles and one integration takes eight to fourteen weeks including migration and testing. Larger systems with several integrations run six months or more. Building small first and adding monthly is faster and safer than building everything at once.<\/p><\/div><\/details> Whatever the five to ten daily tasks require, and nothing else in the first version. Typically: records that match your business, a connection to the accounting package, quoting or documents from templates, reminders, and two or three reports. Features are added after launch as the business shows what it needs.<\/p><\/div><\/details> It depends on the record types, user roles, integrations and data migration involved. We quote each project in writing after a scoping call rather than publishing figures. Our guide to custom CRM development costs<\/a> gives the Australian market ranges.<\/p><\/div><\/details><\/div>\n Want this as a one-page checklist?<\/strong> Seven steps and ten checks for building a custom CRM, on one A4 page.<\/p>\n Download the checklist (PDF)<\/a><\/p>\n<\/div>\n Building a custom CRM comes down to seven steps: confirm that a custom build is the right answer, write down the daily tasks it has to support, design the records and how they relate, build a small first version, migrate the old data, launch it with the people who will use it, and keep improving […]<\/p>\n","protected":false},"author":2,"featured_media":103,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[],"class_list":["post-104","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business-systems"],"yoast_head":"\nStep 2: write down the daily tasks<\/h2>\n
Step 3: design the records and how they relate<\/h2>\n
Step 4: build a small first version<\/h2>\n
Step 5: migrate the old data<\/h2>\n
Step 6: launch with the people who will use it<\/h2>\n
Step 7: keep improving it<\/h2>\n
A worked example<\/h2>\n
How High10 helps<\/h2>\n
Frequently asked questions<\/h2>
Can I build a custom CRM without a developer?<\/h3><\/summary>
How long does it take to build a custom CRM?<\/h3><\/summary>
What features should a custom CRM have?<\/h3><\/summary>
How much does it cost to build a custom CRM?<\/h3><\/summary>
Related reading<\/h2>\n
\n