Custom CRM and intranet systems

To scope a custom CRM or intranet, describe a task your team carries out today, who is involved and where the information lives. Sample forms or anonymised records help us understand the workflow. We agree user permissions, reporting and integration requirements during scoping. The first stage is process mapping, where we sit with the people who do the work and write down what actually happens, including the parts that are not in the official process. That stage comes first, is quoted separately, and decides whether the project should happen at all. The written scope then sets out what version one does, what it explicitly does not do, and what data comes across from where. Reports are defined at this point too, because a report nobody agreed the definition of is a report nobody trusts. If an off-the-shelf CRM would do the job, we will tell you that on the first call, before anyone takes on a build that a subscription would have solved.

Usually, yes. A custom CRM or intranet can integrate with the software you already use. Accounting, email, calendars, EPOS, payment and shipping providers all have APIs. We check the specific ones at scope, because a product having an API and a product having an API that does what you need are different statements. Integration requirements are agreed during scoping alongside user permissions and reporting, and the written scope records what data comes across from where. Two signs that a custom system is the right answer are two systems that both hold customer records and disagree, reconciled by hand, and one number calculated three different ways. The aim is one record per customer with the history attached, and numbers calculated once, in one place, and exportable. As an example of connected work, we built CRM and licence management for a teleprompter manufacturer, connected to a custom API so hardware in the field can activate and validate licences.

Changes to a custom CRM or intranet after launch are quoted as work. Many clients hold a support agreement so there is an agreed route for small changes, but it is not a condition of the build. The written scope sets out what version one does and what it explicitly does not do, so it is clear when a later request is new work. Anything outside that scope comes back to you as a short note with the cost and the schedule impact before we build it. The system is also built so that another team can change it. The code is in a repository you own, with a README that tells a developer how to run it. The data is in a standard database you can export from at any time, in a documented schema. No component stops working because we stopped being involved, and the process the system implements is documented in writing.

No. A custom CRM or intranet runs in a browser and works on a phone, but beyond that it is software, and it is scoped, built and tested like software. It holds customer and contact records with the history attached, and it moves work through the stages your team uses, such as enquiry to quote to job to invoice. It can carry forms, approvals with a record of who approved what and when, documents, and the reporting the business runs on. Roles match your org chart, access can be revoked when someone leaves, and there is a log of who changed what. That permissions and audit layer is hard to add later, so it is designed in from the start. The project also runs differently from a website build. It begins with process mapping, delivers something a real team can use within the first phase, and runs the old way and the new way side by side for a period.

The data in a system we build lives in UK data centres, on infrastructure we manage, in an environment isolated to your system and not shared with anyone else. Backups stay in the UK too. If your own policy requires the data to sit somewhere specific, say so at scope and we will build to that instead. See hosting for how that infrastructure is run. Wherever it sits, the data is in a standard database you can export from at any time, in a schema that is documented. The code is in a repository you own, and no component of the system stops working because we stopped being involved. Access is controlled through roles that match your org chart and can be revoked when someone leaves, with a log of who changed what. When the system launches, existing data is migrated and checked, and for a period the old way and the new way run side by side.