Tailored Dynamics 365 Adoption and Training to Overcome User Resistance
For the manager whose team has already sat through generic training, hated it, and is threatening to go back to the spreadsheet.
This is tailored Dynamics 365 adoption and training for a team that has already sat through generic training and rejected it. It is not a course catalogue and not a compliance module with a quiz at the end. We build the sessions from your own records, your own process and your own screens, role by role, and we teach what changes in the daily work rather than touring the features of the product. It exists for one situation in particular: a live implementation where usage has stalled, the numbers coming out of the system are unreliable because only half the team enters anything, and people are openly saying they will go back to the spreadsheet. The reason we can fix that and a training vendor usually cannot is that the people running the sessions are the engineers who can change the form, the view or the flow in the room, and most user resistance turns out to be a design complaint wearing an attitude costume.
The short answer
- What it is. A tailored adoption programme for Dynamics 365 Customer Engagement: Sales, Customer Service, Field Service and Customer Insights, plus the Power Apps and Power Automate that sit around them. Role based curricula built from your configuration and your data, live sessions in small groups, floorwalking after go live, and a second wave once people know enough to ask real questions.
- What makes it different. We fix before we teach. The first thing we do is read what the system already records about where people get stuck, then remove the worst of the friction: the eight field form that needs three, the default view nobody recognises, the retyping a flow can do. Training that explains a bad screen very clearly is still a bad screen.
- Who delivers it. Solzet consultants and engineers from Yerevan, Armenia, working on Dynamics 365 Customer Engagement and the Power Platform every day. The person teaching your sales team on Tuesday is the person who can change the form on Wednesday. Sessions run live over Teams, or in the room in Yerevan, in English, Armenian or Russian.
- What we are not. A Microsoft Learning Partner selling official courseware and exam certificates, and not an e-learning library. If what you need is a certificate for a procurement file, buy that from a training company. If what you need is a team that starts using the system, this is the other thing.
If the system itself is the problem rather than the people using it, start with our health check and technical audit instead, and come back here once you know what you are training people on.
Why generic Dynamics 365 training failed with your team
If your people rejected the last round of training, that is useful information and not a character flaw. These are the six reasons a generic or compliance style course fails on a team that already has a working way of doing its job, and each one of them is a design decision somebody made about the training rather than something wrong with the room.
It teaches the product, and nobody resists the product
A generic course walks through navigation, records, views and dashboards, in a demo tenant, with sample data. That is a tour of software. What your team is resisting is a change to how they work: who owns a lead now, what has to be true before a deal moves stage, and the fact that a phone call which used to be remembered now has to be typed. None of that is in the course, so the course cannot answer it.
Compliance training is designed to be evidenced, not to be useful
A module with a completion percentage and a quiz exists so somebody can prove it happened. People know the difference immediately, and the moment they detect it, the room stops listening. If your last attempt was a recorded video and a multiple choice test, the team is not being difficult by hating it. They correctly identified what it was for.
It runs on sample data, so nobody recognises anything
People learn a system by finding their own accounts, their own open work and their own numbers in it. Training on a demo tenant full of invented companies teaches the click path and nothing about the job. Worse, it hides the problem that actually matters, which is whether the migrated data looks right to the person who owns it.
One session for eight different jobs teaches nobody
A room holding sales, service, dispatch and finance gets a lowest common denominator agenda where every person is bored for most of it and lost for the rest. A field technician and a sales manager share a platform, not a workflow. The curriculum has to split by role or it is a broadcast.
The trainer cannot change anything
The most common moment in a bad session is a user pointing at a screen and saying it makes their job harder, and the trainer writing it on a flip chart. That is the end of the conversation as far as the room is concerned. Nothing in the course fixes it, the feedback goes into a backlog nobody sees again, and everyone learns that complaining is pointless.
It happens once, at the worst possible moment
Training is scheduled the week before go live, when nobody has enough context to ask a good question, and then never again. Every real question arrives in week three, once people have hit their own edge cases, and by then the trainers have left. The useful material is the second wave, and the second wave is the one that gets cut from the budget.
The related argument, that a search for a training provider is often really a broken customisation, is made in full in our post on the Dynamics 365 customization mistakes that break implementations.
What a user revolt is actually telling you
Every sentence in the left hand column is one we have heard in a room. Almost none of them are really about attitude, and reading them as complaints to be managed rather than evidence to be acted on is how a rollout gets a second failed training programme instead of a fix.
| What the team says | What it usually means | What we change first |
|---|---|---|
| It takes twenty clicks to log one call. | The main form carries every field anybody has ever asked for, on one tab, in the order they were requested rather than the order the job happens in. | Rebuild the form around the fields the task genuinely needs, move the rest behind a second tab, and let business rules reveal the conditional ones instead of showing all of them to everyone. |
| The spreadsheet was faster. | Usually true, and worth conceding out loud. The sheet had no required fields, no validation and no owner. Speed was the whole benefit and it was real. | Time the task in both, in front of the team, then remove steps until the system wins on something they care about. Arguing with the comparison loses the room. Beating it ends the argument. |
| It never has the right data. | Migration left history behind, matched records badly, or dropped the notes people relied on, so nobody recognises their own accounts on the first screen. | Fix the data before you book a session. No amount of training rescues a system whose records look wrong to the person who owns them. |
| I already know how to do my job. | They do. The training was about the product when the question was about the process, and nobody told them what specifically changes for them. | Open the session with the three things that change for that role and the one thing that gets easier. Everything else is detail that can wait. |
| This is just management checking up on us. | The only visible output so far has been a manager dashboard. Everything shipped to date takes time from the user and gives value to somebody else. | Ship one thing in the first fortnight that shortens their own day, and say who asked for it. A pipeline dashboard is not that thing. |
| Nobody else uses it, so what is the point. | True, and self reinforcing. Partial use makes the data unreliable, unreliable data makes the reports useless, useless reports prove the sceptics right. | Stop trying to move the whole company at once. Get one team and one process to complete use, publish that, and expand from something that works. |
| The last training was a video and a quiz. | Compliance training was bought instead of adoption work, probably because it was cheaper and easier to evidence. | Live sessions, small groups, in a real environment they can break, run by somebody who can answer why the screen looks like that. |
| I raised this six months ago and nothing happened. | The feedback loop is broken. This is the most damaging item on the list, because it is about trust rather than about software. | Fix two of the outstanding complaints before the first session and open by naming who raised them. Credibility in the room is bought, not asserted. |
The one item on that list which is not a software problem is the last. Once a team believes feedback goes nowhere, the fix is to close two old complaints before you ask for a single new one.
The adoption programme, step by step
The order matters more than any individual step. Diagnosis first, then configuration changes, then teaching, then presence while people work. A programme that starts at step five is a course, and a course is what did not work last time.
- 1
Agree what adoption means, as something countable
Before anything is scheduled we write down the number this is judged on, per team, and it is a process number rather than a login count. Opportunities with a next activity booked. Cases resolved in the system rather than in a mailbox. Work orders closed on the device instead of on paper. Timesheets submitted by Friday. The number has to be one the business already cares about, because a metric invented for the training programme gets abandoned with the training programme.
- 2
Watch the work before writing a single slide
We sit with two or three people in each role for a morning and watch a real day, including the parts that happen in a spreadsheet, on the phone and in a personal folder of saved emails. We are looking for the workarounds, because a workaround is a precise, free description of where the system fails. This is also where we find the informal expert every team has, who matters more to the rollout than any manager.
- 3
Read what the system already records about the problem
Dynamics 365 knows a great deal about where people give up. Which forms are opened and abandoned, which fields stay empty, which views were personalised because the default was useless, how long a form takes to load, which flows fail silently, how many records are created by the integration versus by a person, and which security roles are blocking something people quietly ask a colleague to do for them. We pull that evidence with the platform analytics and audit history rather than guessing, and it usually contradicts at least one thing everybody believed.
- 4
Fix the worst of the friction before the first session
This is the step a training vendor cannot perform and the reason the programme works. We take the shortlist from the two steps above and change the system: simplify the form and split the tabs, fix the default view so the first screen shows the person their own work, remove required fields the business does not actually require, add the business rules that hide what is irrelevant, and automate the retyping with a flow. Then we go back to the people who complained and show them. The session that follows lands in a different room from the one we would have walked into a week earlier.
- 5
Build the curriculum from your records, one track per role
Each role gets its own short track built on your configuration: the screens they will really see, the fields they will really fill, and their own accounts, cases or work orders in the examples. The spine of every track is the process rather than the product, so it is written as the tasks the job is made of and not as a tour of the navigation. Where a track needs a reference card, it is one page, screenshotted from your system, and it names who to ask.
- 6
Run the sessions live, small, and in an environment they can break
Groups of six to ten from the same role, ninety minutes at a time, hands on in a training environment loaded with a realistic copy of your data rather than sample companies. People do the work rather than watch it. Sessions are recorded so the ones who cannot attend get something, but the recording is the fallback and never the plan, because a recording cannot answer the question that is actually holding somebody up.
- 7
Name and equip somebody inside each team
Every team gets one or two people who get a longer session, early access to the changes, and a direct line to us. They are chosen because their colleagues already ask them things, not because they are available. This is the part that decides whether the programme survives after we leave, and it is worth protecting their time in writing, because the alternative is a champion who is quietly doing two jobs and resents both.
- 8
Floorwalk the first two weeks instead of opening a ticket queue
For the first fortnight of real use we are present and reachable while people work, not sitting behind a support address. Somebody who is stuck at 10:40 on a Tuesday and cannot get an answer goes back to the spreadsheet by 10:45, and the habit forms there. Small fixes that come out of this window get shipped inside the window, because a change that arrives in the same week it was asked for is worth more to adoption than a better change next quarter.
- 9
Publish the number weekly, by team, without theatre
The number agreed in the first step is published every week per team, in the open, alongside what changed in the system that week. Two rules make it work. It is reported by team rather than by individual, so it reads as a system problem rather than a naming exercise, and every week it is published with at least one thing we changed because somebody complained. A metric that only travels upward turns into surveillance, and surveillance is where adoption programmes go to die.
- 10
Run the second wave once people know enough to ask hard questions
Thirty to sixty days in, we come back for a shorter round. By then the team has hit its own edge cases, discovered the features nobody was ready to hear about at go live, and formed habits worth correcting while they are still soft. This wave covers the things that were deliberately left out of the first: personal views, bulk edit, the reports they can build themselves, and the shortcuts that make the daily grind faster. It is the highest value session in the programme and the one most often cut.
- 11
Hand over the material and the ability to maintain it
Everything is yours: the role tracks, the reference cards, the recordings and the environment setup, in editable form rather than as a locked package. Your administrators get their own track on how to keep it current, because Microsoft ships two release waves a year and a training pack written once is wrong within a year. If you continue with us it is as ongoing support, not because the material only works while we are holding it.
We fix the system before we teach it
This is the part a training company structurally cannot do, and it is why the same team that rejected a course will sit still for this. These are the changes that most often come out of the diagnostic, in rough order of how much resistance they remove per day of work.
The form, split by when things are known
Most forms that people hate are one long tab holding every field the business ever mentioned, in request order. We rebuild around the moment: what has to be captured on the phone, what is known later, what only a specialist ever touches. Tabs, sections and business rules do almost all of this without a line of code, and it is the single change that most often turns a hostile team neutral.
The first screen, showing their own work
People judge the system by whatever loads when they open the app. If that is a grid of all accounts sorted by name, the system looks like a filing cabinet. If it is their open work, ordered by what is late, it looks like a tool. Default views, personal view defaults per role and a landing dashboard per app are cheap to change and disproportionately effective.
Required fields that are actually required
Every mandatory field that cannot honestly be answered at the moment it is demanded produces a junk value, and junk values are how a data set loses its credibility. We go through the required list with the people who fill it in, and either move the requirement to a later stage, make it conditional, or accept that it was never a requirement at all.
Retyping removed with Power Automate
A large share of resistance is not to the system but to entering the same fact twice. A flow that copies the detail from the record into the follow up, files the email against the case, creates the tasks a stage change implies, or writes the confirmation nobody enjoys writing, buys goodwill faster than any argument about data quality.
A custom control where the standard screen loses the argument
Sometimes the honest answer is that the out of the box screen genuinely is slower than the spreadsheet for that specific task, and configuration will not close the gap. That is what PCF controls are for: an editable grid, a board view, a picker built for the job. Building custom controls is a service line of ours in its own right, so it is normal work here rather than an escalation to somebody else.
Something back for the people doing the entering
If every change so far has taken time from the user and given information to a manager, the system is a tax and everybody knows it. We make a point of shipping at least one thing per team that only benefits that team: their own view, their own report, a flow that does the annoying part, a mobile shortcut. Reciprocity is not a soft factor here, it is the mechanism.
Where the answer is a custom control rather than configuration, that is our own work rather than a subcontract: see custom PCF control development and the buy, build or customize decision guide for how we decide whether a control is worth commissioning at all.
One track per role, built from your own system
A field technician and a sales manager share a platform, not a workflow, so they do not share a session. Each track below is short, hands on, and written against your configuration rather than a demo tenant. Which of them you need depends on what you have deployed, and a first programme is usually three or four of them rather than all seven.
Sales people and account managers
The daily loop rather than the module: what happens to a lead that arrives from the website, when a qualification becomes an opportunity, what has to be true to move a stage, and how to keep the forecast honest without spending an afternoon on it. Heavy on the Outlook and Teams side, because a seller who has to leave their inbox to record anything will not record it. Light on configuration, since none of it is their job.
Sales managers and heads of sales
Reading the pipeline without opening every record, running a one to one from the system instead of from a spreadsheet somebody prepared the night before, and the conversation about what the numbers mean when half the team is not yet entering everything. Managers are the single biggest lever in the programme, because a manager who runs their meeting off the CRM makes the CRM matter, and one who asks for the sheet undoes an entire rollout.
Customer service agents
The case from arrival to resolution: routing and queues, why an SLA timer behaves the way it does, using knowledge articles rather than a personal folder of answers, and closing a case in a way the reporting can actually count. Where Omnichannel is in scope, the session covers working several conversations at once and what to do when a chat drops, which is where most agent frustration on that product comes from.
Dispatchers and service coordinators
The schedule board as a working tool rather than a screensaver: what the scheduling assistant is really doing, why it suggests the person it suggests, and how to keep a manual booking from being moved out from under you. Dispatch is the role where trust in the system is won or lost fastest, because the consequence of a bad suggestion is a technician driving to the wrong town.
Field technicians on the mobile app
Short, practical, and run on a real phone rather than a projector: opening the right asset, running the service tasks, recording measurements, photographing a fault, consuming a part and capturing a signature with the network switched off. Technicians adopt an app that takes fewer taps than the paperwork it replaces and abandon one that takes more, so this track is as much a design review as a training session.
Marketing and Customer Insights operators
Building a segment that means something, the difference between a journey that is live and one that only looks live, consent and preference handling, and how to check whether a contact is actually moving through the journey rather than sitting stuck at a tile. This is a small audience but a high leverage one, since a misconfigured journey is visible to your customers rather than only to your staff.
System owners and internal administrators
The track that decides whether the programme outlives us. Solutions and environments and why nobody customises production, security roles and teams, managing views and dashboards, adding a field without breaking the reporting, reading flow run histories, and knowing where the boundary sits between what an administrator should change and what needs an engineer. Run for the internal owner, whether or not that person is full time on it.
The dispatch and technician tracks draw on the same delivery experience as our Field Service implementation work, where an installed base in Dataverse and a mobile app the technicians actually adopted moved a European manufacturer off spreadsheets and phone calls. Time entry adoption on Project Operations, which is its own kind of resistance, is covered in the Project Operations implementation guide.
Measuring adoption without turning it into surveillance
An adoption number that only travels upward teaches people that the system exists to watch them, and a team that believes that will feed it exactly enough to be left alone. These are the things we count, the two rules we publish them under, and the one category of number we refuse to put in front of you.
Process completion, not logins
A login proves somebody opened a browser. We count the thing the business already wanted: opportunities with a next step booked, cases resolved inside the system, work orders completed on the device, quotes raised from the record rather than from a document on a laptop. If the number would still matter with the CRM removed, it is the right number.
Data quality on the fields decisions depend on
Not completeness across every column, which nobody has ever achieved and which mostly measures how many required fields you added. We pick the handful of fields the reports actually consume and track how often they are filled honestly and kept current, because that is the difference between a report a leadership team trusts and one they stop opening.
The workaround census
The most reliable adoption signal in any organisation is how many spreadsheets are still in daily use, and it costs nothing to count. We name them at the start of the programme, agree which ones should disappear, and check them again at the end. A shadow spreadsheet that survives is not a discipline problem, it is a specification for something the system still does not do.
What we will not put on a slide
We publish no benchmark adoption percentages and no industry averages, on this page or in a proposal, because we cannot evidence them for your company and a number invented to justify a purchase is the exact behaviour that made your team cynical in the first place. Your baseline is measured in your own environment in the first week, and every claim afterwards is against that.
The two publishing rules are simple enough to hold anybody to. Report by team rather than by individual, so a low number reads as a system problem to be solved rather than a person to be spoken to. And never publish the number without also publishing at least one thing that changed in the system that week because somebody complained. The second rule is the one that keeps people telling you the truth, which is the only input the whole programme actually runs on.
The trainer is an engineer who can change the system
Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia. We implement Sales, Customer Service, Field Service and Customer Insights, we build Power Apps, Power Automate and custom PCF controls, and we take over implementations that have stalled. Adoption work is not a separate department here, which is the whole point: the consultant who teaches your service team on Tuesday is the one who can rebuild the case form on Wednesday, and the room can tell the difference within about ten minutes.
Sessions are live and small, six to ten people from the same role, hands on in a training environment loaded with a realistic copy of your data rather than sample companies. We run them remotely over Teams for clients across Europe, the UK and the US, or in the room for organisations in Yerevan. We teach in English, Armenian and Russian. Armenia is UTC+4 with no daylight saving, which leaves four to six hours of daily overlap with Western European hours and six to eight with the UK, so sessions and floorwalking happen inside your working day rather than being handed over as a recording the next morning.
We work in your tenant through accounts you create with least privilege and can revoke at any time, and the training environment is a sandbox rather than production. Where a realistic copy of your data would expose personal data unnecessarily, we mask it. Engagements are B2B with a mutual NDA, a GDPR compliant data processing agreement and IP ownership stated in the statement of work, and every piece of material we produce is handed over in editable form.
If another partner built the system and you want an outside read before committing to anything, that is our independent health check. If the implementation is far enough gone that adoption is the least of the problems, it is a rescue and takeover, and there is a guide to failed project takeovers that includes what to do when there is no budget at all.
Where we are the wrong answer
A services page that only lists strengths is not much use to somebody trying to decide. There are four situations where buying this from us would be a mistake, and in three of them we would tell you so before quoting.
You need certificates for a procurement file
If the requirement is official Microsoft courseware, a numbered course code and an exam voucher, buy that from a Microsoft Learning Partner or a training company. We are not one, we do not sell certificates, and pretending otherwise would waste your budget. Plenty of organisations buy both, and the order that works is the platform course first for the administrators and this programme for everybody else.
The build is broken rather than unloved
There is a real difference between a team resisting a working system and a team correctly refusing a broken one. If flows fail nightly, the data model cannot answer the questions the business asks, or the last partner customised production directly, training is the wrong purchase and would be us taking money to paper over it. That is a health check or a rescue, and both are described elsewhere on this site.
The incentives point the other way
If the commission plan pays on a number that lives outside the CRM, if the sales meeting still runs off a spreadsheet somebody prepares the night before, or if the executive sponsor has quietly stopped attending, no amount of training moves the needle and we will say so rather than sell you a programme. Those are decisions only you can make, and they are worth making before anybody books a room.
You need on site delivery in a local language every week
We teach in English, Armenian and Russian, live over Teams, or in person in Yerevan. If you need weekly sessions in the room in German, Dutch or French, a local partner will serve you better for the classroom half, and we are happy to do the system changes behind it while they front the sessions.
Weighing whether to run the adoption work with your own people instead? Our consultant against do it yourself decision guide costs training, adoption support and hypercare as a budget line and is honest about when the internal route is the better one.
Frequently Asked Questions
My team hates generic training. How is this actually different?
Three differences, and they are structural rather than a matter of style. First, we change the system before we teach it: the friction people complained about is fixed in the environment before the first session, so the session is about a better screen rather than an explanation of a bad one. Second, the material is built from your configuration and your records, split into a short track per role, so nobody sits through forty minutes about a module they will never open. Third, the person in the room is an engineer who works on Dynamics 365 Customer Engagement every day, so when somebody says the form is wrong, the answer is a change rather than a note on a flip chart. If your last training was a recorded video and a quiz, your team was right to hate it, and telling them that out loud is usually how the first session starts.
Do you run official Microsoft certification courses?
No. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy, not a Microsoft Learning Partner, and we do not sell official courseware, course codes or exam vouchers. Our engineers hold Microsoft certifications, but what we deliver is tailored adoption work on your own system rather than a syllabus. If you need certificates for a procurement or compliance file, buy those from a training company. If you need the team to start using the system, that is what this is, and the two are not really substitutes for each other.
What if the real problem is the system rather than the users?
That is the most common finding, and we would rather tell you in week one than run a programme around it. Resistance is information: a team that says a form takes twenty clicks is usually counting accurately. The first phase of the programme is deliberately diagnostic, combining watching people work with the evidence the platform already holds, and it produces a shortlist of changes rather than a curriculum. If what we find is a genuinely broken build, flows failing nightly, a data model that cannot answer the questions the business asks, customisation done directly in production, then the honest answer is that training is the wrong purchase and you want a health check or a rescue instead. We will say that in writing rather than sell you sessions.
My team is threatening to go back to spreadsheets. What happens first?
We do not open with a training plan, because at that point a training plan reads as management not listening. We start by watching two or three people in each role do a real day and counting the workarounds, then we fix two or three of the loudest complaints in the environment and take them back to the people who raised them. That is the credibility purchase, and everything else depends on it. The second move is to make sure something ships that benefits the people doing the data entry rather than only the people reading the reports, because if every change so far has taken time from users and given information to managers, the revolt is a rational response and not a discipline problem.
How long does an adoption programme take?
It depends on how many distinct roles are in scope, how much friction has to be removed before teaching, and whether you are pre go live or trying to recover a rollout that has already stalled. A single team on one app is a matter of weeks. A multi role recovery across sales and service is longer, mostly because the fixes are real configuration work rather than session preparation. What does not change is the shape: diagnose, fix, teach by role, floorwalk the first fortnight, publish the number, then come back at thirty to sixty days for the second wave. We would rather scope that properly on a call than put a duration on a web page, because a number quoted without seeing the environment is guesswork.
How do you measure adoption without turning it into surveillance?
Two rules. Report by team rather than by individual, and publish every weekly number alongside at least one change we made because somebody complained. The moment a metric only travels upward, people learn that the system is there to watch them and they optimise for the metric rather than the work. On what to count, we use process completion rather than logins: opportunities with a next activity booked, cases resolved in the system rather than in a mailbox, work orders closed on the device, timesheets in by Friday. We also count the shadow spreadsheets still in daily use, which is the most honest adoption signal available and costs nothing to collect.
Do you train administrators as well, or only end users?
Both, and the administrator track is the one that decides whether the programme survives. It covers solutions and environments and why production is never customised directly, security roles and teams, managing views and dashboards, adding a field without breaking the reporting, reading flow run histories, and where the line sits between what an internal administrator should change and what needs an engineer. Microsoft ships two release waves a year, so a training pack written once is wrong within a year. We hand over everything in editable form and teach your owner to keep it current, rather than leaving you dependent on us to update a slide.
Can you do this if another partner built the system?
Yes, and it is a common way we get involved. We have no earlier design decision to defend, which makes the diagnostic more useful, and we work in your tenant through accounts you create with least privilege and can revoke. Where we find things that need fixing we say so plainly and put them in an order the incumbent partner can execute if you would rather they did. Taking over from another partner entirely is a different service, described on our project rescue and takeover page, and we will tell you which of the two you are actually looking at.
How are sessions delivered, and in what languages?
Live, in small groups of six to ten from the same role, hands on in a training environment loaded with a realistic copy of your data. Remote over Teams for clients across Europe, the UK and the US, or in the room for organisations in Yerevan. We teach in English, Armenian and Russian. Armenia is UTC+4 with no daylight saving, which leaves four to six hours of daily overlap with Western European hours and six to eight with the UK, so sessions run live at times that suit your working day rather than being handed over as recordings. Recordings exist as a fallback for people who cannot attend, never as the plan.
What does it cost?
It is scoped like delivery work rather than sold per seat, because the expensive part is the configuration work that happens before the teaching and that depends entirely on what we find. The inputs are the number of roles in scope, the state of the system, and whether you want the second wave and ongoing support after it. We quote a fixed scope for the diagnostic and the first round of fixes, which is the part where the value is decided, and estimate the rest from what that finds. Our decision guide on hiring a consultant against doing it yourself sets out how we build project numbers generally, including what drives training and hypercare as a budget line.
Start with the diagnostic
Tell us which apps are live, how many people are supposed to be using them, and the sentence your team keeps repeating about why they do not. We will come back with what we would look at first, what we think is configuration rather than training, and an honest read on whether an adoption programme is what you actually need.