Public sector
Help public services see,
coordinate and act with confidence.
FragmentedConnected
For local authorities, public-service teams, funding programmes, partnerships and corporate functions coordinating requests, referrals, cases, partners, funding, finance and reporting. Public Sector is not one operating model, so this page qualifies the service problem before it suggests any technology.
Start with the service problem, then design the technology around it.
In short
What a public-service leader should take from this page.
Eleven points. If you read nothing else, these decide which route is worth a conversation.
01
Public Sector is not one operating model
A council, a delivery team, a funding programme, a partnership, a care service and a corporate back office face different problems.
02
Start with the service problem
Start with the service problem, then design the technology around it.
03
CRMS is one qualified route
CRMS is a purpose-built solution for crisis, hardship and community-resilience support. It is not the whole Public Sector proposition.
04
Care routes through Healthcare & Care
Healthcare & Care is the canonical route for care-service requirements, with CMS qualified only where the operating model fits.
05
CRM, Power Platform, ERP, Data and Integration are all valid
A standard route is often the more proportionate answer than a purpose-built solution.
06
Each information domain needs an owner
Connected services require clear ownership of information, not one database containing everything.
07
Cross-agency access must be designed
Cross-organisational working is an information-sharing design problem before it is a portal decision.
08
The commercial route follows the situation
Assessment, Transform, implementation, RAPID qualification, Recover, Optimise, Support and Partner Transition answer different starting points.
09
Go-live is proven, not asserted
Four confidence gates test service, platform, end-to-end proof and operational readiness.
10
The organisation stays accountable
We can implement an approved operating model. The organisation remains accountable for the service, statutory, funding and governance decisions behind it.
11
Evidence is stated honestly
No published customer video is centrally verified as Public Sector evidence today.
The operating reality
Public-service teams can be constrained by fragmented information, ownership and processes even when people are working hard to deliver the service.
The difficulty is often giving those people a complete enough view to coordinate the work around them.
Technology may be only one part of the problem. Fragmented process, information, ownership and partner working can matter just as much.
Information is fragmented
Important information can sit across systems, spreadsheets, documents and inboxes.
Work crosses organisations
Councils, providers, charities, clinical teams and community partners may all contribute to the same outcome.
Decisions have consequences
Funding, referrals, safeguarding, incidents and service capacity require accountability.
Administration consumes capacity
Repeated entry, chasing information and manual reporting take time away from higher-value work.
Leadership needs visibility
Operational problems are difficult to manage when the information needed to understand them arrives late.
The goal is not another system. It is a clearer way to operate.
Technology creates value when it improves how information moves, how work is coordinated and how decisions are understood. Our public-sector approach starts with the operating problem before deciding what technology should do. Designed around the work, not around the software.
Operating archetypes
Which kind of public organisation or service is this?
These are orientation categories rather than packaged products. Not every public organisation operates identically, and the archetype decides which parts of this page matter.
Local authority or council
Resident and customer interaction, service requests, referrals, cases, partners, funding, finance, data and reporting under one accountability structure.
Public-service delivery team
A specific service with its own demand, ownership, decisions and outcome expectations, often inside a larger organisation.
Commissioning or funding programme
Money, programme conditions, providers and evidence coordinated across organisations that the commissioner does not operate.
Multi-agency or community partnership
Several organisations contributing to one outcome, where information sharing and ownership matter more than any single system.
Public-sector care service
A care operating model, which routes to Healthcare & Care before any CMS qualification.
Corporate or back-office public sector
Finance, procurement, supplier, project and management reporting requirements rather than front-line service work.
Other
Public organisations vary. Housing, public bodies and hybrid arrangements each change the operating question.
Not sure
Where the model is genuinely mixed, orientation is a more honest first step than a proposal.
Relevance and limits
The proposition is relevant to councils, local authorities and other public-service organisations managing resident and customer interaction, service requests, referrals, cases, partners, funding, finance, data, reporting and operational improvement. We do not imply broader central-government experience.
- No council or local-government customer evidence is claimed
- No Public Sector customer outcomes are claimed
- No statutory or accessibility compliance is claimed
- No public-sector certification is claimed
- No NHS capability is claimed
- No emergency-planning or business-continuity capability is claimed
- No CRMS or CMS customer outcomes are claimed
- No implementation duration is promised
Where we help
Start with the problem, not the product.
Ten starting points. Each one leads somewhere different, and none of them selects technology automatically.
Resident or customer service
Contact, request, routing, service and resolution across the channels the organisation actually operates.
Potentially Dynamics 365 CRM or Customer Service.
Explore CRMGeneral case or workflow
Work that needs ownership over time, with stages, actions, evidence and an audit trail.
Potentially Dynamics 365 CRM or Power Platform.
Explore Power PlatformCrisis or community support
Requests, assessment, eligibility, funding, partner working and evidence for hardship and community-resilience services.
CRMS qualification.
Explore CRMSCare service
Care coordination around referral, assessment, planning, incidents and capacity.
Route first to Healthcare & Care, then CMS qualification where appropriate.
Explore Healthcare & CareFinance or corporate operations
Ledger, payables, receivables, cash, budget, procurement, project, supplier and management reporting.
ERP qualification between Business Central and Dynamics 365 Finance.
See the ERP qualificationData or reporting
Definitions, data quality, demand and performance reporting derived from a governed model.
Power BI and Microsoft Fabric.
Explore Power BI & FabricIntegration
Connecting service, finance, identity, document, partner and specialist systems deliberately.
Approved integration architecture.
Explore IntegrationExisting programme in trouble
An implementation that has lost confidence or control.
Recover.
Explore RecoverLive platform needing improvement
A working platform that still contains worthwhile friction.
Optimise.
Explore Optimise
Resident and customer service
How a person or organisation reaches a service.
A general public-service interaction model. Not every contact should become a case, and forcing one is how services acquire administration they never needed.
Contact
An interaction with the service, through whichever route the person or organisation used.
Request
Something the person or organisation needs from the service, captured once.
Route
The request reaches the team, service or partner that should own it.
Service
The service responds within its own defined process and commitments.
Case where required
A managed unit of work is created only where ownership over time is genuinely needed.
Action
The work moves forward, with the owner and next action visible.
Communication
The person, organisation or partner is kept informed through an agreed route.
Resolution or outcome
The result is recorded in the organisation's own terms, with the evidence it defines.
Requests, referrals and cases
Four different things, often called the same thing.
The distinction decides how much process the service has to carry and where ownership genuinely sits.
Contact
An interaction. It does not automatically become anything else.
Request
Something the person or organisation needs from the service.
Case
A managed unit of work requiring ownership over time.
Referral
A request or transfer involving another service or organisation.
CRM route
Not every case-based service needs a purpose-built solution.
A standard Dynamics 365 or Power Platform route may be the more proportionate answer, and it is often faster to govern and cheaper to support.
Potential public-sector CRM areas
- People and organisations
- Resident or customer relationship
- Request
- Case
- Queue
- Complaint
- Communication
- Service
- Knowledge
- Partner relationship
Power Platform route
Use Power Platform where a focused service process needs structure.
Do not create an unmanaged application estate simply because low-code makes building easy. Each app still needs an owner, a lifecycle and a support position.
Potential focused processes
- Forms
- Workflow
- Approvals
- Internal service apps
- Inspection
- Case extensions
- Partner forms
- Automation
CRMS
Crisis & Resilience Management System.
CRMS remains our principal purpose-built Public Sector solution, for crisis support, hardship support and community resilience. It is one qualified route, not the whole proposition.
The boundary, stated up front
CRMS is focused on crisis support, hardship and community-resilience services. It is not currently positioned as an emergency-planning, incident-command or business-continuity platform.
The name can imply wider emergency-management capability, so we say this before procurement rather than during it. The dedicated CRMS page remains canonical for the full boundary.
What CRMS coordinates
- Request and referral management
- Assessment and eligibility
- Case coordination
- Partner working
- Funding and support decisions
- Evidence and documentation
- Approvals
- Communication
- Operational visibility
- Reporting and audit trail
Public-sector care services
Care requirements route through Healthcare & Care first.
Public Sector may reference CMS, but it does not own the proposition. Healthcare & Care is the canonical parent route for care-service requirements.
- 01Public-sector care service
- 02Healthcare & Care
- 03CMS qualification where the operating model fits
CMS supports care-service coordination around referral, assessment, care and service information, planning, incidents, safeguarding workflow, capacity, family and representative communication and operational reporting, while specialist clinical systems retain authority where appropriate.
Corporate and finance
ERP fit follows the financial and operating model, not the fact that the organisation is public sector.
Front-line service work is only part of the picture. Corporate and back-office requirements deserve their own qualification.
Potential requirements
- General ledger
- Accounts payable
- Accounts receivable
- Cash
- Budget
- Procurement
- Project
- Supplier
- Management reporting
Business Central
Potential fit where the combined operating and finance requirement fits responsibly within the platform, including ledger, payables, receivables, cash, budget, procurement and management reporting.
Explore Business CentralDynamics 365 Finance
Potential fit where deeper enterprise, entity, control or financial complexity warrants it, including multiple entities, segregation of duties and broader enterprise integration.
Explore Finance & Supply ChainWe do not claim local-government-specific finance functionality unless it has been verified.
Funding and finance
A service platform may record why support was approved and what was committed.
The finance system remains authoritative for the accounting transaction where appropriate. Separating the two keeps both records honest.
The service or case system may hold
- Service decision
- Reason for the decision
- Commitment
- Programme or fund context
- Supporting evidence
The finance system may hold
- Accounting transaction
- Payment
- Ledger position
- Financial actual
Commissioning and funding models
Where money, programme and provider are different organisations.
Where relevant, the chain runs from commissioner to outcome. We do not imply procurement, grant or contract-management functionality unless it has been verified.
Commissioner
The organisation accountable for the service being available and funded.
Programme
The funded programme, its conditions and its reporting expectations.
Provider or partner
The organisation actually delivering part of the service.
Service
The activity people receive, however it is arranged.
Funding or commitment
What has been approved and committed, and on what basis.
Evidence
The information the programme requires to support the commitment.
Outcome and reporting
The outcome definitions the organisation has set, reported from the record.
Partner working
Public outcomes often cross organisational boundaries.
Cross-organisational working is an information-sharing design problem before it is a portal decision. Four interaction patterns, chosen deliberately.
No direct access
Controlled communication and documents, with no partner login into the service platform.
Form or portal
Purpose-specific structured external interaction, scoped to the information the process genuinely needs.
Direct application access
Only where identity, security, licensing and operational need justify it.
System-to-system integration
Where the partner already has an operational platform of their own.
What each partner relationship has to settle
- Referral
- Handover
- Ownership
- Evidence
- Communication
- Funding
- Escalation
- Reporting
Information minimisation
Only bring information into the service platform where there is a defined operational purpose.
A nine-point test for each important piece of information. It is quicker than removing the information later.
- 01Purpose
- 02Owner
- 03Source
- 04Minimum information
- 05Access
- 06Update authority
- 07Sharing
- 08Retention
- 09Audit
Especially important for
- Vulnerability
- Safeguarding
- Health
- Financial hardship
- Family or household
- Partner information
Safeguarding responsibility
The platform can support an approved safeguarding workflow.
It does not determine what constitutes a safeguarding concern or what statutory action is required.
The organisation owns
- Safeguarding policy
- Thresholds
- Professional decisions
- Escalation
- Statutory process
- External referral
- Information-sharing decisions
The platform may support
- Recording
- Routing
- Ownership
- Escalation
- Evidence
- Status
- Audit
Accessibility and assisted digital
Digital access should not become the only route into a public service simply because a form exists.
Public services may need multiple front doors. The design should reflect the routes the organisation intends to keep.
- Online self-service
- Staff-assisted
- Telephone
- Internal referral
- Partner referral
- Other approved route
We do not claim accessibility compliance unless it has been validated. Detailed intake design for crisis and community support is covered on the CRMS page.
Explore CRMS intake designMicrosoft foundation
Responsibilities first, technology second.
Where Microsoft services are already part of the organisation's approved architecture, business applications can extend that environment while specialist systems remain where they are still required.
Service and case
Dynamics 365 and Power Platform, where a standard route is proportionate.
Explore CRMIntegration
An approved integration architecture across service, finance and specialist systems.
Explore IntegrationCollaboration
Microsoft 365 where collaboration around the work is relevant.
Explore the Microsoft ecosystem
Then the individual technologies
Dynamics 365
Structured service, case and customer processes.
Power Platform
Configurable applications built around the service.
Dataverse
May provide a governed operational data layer for the service processes implemented on the Microsoft platform.
Power Automate
Routine steps handled consistently against approved rules.
Power BI
Operational and leadership reporting from a governed data model.
Microsoft 365
Collaboration around the work where relevant.
Azure services
Applied where integration or scale requires it.
Integration
Every material interface needs eleven answers.
Integration is where connected services succeed or quietly fail. These questions are cheaper to answer before build than after go-live.
Systems that may be involved
- Finance
- Identity
- Case systems
- Care systems
- Workforce
- GIS
- Property or asset
- Documents
- Payments
- Websites and forms
- Partner systems
- Data platforms
Purpose
Why the interface exists, in service terms.
Authority
Which system is authoritative for the information being moved.
Source
Where the information genuinely originates.
Target
Which system consumes it, and for which process.
Data
The minimum information the process needs, not everything available.
Identity
How the same person or organisation is recognised on both sides.
Timing
Real time, scheduled or event driven, agreed against the operational need.
Failure
What happens when the interface does not complete.
Reconciliation
How both sides are proven to agree afterwards.
Monitoring
How a failure becomes visible before a service user reports it.
Support owner
Who is accountable for the interface once it is live.
Service continuity
A public service still needs an operating model when one of its systems is unavailable.
Continuity is an operating design question, not a hosting statistic. We do not publish uptime or recovery targets.
Critical service
The services that must keep operating, in priority order.
Technology dependency
The platforms, integrations and identity services each one relies on.
Failure
What each dependency does when it degrades rather than fails cleanly.
Fallback
The agreed manual or degraded process, and who is authorised to invoke it.
Recovery
How the backlog and queued work are brought back under control.
Reconciliation
How activity during the outage is proven complete afterwards.
Review
What the organisation changes as a result.
Questions worth answering before go-live
- How are requests captured during downtime?
- What information must staff retain access to?
- What happens when an integration fails?
- Can work queue safely?
- How is a partner failure handled?
- How is activity reconciled after restoration?
- Who owns service recovery?
Activity, output and outcome
A closed case is not the same as a public outcome.
The platform can record and report the organisation's defined outcome evidence. It does not prove public value simply because a case reaches closure.
Demand
What is arriving, from where, and at what rate.
Activity
What the service actually did in response.
Output
What was produced or delivered.
Outcome
The change the organisation set out to achieve, defined by the organisation.
Evidence
The information the organisation accepts as proof of that outcome.
Review
What leadership changes as a result.
We do not invent outcome frameworks. The organisation defines what an outcome is and what evidence supports it, and the platform reports against that definition.
Design principles
Designed around the work, not around the software.
Eight principles that hold whichever route the organisation takes.
One operational view
Bring relevant information together around the work being performed.
Structured workflow
Make stages, ownership and next actions visible.
Accountability
Keep important decisions, approvals and activity traceable.
Partner working
Public outcomes often cross organisational boundaries, so design for work that extends beyond one internal team.
Role-based experience
Give people the information relevant to their responsibility.
Reporting from the process
Capture operational information in a structured way so management reporting can be derived from a governed data model rather than reconstructed manually.
Human oversight
Technology supports professional judgement rather than pretending to replace it.
Trusted information
Better decisions start with information people can trust.
Access
Who should be able to see what?
Access is designed around roles and responsibilities rather than assumed from a generic configuration.
Accountability
Can important actions and decisions be understood later?
Decisions, approvals and status changes should remain traceable to a person and a point in time.
Data responsibility
Who owns the quality and meaning of the information?
Ownership of definitions and data quality belongs with the service, supported by the design.
Human decision-making
Where should professional judgement remain central?
High-impact decisions stay with accountable people. The system supports the process around them.
Change control
How are changes introduced without destabilising the service?
Changes are prioritised, tested and released in a way the service can absorb.
Transparency
Can users understand how the process is working?
People should be able to see where work sits, who owns it and what happens next.
Commercial routes
The right route depends on how much is still undecided.
CRMS and CMS are solution and capability routes, not substitutes for the commercial lifecycle. Data & AI is a capability rather than a universal commercial route.
Transform
Where the future service or corporate operating model still needs defining.
Explore TransformStandard implementation
Where operating model and platform are sufficiently understood and conventional governed implementation is appropriate.
Explore ImplementationRAPID qualification
Only where the underlying bounded scope and platform meet the approved strict-fit conditions.
Explore RAPIDPartner Transition
Where the platform can remain but Microsoft partner responsibility needs changing.
Explore Partner Transition
RAPID, strictly qualified
- 01Operating model fit
- 02Platform fit
- 03Delivery fit
A bounded CRM, Power Platform or Business Central requirement may qualify for RAPID where the approved conditions are met. Public Sector, CRMS, CMS or cross-agency complexity does not automatically create RAPID suitability. We do not promise an implementation duration.
Explore RAPIDSupport, Customer Success and Optimise
Support keeps agreed supported capability operating under the contracted service. Customer Success reviews service priorities, value, risk and future decisions. Optimise executes justified improvement. Recovery is used when programme control or confidence has materially deteriorated. No change remains a valid review outcome.
Explore Customer SuccessConfidence gates
Four points where public-service confidence is re-confirmed.
A gate is a decision point rather than a milestone to pass. Each one can confirm the plan, pause it, or reduce scope, and each is evidenced rather than asserted.
Gate 1
Before commitment
Service and responsibility confidence
Before scope is committed, the service and the people accountable for its decisions should be understood well enough to plan responsibly.
Confirmed at this gate
- Organisation and service model
- Service outcome
- Users
- Channels
- Service owner
- Decision owners
- Policy owners
- Safeguarding where relevant
- Funding or commissioning where relevant
- Partners
- Specialist systems
- The problem to solve
Decision
Proceed · Assessment · Transform first · A different route
Gate 2
Before build
Platform, information and governance confidence
Before configuration begins, each capability and each information domain should have an agreed owner, an agreed boundary and an agreed governance position.
Confirmed at this gate
- CRM
- Power Platform
- CRMS
- Healthcare and CMS where relevant
- ERP
- Data authority
- External access
- Information sharing
- Security
- Retention
- Integration
- Migration
- Reporting
- Licensing
- Accessibility
- Continuity
- First-release scope
Decision
Proceed · Re-scope · Retain a specialist system · Resolve readiness
Gate 3
Before go-live decision
End-to-end service proof
A representative service journey should be proven with real data, including the exceptions that occur on a normal working day.
Confirmed at this gate
- Contact or request to assessment where relevant
- Ownership and decision
- Action and partner handoff
- Communication
- Funding or finance where relevant
- Reporting
- Missing information
- Duplicate request
- Access restriction
- Exception handling
- Safeguarding workflow
- Integration failure and downtime
- Audit
Decision
Proceed · Remediate · Re-test
Gate 4
Go-live decision
Operational go-live readiness
The final gate asks whether the service can continue and whether work already in progress keeps its ownership, context and commitments.
Confirmed at this gate
- Active requests
- Referrals
- Cases
- Decisions
- Partner activity
- Funding commitments
- Finance interfaces
- Migrated data
- Front door and forms
- Users and external access
- Integrations
- Reporting
- Continuity
- Support and ownership
- Open risks
Decision
Go · No-go · Controlled deferral
Go-live confidence should come from proving the service can continue through the new operating model, not simply that the technology is configured.
Shared responsibility
Some of this only you can do.
We can implement an approved operating model. The organisation remains accountable for the service, statutory, funding and governance decisions behind it.
The organisation owns
- Service policy
- Statutory interpretation
- Eligibility rules
- Funding rules
- Delegated authority
- Safeguarding policy
- Information-governance decisions
- Lawful sharing decisions
- Retention
- Accessibility requirements
- Finance and accounting treatment
- Service outcomes
- Partner agreements
- Data validation
- User acceptance testing
- Cutover
- Adoption
- Continuity
InteliSense may provide where agreed
- Process design
- Architecture
- Platform qualification
- Configuration
- Development
- Integration
- Migration
- Security configuration
- Testing
- Reporting
- Delivery assurance
- Cutover support
- Risk visibility
Delivery and cutover
Cutover must preserve ownership, context and outstanding commitments for work already in progress.
Twelve delivery stages, and fourteen live positions that need an agreed treatment before the switch. We do not assume one big-bang cutover.
Understand
Map the service, users, information and decision points.
Design
Define the future operating process and information model.
Validate
Use real scenarios with the people who perform the work.
Build
Configure the agreed solution.
Connect
Establish the integrations the service genuinely needs.
Migrate
Move the information the future service requires.
Prove
Test workflow, roles, information, exceptions and reporting.
Prepare
Ready the people, the fallback and the cutover plan.
Cutover
Transfer live work without losing ownership or commitments.
Stabilise
Hold the service steady while the new process settles.
Operate
Run under the agreed support and governance arrangements.
Review
Use operational experience and data to refine the service.
Live state that has to survive the transition
- 01Active requests
- 02Referrals
- 03Cases
- 04Owners
- 05Next actions
- 06Funding commitments
- 07Open decisions
- 08Partner actions
- 09Current documents
- 10Timers and service commitments
- 11Forms
- 12Integrations
- 13Users and access
- 14Reporting
Foundations
The work that decides whether the operating model holds.
Migration, adoption, security and licensing are not administrative afterthoughts. Each has its own page, and each affects whether the service behaves as designed.
Value realisation
Value should be judged by the service outcome or operating burden that changes, not by how many features are configured.
Each outcome runs from baseline to evidence. We do not publish savings or improvement percentages we cannot evidence.
Request administration
- Baseline
- Current effort spent re-keying and chasing information for a single request.
- Operating change
- One capture point per request, with routing rules the service owns.
- Platform capability
- Structured request capture, routing and ownership.
- Adoption
- Front-line and service teams working the same front door.
- Evidence and review
- Observed movement against the baseline, reviewed rather than assumed.
Case ownership and chasing
- Baseline
- Current volume of referral chasing and cases without a clear owner.
- Operating change
- Stages, ownership and next actions defined by the service.
- Platform capability
- Visible ownership, queues and escalation.
- Adoption
- Managers using the record rather than a parallel spreadsheet.
- Evidence and review
- Unresolved work and chasing effort tracked over time.
Decision waiting time
- Baseline
- Current time spent waiting for approvals and decisions to be recorded.
- Operating change
- Delegated authority and approval routes agreed by the organisation.
- Platform capability
- Approval workflow with an audit trail.
- Adoption
- Approvers working in the system where the decision is recorded.
- Evidence and review
- Waiting time observed against the same baseline.
Funding and reporting effort
- Baseline
- Current effort to reconcile funding commitments and produce reporting.
- Operating change
- Service decision and financial transaction separated with clear authority.
- Platform capability
- Commitment recorded in the service platform, actuals in finance, reporting from a governed model.
- Adoption
- Service and finance teams reviewing the same figures.
- Evidence and review
- Reconciliation and reporting effort observed rather than promised.
AI with accountability
Human oversight should follow consequence, delegated authority and the organisation's approved policy.
These are candidate use cases, not claims. AI does not independently determine vulnerability, eligibility, safeguarding, funding or clinical decisions.
01 Retrieve or summarise
AI may assist within approved information boundaries, such as summarising a record or finding relevant information.
02 Draft or prepare
Drafting routine communication or reporting, with human review where required.
03 Administrative routing
Automation may act against approved rules, such as routing an exception to the right queue.
04 Recommend or surface an exception
Preparing information for triage or prioritisation where an accountable person remains responsible for the decision.
05 High-impact decision
Eligibility, funding, safeguarding and clinical decisions remain with accountable human authority.
Lower-risk starting points
- Summarising information
- Helping users find relevant records
- Identifying missing information
- Drafting routine communication
- Preparing information for triage or prioritisation
- Highlighting patterns
- Supporting reporting
- Surfacing potential exceptions
Leadership views
Different roles need different views of the same service.
Job titles vary across public organisations, so these are responsibilities rather than assumed titles.
Chief executive or senior leadership
Demand, risk, outcomes and service pressure.
Finance leadership
Funding commitments, budgets, finance position and reconciliation.
Service director
Demand, backlog, capacity, partner delivery and outcomes.
CIO or digital leadership
Architecture, security, integration, resilience and change.
Data or performance leadership
Definitions, data quality, reporting and evidence.
Questions leadership should be able to answer
- Where is demand increasing?
- Where are cases or requests slowing down?
- Where is capacity under pressure?
- Which partners are involved?
- Where are decisions waiting?
- What funding or support has been committed?
- Where are incidents or risks increasing?
- What outcomes are being achieved?
- Where is administration consuming capacity?
Going deeper
The detail behind the routing.
Progressive disclosure for the areas that decide how much process a service ends up carrying.
How we work
Start with the service problem, then design the technology around it.
The same working principles apply whether the answer is CRM, Power Platform, CRMS, ERP, data or integration.
Understand before building
Start with the service problem, then design the technology around it.
Make decisions visible
Expose assumptions and trade-offs early.
Use standard capability where it fits
Avoid complexity without business value.
Involve the people doing the work
Validate with real users and real scenarios.
Make data part of the design
Do not leave information quality until reporting fails.
Keep ownership clear
Technology should strengthen accountability, not obscure it.
Improve after go-live
Treat the first release as the beginning of operational learning.
Evidence
What our Public Sector evidence actually proves today.
We do not currently have a published customer video centrally verified as Public Sector evidence. CRMS and CMS are developed propositions rather than Public Sector customer outcome evidence.
No published customer video is centrally verified as Public Sector evidence. Our current published customer evidence relates to manufacturing, a membership organisation and general InteliSense customers, and we do not present those as Public Sector proof. Public Sector evidence will be published once the customer, the sector, the engagement and the approved claims have been verified.
Company-level customer evidence is published separately and clearly labelled as such. It shows what working with InteliSense is like, not what we have delivered in the public sector.
See company-level customer storiesWhere to start
Tell us where you are, and we will tell you what the situation supports.
Four questions. The answers are carried into the conversation, so nothing needs repeating. We do not select CRMS, CMS or any other platform from a form.
Indicative signal
Answer the questions and we will show a likely starting point. This is orientation rather than a recommendation. We do not select CRMS, CMS, a platform or an acceleration route from a form. Please keep answers at organisation and service level.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions public-service leaders ask.
Coordinate the service, not just the software
Which service problem needs to change, and who owns the decision behind it?
If requests, referrals, cases, partner working, funding, finance or reporting are harder to coordinate than they should be, we can help you understand where the constraint sits and which capability and commercial route your situation genuinely supports.