CRMS: Crisis & Resilience Management System
Coordinate crisis support
without losing sight of the person,
the decision or the outcome.
Request → DecisionSupport
An InteliSense solution on Microsoft business applications, connecting requests, assessment, governed decisions, funding, partner working, evidence and reporting for crisis, hardship and community support services.
Urgent support still needs governance.
In short
Fragmented crisis and support services are hard to coordinate, govern and fund.
CRMS connects requests, assessment, cases, support, funding, partners, communication, evidence and reporting so the service can explain itself while it is still running.
What the service can then answer
- Who needs support
- What has been assessed
- What was decided, and why
- Who owns the next action
- What support or funding was committed
- Which partner is involved
- What evidence exists
- What is outstanding
- What happened in the end
Typically relevant to
- Local authorities
- Public-sector service teams
- Community support programmes
- Crisis and hardship fund services
- Charities and not-for-profits
- Housing and support organisations
- Health and community organisations
- Multi-agency services
Not every case-based service needs CRMS, and we will say so where a lighter Microsoft solution would serve you better.
The operating reality
The request may be simple. The journey rarely is.
When assessment, evidence, eligibility, funding, approval, communication, partner activity and reporting sit across email, spreadsheets, shared drives and different systems, fragmentation creates work nobody intended.
Most of this work is invisible in a business case, but it is felt every day by the people delivering the service.
Repeated information
The same details are captured or checked more than once.
Manual chasing
People spend time finding status, evidence or ownership.
Unclear ownership
It becomes difficult to see who is responsible for the next action.
Slower decisions
Approvals can wait because information is incomplete or dispersed.
Partner blind spots
The complete support journey may extend beyond one organisation.
Reporting after the fact
Teams rebuild operational information manually for management reporting.
Limited outcome visibility
It can be easier to see activity than understand what support was provided and what happened next.
The CRMS service model
One connected journey from request to outcome.
A structured operating model around the request, keeping the people, organisations, evidence, decisions and actions connected to it.
Request
Capture the request or referral consistently.
Assess
Bring together the information needed to understand need and eligibility.
Decide
Record accountable support or funding decisions.
Support
Coordinate the agreed intervention or assistance.
Coordinate
Connect internal teams and external partners around the case.
Review
Maintain visibility of progress, actions, risk and outcome.
Learn
Use operational information to understand demand, performance and outcomes.
Five control layers
Person
The individual, household or organisation the service is supporting.
Case
The work, the ownership and the next action.
Funding
What was committed, on what authority and what was provided.
Partner
Who else is delivering part of the support, and what came back.
Evidence
What the service relied on, and can explain later.
What CRMS is, and what it is not
The operating model is broader than any one implementation.
The first release contains only what has been qualified for the service being delivered. Everything else stays a later decision rather than an assumed inclusion.
01
CRMS operating model
The broader service model CRMS can support: requests, assessment, eligibility, cases, funding, partners, safeguarding context, communication, evidence, reporting and workflow.
02
Qualified first release
Only the services, processes, data, integrations, users, reporting and controls explicitly agreed for the service being delivered.
03
Later phase, further qualification
Wider programmes, partner portals, advanced integration, extensive migration, additional services or funding schemes, advanced analytics and AI assistance.
Inside the CRMS proposition
- Requests and referrals
- Assessment and eligibility
- Casework and ownership
- Support and funding decisions
- Partner referral and outcome
- Safeguarding and risk context
- Communication and evidence
- Service reporting
Not part of the CRMS proposition
- Emergency preparedness planning
- Incident command
- Situation reporting
- Business continuity management
- Resource and exercise management
- Mass emergency communications
The name can suggest emergency planning and business continuity. CRMS is a crisis-support and community-resilience operating model, and we would rather be clear about that than let a procurement discover it later.
What you are buying
CRMS is an InteliSense solution built on Microsoft business applications and configured against your service operating model. The applications, integrations, scope and commercial arrangement are qualified for each organisation, so this page deliberately makes no claim about standard modules, licence requirements, prices, delivery durations, support entitlements or roadmap. Those belong in a qualified proposal, not in marketing copy.
The front door
How a request reaches the service decides how well the service runs.
Request and referral routes are designed for the service rather than switched on wholesale. Very few implementations use all of them.
- Online self-service
- Staff-assisted application
- Telephone
- Internal referral
- Partner referral
- External form
- Power Pages where external interaction is required
- System integration or import where justified
Accessibility
The front door has to work for the people least able to use it.
Assisted digital
Staff and partners capturing on behalf of someone else.
Service eligibility
Routing a request to the service that can actually help.
Channel choice
Different routes into the same governed process.
Identity requirements
What the service needs to know, and what it does not.
Duplicate detection
Where the same request arrives twice, and it matters.
Referral ownership
Who holds the request from the moment it arrives.
Acknowledgement
The person knows the request has landed.
Next action
Nothing waits in a queue nobody owns.
Identity checking, verification and duplicate handling are qualified against the service and its policy. We do not claim identity-verification capability that has not been designed for your requirement.
Assessment, eligibility and casework
Structure where it helps, judgement where it matters.
Controlled assessment is more than a form. It is the evidence a service relies on when it has to explain a decision months later.
What a governed assessment may capture
- Need
- Circumstances
- Vulnerability context
- Evidence
- Eligibility
- Service criteria
- Risk
- Previous support where appropriate
- Decision
- Rationale
- Exception
- Reviewer or approver
When policy changes
Schemes and criteria move. Where that matters, the design can qualify:
- Rule or criteria version
- Effective date
- Decision date
- Policy context at the time
Technology can structure the evidence and the workflow. Accountable decision-making remains governed by the organisation.
Capability in service terms
Open the areas that matter to your service. Capability is configured to the operating model rather than switched on wholesale.
- Request capture
- Referral capture
- Source and channel
- Contact details
- Reason for request
- Initial need
- Supporting information and documents
- Consent and declarations where configured
- Priority
- Routing and acknowledgement
Case view
See the context around the request.
Where appropriate, authorised users can understand the information connected to the person, household or organisation and their support journey. Access always remains role appropriate, and this is not a claim to a single view of everything.
- Contact information
- Current request
- Previous relevant requests
- Needs and circumstances
- Evidence
- Interactions
- Support history
- Partner involvement
- Actions
- Decisions
- Documents
Funding governance
Understand commitments before reporting catches up.
CRMS is not a financial ledger. It governs the chain of decision and commitment behind the numbers, while the finance system remains the record of transaction.
01
Programme
The scheme the support is funded from.
02
Fund
The pot, its budget and its rules.
03
Assessment
The evidence and eligibility position.
04
Decision
The accountable approval, with reason.
05
Commitment
What the service has committed to provide.
06
Provision
What was actually provided or paid.
07
Reconciliation
How that reconciles with the finance system.
08
Outcome
What the support achieved.
What funding qualification may cover
- Programme
- Scheme
- Fund or pot
- Available budget
- Eligibility rules
- Effective dates
- Delegated authority
- Approval level
- Decision reason
- Evidence
- Exceptions and overrides
- Committed amount
- Approved amount
- Provided or paid amount
- Payment or support status
- Finance-system reference
- Reconciliation
- Outcome
Not every implementation needs all of this, and none of it makes CRMS a finance system. The architecture decides how CRMS and finance interact, and which one is authoritative for each value.
Working across boundaries
The service does not stop at the boundary of one organisation.
Crisis and community support may involve charities, community organisations, advice services, housing organisations, health partners, food and financial support, and other commissioned or voluntary-sector partners.
Refer
Who initiated the referral, and on what basis.
Accept
Whether the partner accepted it, and when.
Deliver
Who currently owns the action.
Update
What the partner may see, and what they may update.
Outcome
Whether support was delivered, and what came back.
Close the loop
The originating organisation retains accountability.
Coordinating partner activity
- Partner directory
- Referral
- Assignment
- Handover
- Status
- Communication
- Evidence
- Service provided
- Outcome
- Escalation
Partner involvement does not imply system access, and a partner portal is not included unless it is in qualified scope. What each organisation can see or update is a design decision, and exceptions escalate back to the accountable organisation.
Know who is helping, where and with what.
Partner organisations
Services offered
Areas covered
Referral activity
Open referrals
Support delivered
Capacity where captured
Outcomes where captured
Funding relationships where relevant
Information governance
Designed around your approved governance, not a generic configuration.
CRMS should be designed around the organisation's approved information-governance, access, retention and sharing requirements. These are qualified during design rather than assumed.
- Data minimisation
- Purpose of collection
- Sensitive information
- Access by role
- Need to know
- Document and evidence access
- Audit trail
- Data retention
- Deletion or anonymisation where required
- Information sharing
- External partner access
- Consent where applicable
- Lawful basis considerations
- DPIA considerations
- Information-sharing agreements
We are not your legal advisers, and no system automatically provides data protection compliance. Lawful basis, DPIA outcomes and information-sharing agreements remain the organisation's decisions, supported by the design work we do together.
Human accountability
High-impact eligibility, funding, safeguarding and exception decisions remain under accountable human control, with automation used only where policy and governance permit it.
CRMS supports statutory safeguarding procedures. It does not replace them.
What the technology does instead
- Surfacing relevant information
- Highlighting missing information
- Routing tasks
- Prioritising work against approved rules
- Presenting history
- Creating reminders
- Supporting professional review
Four different things, often confused
Most of what a service needs is rules, workflow and reporting. AI is the smallest layer, not the headline.
Rules
Mandatory fields, threshold checks, required evidence, status rules and approved eligibility workflow logic.
Workflow and automation
Assignment, reminders, approvals, service-level timers, follow-up, escalation and notifications.
Reporting and analytics
Caseload, ageing, demand, funding, partner referrals, service performance, exceptions and trends.
AI assistance
Summarising case history, retrieving knowledge, drafting routine communications, preparing briefings and surfacing patterns for human review.
Where AI assistance can help
- Summarise case information
- Identify missing information
- Find relevant records
- Draft routine correspondence
- Summarise interaction history
- Highlight ageing cases
- Surface potential exceptions
- Support reporting
- Help users navigate knowledge
Capability comes from standard Microsoft AI where it is supported and governed, or from configured CRMS automation. We do not claim a bespoke InteliSense model where none exists.
What AI does not do
- Decide vulnerability
- Approve funding
- Determine safeguarding action
- Override policy
- Make a final high-impact decision
Operational visibility
See what is happening across the service.
Questions like these should be answerable from the work itself, with Power BI applied where richer analysis is required.
How many requests are open?
Where is demand increasing?
What types of support are being requested?
Where are assessments waiting?
Which decisions are pending?
Where is evidence incomplete?
Which partners are involved?
Where are referrals waiting?
What support has been committed?
Where are cases ageing?
Where is workload concentrated?
- Demand
- Request type
- Assessment
- Eligibility
- Decision
- Support
- Partner activity
- Funding
- Service levels
- Case ageing
- Geography
- Outcomes
- Exceptions
A clearer service depends on information people can trust.
If important information only exists in inboxes and spreadsheets, leadership visibility will always be harder than it needs to be.
Data
Information designed to be used.
Structured data
Capture information in a form the service can use and report.
Consistent definitions
Agree what a request, decision and outcome mean.
Role-based access
Make information available according to responsibility.
Ownership
Keep the quality and meaning of information owned by the service.
Auditability
Retain visibility of important activity and decisions.
Reporting from operations
Let management information come from the work rather than a manual rebuild.
Microsoft architecture
Assembled from the Microsoft applications the service needs.
CRMS is a Microsoft business-application solution. The components below are selected during design, and no implementation contains all of them.
Microsoft Dataverse
A governed home for service data, security and logic.
Dynamics 365 Customer Service
Where a structured case, queue and resolution model fits the service.
Power Apps
Focused applications shaped around how the service actually works.
Power Automate
Routine coordination handled consistently.
Power Pages
Where external self-service or partner interaction is required.
Power BI
Service, funding and leadership reporting.
Microsoft 365
Familiar collaboration, documents and communication.
Azure services
Applied where integration or scale genuinely requires it.
Microsoft AI and Copilot capability
Where it is supported, governed and appropriate for the service.
Architecture is selected against
- Users
- Case model
- External access
- Data
- Workflow
- Reporting
- Security
- Integration
- Licensing
- Scale
Licensing depends on the applications, users and access model finally agreed. We qualify it with you rather than publish guidance that may not apply.
Role-based experience
Different users need different views of the same service.
Each role should see the work and information relevant to its responsibility.
Capture requests quickly and see what information is still needed.
CRMS fit assessment
Answer a few questions and get a likely direction.
Service-level questions only. Please do not include personal, case or safeguarding information about the people your service supports. The result is indicative rather than a solution decision, and CRMS is not always the right answer.
Indicative signal
Answer the questions and we will show a likely direction. This is an indication rather than a solution decision, and CRMS is not always the right answer. Please keep every answer at service level: do not include personal or sensitive case information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Routes
CRMS is one answer. It is not always the right one.
The starting point depends on what is actually true today rather than on which solution we would prefer to sell.
Transform
Where the future service or operating model still needs to be defined before any solution is selected.
Explore TransformRecover
Where an existing case-management, Dynamics or Power Platform programme is stalled, unstable, over budget, poorly adopted, heavily customised, data-poor or no longer trusted.
Explore RecoverOptimise
Where the platform is live and stable but workflow, reporting, funding control, partner coordination, data quality, automation or adoption need to improve.
Explore OptimiseA lighter CRM or Power Platform solution
Where the requirement is a contained case process, contact and relationship process, workflow or focused application, CRMS would add governance the service does not need.
Explore Power Platform
Looking for clinical and care-service management instead?
Explore CMS, our Clinical Management SystemHow delivery is controlled
Start with the service, not the software.
Every service is different, so this describes the discipline rather than a fixed duration. Not every stage carries the same weight in every implementation.
Understand
Map the real service journey, organisations, roles and decisions.
Design
Define the future workflow, information and responsibility model.
Validate
Use representative cases with the people who perform the work.
Configure
Build the agreed CRMS solution.
Connect
Integrate the systems the service genuinely depends on.
Migrate
Move the cases, people, funding and reference data that are needed.
Prove
Test end-to-end service scenarios, access, reporting and audit.
Cutover
Move controlled from the current service into CRMS.
Operate
Stabilise, support and take ownership of real service use.
Improve
Use operational experience and data to refine the service.
Confidence gates
Delivery continues at pace only while the conditions for controlled delivery remain true.
Four business decision points, owned jointly. They exist to protect the service, not to generate project paperwork.
Gate 1
Before design
Service and fit
Confirm that the service problem and the operating model are understood well enough to justify designing a solution.
Confirmed at this gate
- Service objective
- Request and case model
- Users
- Assessment
- Eligibility
- Funding
- Partner working
- Safeguarding and risk
- Platform fit
- Broad first-release scope
Decision
Proceed · Narrow the scope · Transform first · Choose a lighter CRM or Power Platform route
Gate 2
Before build
Design and readiness
Confirm that the organisation can support what is about to be built, and that governance is settled rather than assumed.
Confirmed at this gate
- Process owners
- Data owners
- Data availability
- Information governance
- Security and access
- Partner model
- Funding model
- Integrations
- Environments
- Business users
- Decision availability
Decision
Proceed · Resolve readiness · Re-scope · Pause
Gate 3
Before go-live planning
Prove
Confirm the service works end to end against real scenarios, within the qualified scope, rather than against the build plan.
Confirmed at this gate
- Request and referral
- Assessment
- Case ownership
- Funding
- Partner referrals
- Communication
- Safeguarding and risk controls
- Data
- Security
- Integrations
- Reporting
- Audit
- User acceptance
Decision
Proceed · Remediate · Re-plan
Gate 4
Before go-live
Go-live
A shared business decision on whether the service is ready to run in CRMS, taken by the people accountable for it.
Confirmed at this gate
- Production readiness
- Users and access
- Migrated and open cases
- Funding position where relevant
- Forms and front door
- Integrations
- Reporting
- Partner process
- Support model
- Business ownership
- Material open risks
Decision
Go · No-go · Controlled deferral
What we prove in a CRMS walkthrough
The operating model, shown as your service would run it.
A walkthrough follows a realistic scenario using synthetic data, built around your process rather than a generic feature demo. No real case information is used.
01
A request enters the service
Through the channel the service actually uses.
02
The case is assessed
Structured need, eligibility and evidence in one process.
03
Evidence is reviewed
What is present, what is missing, what is required.
04
A funding decision is governed
Recommendation, authority, reason and approval level.
05
A partner referral is tracked
Referred, accepted, delivered, outcome returned.
06
Communication is recorded
Against the case rather than in a personal inbox.
07
Risk context is surfaced appropriately
To the people whose role permits it.
08
Support is delivered
And what was provided is visible.
09
The outcome is captured
So the service can explain what happened.
10
Management sees the service
Demand, funding position and exceptions, from the work itself.
Accountability
Understand what happened, who acted and why.
Activity across the case can be recorded so the service can explain its own decisions later, to leadership, to auditors and to the people it supports.
- Request created
- Information changed
- Assessment completed
- Decision recorded
- Approval
- Referral
- Support committed
- Communication
- Case status
- Closure
Clear boundaries matter.
CRMS is not a replacement for professional judgement.
CRMS is not an autonomous eligibility engine.
CRMS is not an autonomous safeguarding decision-maker.
CRMS is not an emergency preparedness or incident-command platform.
CRMS is not a complete local-authority ERP.
CRMS is not a financial ledger.
CRMS is not a replacement for every specialist system.
CRMS is not a reason to move every historic record into one database.
The purpose is to connect the service processes and information that need to work together.
CRMS should fit into the wider service environment.
Integration is treated as a design decision rather than a standard inclusion. Each of these areas is potential, where required and subject to solution design.
- Finance
- Identity
- Document services
- Existing case systems
- GIS
- Partner systems
- Payment services
- Data platforms
- Other Microsoft systems
What happens after go-live
The first release is where operational learning starts.
Improvement is based on what the service actually experiences. None of it is an automatic commitment, and expansion should be justified by evidence rather than assumed.
Operate
Run the service reliably, with clear ownership.
Stabilise and support
Resolve issues and settle the first release.
Optimise
Improve workflow, data quality, reporting and adoption.
Expand
Extend where the evidence justifies it, not automatically.
Where later value usually comes from
- Additional services
- Additional funding programmes
- Additional partners
- New intake routes
- Automation
- Reporting
- Data improvement
- Integration
- AI assistance
- Self-service
- Wider organisation rollout
Evidence
General customer evidence, and what it does and does not prove.
These videos are customers describing what it is like to work with InteliSense on Microsoft business applications. None of them is CRMS, local-authority crisis support, public-sector funding, safeguarding or multi-agency evidence, and none should be read as proof of a CRMS outcome.
Customer voice
What customers say about working with us.
Customer voices
InteliSense customers
Hear our customers talk about InteliSense
How we work
Complex services need clarity before configuration.
Understand the service
Start with how the work actually happens today.
Map the decisions
Identify who decides what, and on what evidence.
Connect the information
Design where information lives and how it moves.
Involve users early
Validate with the people performing the service.
Make accountability visible
Keep ownership and decisions traceable.
Use standard Microsoft capability where it fits
Avoid complexity that adds no service value.
Prove with real scenarios
Test the service, not only the software.
Improve after go-live
Treat the first release as operational learning.
Common questions
Questions about CRMS.
Start with the service
Where is crisis and community support becoming harder to coordinate?
Show us where requests, assessment, partners, decisions or reporting are creating friction. We will help determine whether CRMS, a lighter Microsoft solution or a different route fits the problem. Please keep the conversation at service level rather than case level.