Delivering a CRM or CMS as part of a service
To deliver a CRM or CMS, you need to create a good set of requirements. To do this, it’s important to:
- know who your users are – user research will help with this
- define the outcomes your project must deliver by writing a business case
- map your service through service design or blueprinting
- understand any statutory or policy obligations, such as requirements for records management or data retention
- estimate the volume and types of interactions your service will manage, for example high‑volume enquiries or time‑bound casework
- identify legislative requirements, such as compliance with data protection law
- define your security and data requirements, including how data will be stored, processed and protected
- make sure your project meets digital standards
- understand how the system will integrate with existing tools, considering any technical or organisational constraints
Starter set of CRM and CMS requirements
You might find these starter sets of CRM and CMS requirements useful. They are intended as a starting point and are not exhaustive.
Starter set of CRM requirements
User and contact management
A CRM should be able to:
- store and update user contact details
- record multiple contacts for the same organisation or household
- support different user types (for example: service users, partners, stakeholders)
- track changes to user information over time
- allow users to be linked to cases, enquiries or interactions
Interaction and communication tracking
A CRM should be able to:
- record all inbound and outbound interactions (email, phone, chat, letter, in‑person)
- store notes or summaries of calls and meetings
- attach relevant documents to an interaction record
- view a complete interaction history for each user
- support reminders, follow‑ups and task assignment
Segmentation and analysis
A CRM should be able to:
- group users by attributes such as location, service need or behaviour
- generate simple dashboards and reports
- provide basic analytics on user cohorts, volumes and trends
- export data securely for analytical purposes
- support monitoring against KPIs or service‑level measures
Workflow and task management
A CRM should be able to:
- create and assign tasks to staff or teams
- set due dates, alerts and escalations
- track progress on tasks or follow‑ups
- support simple workflows for triage, enquiries or escalation paths
- help teams manage workload and priorities
Data quality, consistency and governance
A CRM should:
- validate new records to prevent duplicates
- allow controlled editing or merging of records
- support audit logs showing who changed what and when
- apply data‑retention rules (for example, archiving or deletion)
- comply with information‑governance and data‑protection requirements
Integration with other systems
A CRM may need to integrate with:
- email systems
- document‑management tools
- identity or authentication services
- finance or payment systems
- case‑management systems (if separate)
- reporting tools or data warehouses
Integrations should be secure, standards‑based and maintainable.
User access and permissions
A CRM should:
- support role‑based access (for example: administrator, team manager, staff)
- ensure staff only see information relevant to their role
- support multi‑team or cross‑organisational access where required
- provide an audit trail of access and permission changes
Security and compliance
A CRM should:
- store data in line with organisational security policies
- comply with UK GDPR and data‑protection legislation
- support secure cloud environments, if cloud‑hosted
- encrypt data in transit and at rest
- provide incident logging and access monitoring
Usability and accessibility
A CRM should:
- be usable with minimal training
- support accessibility standards (for example WCAG 2.2)
- work across devices and assistive technologies
- provide clear, simple interfaces for staff
Configuration and flexibility
A CRM should:
- allow administrators to configure fields, forms and workflows
- support adding new user attributes or communication types
- adapt to new processes without needing custom development
- allow changes without breaking upgrades or security patches
Scalability and performance
A CRM should:
- handle increases in user numbers or interaction volumes
- support growth without performance issues
- work reliably during peak demand
Supplier support and sustainability
If you are buying a CRM, it should offer:
- clear service‑level agreements (SLAs)
- ongoing support and maintenance
- regular security updates and patches
- a roadmap for future product development
Starter set of CMS requirements
Case creation and management
A CMS should be able to:
- create cases with unique identifiers
- store structured information about each case
- support multiple case types (for example: applications, complaints, inspections, assessments)
- link cases to individual users, households or organisations
- capture case notes, evidence and supporting documents
- track changes to case data over time
Workflow and process management
A CMS should:
- support structured workflows with defined steps or stages
- allow different teams to complete specific actions within a case
- support configurable decision points and branching logic
- enforce mandatory steps or required evidence
- allow caseworkers to see what has been completed and what is outstanding
- provide alerts, reminders and escalation routes
Decision‑making and auditability
A CMS should:
- support simple and complex decision rules
- allow decisions to be recorded with evidence and rationale
- generate an audit trail of every action taken
- retain historical case versions for review or investigation
- support statutory and legislative requirements for records management
- allow supervisor or manager approval where required
Document and evidence handling
A CMS should be able to:
- upload and store supporting documents, evidence and forms
- link documents to specific steps or decisions
- integrate with document‑management systems where needed
- apply retention and deletion schedules in line with policy
- support secure storage of sensitive documents
User, team and partner access
A CMS should:
- support role‑based access for caseworkers, managers and administrators
- allow multiple teams or partners to work on the same case
- restrict access to sensitive information where required
- support delegation or reassignment of cases
- provide visibility of workloads across teams
Reporting and performance monitoring
A CMS should:
- support dashboards for open cases, progress, bottlenecks and outcomes
- provide filters for case type, status, geography or user group
- support statutory reporting requirements (for example, complaints handling KPIs)
- allow export of data in accessible formats
- support operational and strategic reporting without manual workarounds
Data quality, governance and compliance
A CMS should:
- prevent duplicate case creation where appropriate
- support data validation and required fields
- log all edits and access actions
- comply with data‑protection legislation (such as UK GDPR)
- support lawful bases for processing and retention rules
- support disclosure, FOI and subject access requests
Integration with other systems
A CMS may need to integrate with:
- identity verification or authentication services
- payment platforms
- document‑management systems
- scheduling systems (for inspections or appointments)
- CRM systems (if separate)
- master data, case records, or data warehouses
Integrations should be secure, standards‑based and maintainable.
Security and risk management
A CMS should:
- store and process data in line with organisational security policies
- support secure hosting environments (such as approved cloud platforms)
- encrypt data at rest and in transit
- manage access tokens and session timeouts
- support logging and monitoring for security incidents
- handle sensitive or restricted information appropriately
Accessibility, usability and user experience
A CMS should:
- be usable with minimal training
- support accessibility standards (for example WCAG 2.2)
- present clear interfaces for caseworkers working under time pressure
- reduce duplication of data entry
- support assisted digital and reasonable adjustments where needed
Configuration and flexibility
A CMS should:
- allow administrators to configure case types, workflows and forms
- enable quick updates when processes, legislation or policy change
- support adding new fields, steps or decision rules
- allow configuration without heavy bespoke development
- avoid breaking upgrades or patches when changes are made
Scalability and resilience
A CMS should:
- support increases in case volume or new service areas
- work reliably during peak demand (for example deadlines or seasonal surges)
- support load balancing and resilience where required
- allow easy onboarding of new users or teams
Support, sustainability and long‑term viability
If you are buying a CMS, it should offer:
- clear support and maintenance arrangements
- defined service‑level agreements
- regular updates that improve security and functionality
- a transparent product roadmap
- sustainable long‑term viability
If you are building or extending an in‑house CMS, you will need capacity to maintain it over the system’s whole life cycle.
Conceptual architecture
The conceptual architecture of a CRM or CMS is a high-level map showing the main parts of the system and how they fit together. It's similar to the floorplan of a house or the structure of a service. It helps you see the big picture of how a CRM or CMS works without needing technical detail.
Understanding the conceptual architecture is important because it can help you:
- write clearer and more structured requirements
- avoid common procurement mistakes
- ask better, more targeted questions of suppliers
- give teams a shared understanding to support decision-making
- plan for future changes, growth and integration needs
The following resources provide examples of high‑level architecture and integration patterns that can help teams understand how CRM and CMS systems fit within a wider service ecosystem.
- GOV.UK publishing architecture overview – a clear example of a conceptual architecture diagram showing how frontend applications, APIs and supporting systems interact
- CRM integration architecture and methods – an accessible overview of how CRMs typically connect with other systems, including common integration layers and data‑flow patterns
- Scaling CRM in the public sector – a public‑sector‑focused explanation of how CRM platforms support citizen interaction, and how cloud‑based architectures help integrate systems
These examples are not templates to copy, but they can help teams visualise the relationships between components, integrations and data flows in a typical CRM or CMS setup.
Data protection and cyber security
If you’re delivering a CRM or CMS, this delivery must meet:
- UK General Data Protection Regulation and Data Protection Act 2018
- National Cyber Security Centre guidance
- cyber security and data criteria of the Digital Scotland Service Standard
To meet data protection standards, you should:
- conduct a Data Protection Impact Assessment (DPIA)
- document your lawful basis for processing – the Information Commissioner’s Office (ICO) has an interactive tool to help you do this
- follow guidance from the ICO on ensuring data minimisation and defining retention and deletion policies
- ensure users know how their data is used by developing consent and privacy notices – the ICO has information on how to obtain, record and manage consent and a privacy notice generator tool
- plan for Subject Access Requests (SARs) by users
To meet cyber security standards, you should consider hiring a technical architect or security architect to help:
- implement multi-factor authentication
- enforce role-based access controls
- encrypt data at rest and in transit
- conduct penetration testing
- plan for incident response
- review supplier security documentation and certifications (for example, ISO 27001)
- ensure the product meets your organisation’s security policy
To get specific help with cyber security, you can contact the Scottish Government Cyber Security Unit.