Customer information is fragmented
Contacts, enquiries, documents and activity history are split across files or systems, leaving the team without one controlled operational view.
CRM development
CRM development shaped around customer data, roles and real work.
We develop web-based customer and workflow systems when an off-the-shelf CRM cannot represent the company’s sales, service or follow-up work accurately enough. Discovery starts with data ownership, roles, stages and connections rather than a generic feature list.
Discuss a projectWhen custom CRM development is justified
Real stages do not fit the product
Company roles, approvals and exceptions require their own states, permissions and action rules that configuration cannot cover safely.
The CRM must exchange data
Forms, ERP, billing or other agreed sources need an explicit source of truth, field mapping and visible error handling.
A CRM begins with data and responsibility
One owner for each key record
We define where a customer, contact, enquiry and job originate and where each may be changed. Two-way synchronisation also needs a conflict rule.
States must guide action
A lead or service stage should show what can happen next, who is responsible and which information is required, rather than acting as a free-text label.
The first stage completes one flow
A bounded release might cover enquiry to qualified work. Reporting, automation and secondary processes remain visible priorities instead of hidden assumptions.
What a CRM solution may cover
What a CRM solution may cover
- Customer, contact and activity model
- Roles, permissions and ownership
- Enquiry or job workflow states
- Search, filters and operational views
- Agreed APIs, notifications and history
What we need for a useful discovery
Current work and ownership
Describe who uses the solution, which steps are manual or split across tools, and who owns the key data and decisions. Existing screens, a process sketch and representative cases help separate daily work from rare exceptions.
Data, connections and constraints
We list the systems, data sources, access rules, languages and integrations in scope. Missing documentation or a test environment is recorded as a dependency; the behaviour of an external system is never assumed.
Acceptance and evidence
We agree which complete action must work in the first stage, how the result will be checked, and which failures must be visible. A metric is included only when its source data and calculation are available.
From a defined decision to a working stage
Discovery
We review users, the business goal, current work, data, dependencies and critical exceptions. The output is a testable scope rather than a speculative feature list.
Structure and prototype
Core actions, states and information architecture become screens or a technical flow. Before development, we verify that both the user and the operator can reach a complete outcome.
Development and connections
The agreed interface, server-side logic and integrations are delivered in controlled increments. Error handling, permissions and observable events are part of the same acceptance scope.
Testing and handover
We check the normal journey, important exceptions, relevant devices and agreed data exchange. Known limits, ownership, monitoring and a rollback approach are documented before launch.
Boundaries to settle before implementation
Boundaries to settle before implementation
- First-stage users, roles and one complete primary journey
- Owners of key data, required fields and retention needs
- Named external systems, access and test-environment availability
- Critical exceptions, error states, permissions and auditable events
- Acceptance checks, launch ownership and a visible next-stage list
Launch, monitoring and ongoing ownership
Handover is more than a set of finished screens. We document the agreed functions, access and administration guidance, external dependencies, known limits, and checks the team can use to observe the solution. The launch method, data cutover, rollback option and next-stage priorities are selected according to the system’s actual risk; they are not presented as fixed promises before discovery.
Public evidence of an enquiry journey
MVAuto
In MVAuto, GoMedia connected catalogue search, vehicle detail and a dealer enquiry in one controlled web journey. This supports workflow capability, not a claim of a separate public CRM product.
View case study
CRM development questions
Does every company need a custom CRM?
No. If an established product fits the data and workflow, configuration may be the better decision. Custom work needs a clear operational or integration reason.
Can existing customer data be migrated?
The scope follows a review of fields, duplicates, quality, legal basis and access to the source, followed by a representative trial.
Can access be restricted by role?
Yes, once roles and permitted actions are defined. Sensitive data also requires explicit access and audit acceptance cases.
Can the CRM receive website forms?
Yes, with agreed validation, duplicate handling, legal basis and a visible failure path for the connection.
CRM development shaped around customer data, roles and real work.
Briefly describe the goal, users, current solution and required functions. The first conversation will clarify the open questions and what discovery is needed before an estimate.