Support & Managed Services
Keep the platform working.
Keep improving what happens around it.
LiveControlled
When Dynamics 365, Business Central, CRM or Power Platform becomes part of day-to-day operations, support needs to understand more than the technical issue. We help customers resolve problems, understand recurring causes and identify where the platform or process needs to improve.
Stabilise. Support. Understand. Prevent. Improve.
When the system is live
Go-live changes the type of responsibility. It does not remove it.
The platform is now part of how the business operates. What matters next is how quickly issues are understood, owned and prevented.
If several of these are familiar, the question is not whether you need support. It is whether your current support model is working.
Business-critical issues
Operational problems need clear ownership and appropriate priority.
Recurring problems
The same issue keeps returning without the underlying cause being addressed.
Support backlog
Requests accumulate faster than they are resolved.
Unclear ownership
Nobody is certain whether the problem is system, process, data, integration or third party.
Small changes become difficult
Simple improvements take too long to progress.
Knowledge is concentrated
Too much depends on one internal person or one external consultant.
Platform changes
Microsoft releases and connected-system changes need to be understood.
Business change
The organisation changes faster than the original solution design.
Good support resolves the issue. Better support asks why it happened.
A ticket may begin with 'the system isn't working'. Correct classification is what turns that sentence into an outcome.
But the cause may be
- Configuration
- Data
- Process
- Security
- Integration
- Custom code
- ISV
- Microsoft platform
- User knowledge
- A new business requirement
From issue to outcome
Give every request a clear route.
The same discipline applies whether the request is a two-minute question or a stopped financial process.
Request
The issue or question arrives with business context, not just an error.
Triage
Establish what kind of problem this actually is.
Classify
Incident, question, configuration, data, integration, code or change.
Prioritise
Priority reflects business impact, not the volume of the request.
Investigate
Find where the behaviour is really coming from.
Resolve or route
Fix it, or move it to the right owner with the reason made clear.
Validate
Confirm with the business that normal operation has returned.
Close
Record the resolution so it is usable next time.
Learn
Ask whether this should become a problem to solve permanently.
Triage
First establish what kind of problem we are dealing with.
Classification decides who investigates, how it is prioritised and whether it belongs in support at all.
Incident
Something that should work is not working.
Question
The user needs guidance.
Configuration
Existing capability needs adjustment.
Data
The issue is caused by data or data quality.
Integration
A connected process has failed.
Custom code
An extension or customisation requires investigation.
Third party / ISV
The issue sits within connected specialist capability.
Microsoft
The underlying Microsoft service may require escalation.
Change request
The business wants the system to do something new.
Scope clarity
Not every request is a support incident.
If agreed capability is not working as expected, that is support. If the business wants new behaviour, automation, reporting, integration or functionality, that is change.
Support
Restore or explain
Return agreed capability to expected behaviour, or explain how it is intended to work.
Change
Understand, estimate, approve, deliver
New behaviour, new automation, new reporting, new integration or significant configuration change.
Change route
Change should be controlled, not hidden inside support.
A change route keeps requirement, effort, approval and deployment visible to the people accountable for them.
Request
The requirement is captured rather than absorbed into a ticket.
Investigate
Understand what is being asked and why.
Requirement
Define the intended behaviour clearly.
Impact
Understand the effect on process, data, integration and users.
Estimate
Provide the effort and commercial position for approval.
Approve
The customer decides whether the change proceeds.
Deliver
Build the change under normal delivery discipline.
Test
Validate against the agreed requirement.
Deploy
Move the change into production in a controlled way.
Close
Confirm the outcome and update knowledge.
Priority
Priority should reflect business impact.
Impact is a business judgement before it is a technical one, so priority is agreed rather than assumed.
- How many users are affected?
- Is a critical business process stopped?
- Is there a workaround?
- Is financial processing affected?
- Is fulfilment affected?
- Is customer service affected?
- Is there data or security risk?
- Is the issue deteriorating?
More than technical support
The error message is only part of the problem.
One reported issue usually has four readings. Support should understand all of them.
User reports
“We cannot post the invoice.”
Technical view
A posting error.
Business view
Customer invoicing has stopped.
Commercial view
Cash collection may be delayed.
Microsoft business applications
Support across the platform your business depends on.
Relevant integrations and approved connected solutions can be included where agreed. Not every third-party system is automatically in scope.
- Dynamics 365 Business Central
- Dynamics 365 Finance
- Dynamics 365 Supply Chain Management
- Dynamics 365 CRM / Customer Engagement
- Power Platform
- Power BI
- Finance, purchasing, sales and inventory
- Warehouse, manufacturing and projects
- Reporting, security and configuration
- Extensions and integrations
- Explore Business Central at /business-central
When systems connect, support cannot stop at the boundary.
Where an issue crosses system boundaries, we help identify the responsible component and coordinate the route to resolution where the agreed support model permits.
Already live with another partner?
You do not need to reimplement the system to change the support relationship.
Many organisations inherit a Dynamics environment they did not design, or reach a point where the original support arrangement no longer works. We can assess the existing platform, understand its dependencies and establish a controlled route into support.
Understand
Learn what the platform actually is today.
Document
Capture what is known, and what is not.
Assess
Establish supportability, risk and dependency.
Prioritise
Agree what needs attention first.
Transition
Move ownership in a controlled way.
Support
Operate the service with clear accountability.
Takeover assessment
Establish what is actually there.
The purpose of the assessment is operational knowledge, not paperwork.
- Applications
- Versions
- Environments
- Capacity
A poor handover should make transition more controlled. Not impossible.
Documentation may be incomplete. Original consultants may have left. Source decisions may be unclear. Open issues may exist. Customisations may be poorly understood. None of that prevents a controlled transition.
Support or Recovery?
Sometimes the problem is bigger than support.
Do not use support tickets to hide a recovery problem.
Support
- The platform is fundamentally operable.
- Issues can be managed through normal service processes.
- Ownership is understandable.
- The backlog is controllable.
Recovery
- Core processes are unstable.
- Delivery or solution confidence has collapsed.
- Major design questions remain unresolved.
- Data or integration issues are systemic.
- Backlog is masking structural problems.
- Go-live or programme decisions remain open.
Support or Optimise?
Sometimes nothing is broken. It could simply work better.
Support restores expected behaviour. Optimise improves existing behaviour.
Support
A workflow stopped.
Optimise
The workflow creates too much manual work.
Support
A report is failing.
Optimise
Leadership needs better insight.
Support
Users cannot complete the process.
Optimise
The process takes too many steps.
Support
An integration failed.
Optimise
The integration architecture needs improving.
Support and Optimise together
Support creates the evidence. Optimisation uses it.
Support shows where the platform repeatedly consumes effort. That evidence can help prioritise improvement.
01
Keep it running
02
Understand the patterns
03
Remove recurring friction
04
Automate
05
Improve insight
06
Introduce prediction
07
Continuous improvement
Beyond the incident
Repeated incidents should become a problem to solve.
Closing the ticket is not the same as removing the problem.
What problem management looks at
- Incident trend
- Recurring cause
- Affected process
- Frequency
- Business impact
- Workaround
- Root cause
- Permanent action
Symptom
What the user experienced.
Incident
What was recorded and resolved.
Pattern
How often it has happened, and where.
Root cause
Data, configuration, training, process, customisation, integration, performance, environment or third party.
Permanent change
The action that removes the problem rather than the ticket.
Knowledge
Every resolved issue should make the next one easier to handle.
Known errors, resolutions, workarounds, user guidance, configuration explanation and escalation routes belong somewhere reusable, for our team and for your key users.
Visible service
Customers should understand what is happening with their support service.
Service view
- Open incidents
- Priority
- Age
- Status
- Ownership
- Backlog
- Trend
- Recurring problems
- Change requests
- Escalations
Service review
- Service performance
- Backlog
- Priority incidents
- Recurring issues
- Problem management
- Open changes
- Platform risk
- Microsoft changes
- Improvement opportunities
- Upcoming business events
The support conversation should be bigger than individual tickets.
Operational timing
Support priorities change with the business calendar.
Support should understand when failure matters most.
- Month-end
- Year-end
- Stock count
- Peak trading
- Seasonal demand
- Payroll
- Financial close
- Product launch
- Warehouse peak
- Acquisition
- Go-live
- Regulatory deadline
Proactive support
The strongest support model looks for avoidable problems.
Where the agreed service includes it, attention can move ahead of the ticket. We only claim proactive monitoring where it is technically delivered.
- Environment health
- Capacity
- Integration failures
- Recurring incidents
- Job failures
- Data issues
- Platform changes
- Known Microsoft issues
- Operational exceptions
Platform change
Cloud platforms change even when your project does not.
Microsoft releases, feature changes, deprecations and compatibility implications should be assessed against your actual solution, customisations and ISVs, then tested where relevant.
The service generates data too
Support history can reveal where the platform is consuming unnecessary effort.
- Incident category
- Recurring issue
- Module
- Process
- Root cause
- Customer team
- Resolution type
- Change volume
- Age
- Trend
AI in support
Use AI to help people understand the issue faster.
AI helps consultants find context quickly. It does not resolve issues autonomously and it does not replace the person accountable for the outcome.
- Summarise ticket history
- Search knowledge
- Find similar incidents
- Prepare investigation context
- Draft responses
- Classify requests
- Identify recurring themes
Potential capability
The longer-term opportunity is to identify some issues before users report them.
Integration failure patterns, capacity pressure, operational backlog, repeated process exceptions and service demand may be predictable where the data supports it. We label this as potential capability rather than a standard inclusion.
Explore Predictive IntelligenceExpertise matters
Support needs people who understand the process behind the configuration.
Finance, supply chain, warehouse, manufacturing, CRM, Power Platform, data, development, integration and architecture.
Service desk
Capture, classify and own the request.
Functional or technical consultant
Investigate within the relevant application area.
Senior specialist
Deeper process, data or development analysis.
Architect or delivery lead
Structural, design or programme-level questions.
Microsoft or ISV
Where the issue sits below or beside the application.
Customers should know who owns the next action.
Every request should make the next action visible.
- Waiting on InteliSense
- Waiting on customer
- Waiting on Microsoft
- Waiting on third party
- Change required
- Resolved
Starting the relationship
Understand the platform before the first critical incident.
Good support is a shared operating model, so onboarding covers both sides of it.
- Stakeholders
- Key users
- Escalation routes
Existing backlog
Start with what is already waiting.
Classifying the inherited backlog usually improves clarity immediately.
Incident
Something that should work is not working.
Problem
A recurring cause behind several tickets.
Change
A new or materially different requirement.
Duplicate
Already recorded elsewhere.
Obsolete
No longer relevant to the business.
Needs discovery
Not yet understood well enough to classify.
Not sure what you have inherited?
Start by understanding the live environment.
What we assess
- Platform
- Configuration
- Customisation
- Integration
- Data
- Security
- Backlog
- Support history
- Known problems
- Business-critical processes
- Documentation
- Ownership
What you get
- A supportability view of the live environment
- A risk and dependency view
- Backlog classification
- Priority issues
- Takeover considerations
- Recovery indicators, where they exist
- Optimisation opportunities
Where support sits
One relationship, several routes.
Support is the part of the relationship that operates every day. It is not the only route available to you.
Support model
Structure the service around the business, not a package name.
Support arrangements can be structured according to the factors that actually determine effort and risk.
- Platform
- Business criticality
- Required coverage
- Complexity
- Integration landscape
- Volume
- Expertise required
- Service governance
- Improvement requirements
Evidence
They came to us for what needed fixing. They stayed for what came next.
80% of our business comes from existing customers and referrals. Here is what those customers say in their own words.
Customer voice
What our customers say.
Customer voices
InteliSense customers
Hear our customers talk about InteliSense
How we support
Own the issue. Understand the context. Improve what happens next.
Business context
Understand why the issue matters, not only what it says.
Clear ownership
Make the next action visible at all times.
Right expertise
Route the issue to people who understand the relevant process.
Root cause
Look beyond repeated symptoms.
Controlled change
Separate support from new requirements.
Connected platform
Understand ERP, CRM, Power Platform, data and integration dependencies.
Continuous improvement
Use support evidence to identify optimisation opportunities.
Long-term relationship
Stay involved beyond implementation.
Common questions
Questions leaders ask about support.
Your system is already live
The question is whether your support model is working.
Whether InteliSense implemented the platform or not, we can help you understand the current environment, existing backlog and support dependencies, and determine the right route forward.