Dynamics 365 Case Management - Simply Explained

1
00:00:00,000 --> 00:00:04,120
A customer emails about a broken order, then calls the next day, then opens a chat because

2
00:00:04,120 --> 00:00:07,560
nobody seems to know what happened, and they repeat the same story every time, while

3
00:00:07,560 --> 00:00:11,360
your support team hunts through inboxes, notes, and separate tools.

4
00:00:11,360 --> 00:00:15,240
That Uhtmer is exactly what Dynamics 365 Case Management fixes.

5
00:00:15,240 --> 00:00:18,840
Think of a case like one labeled folder inside a busy office building, where every part

6
00:00:18,840 --> 00:00:22,280
of a customer problem goes into that folder or from the first question to the final answer.

7
00:00:22,280 --> 00:00:24,640
Uhtmer Mirko Peters from M365FM.

8
00:00:24,640 --> 00:00:29,360
And in this knowledge nugget, you outmell see how cases, routing, response deadlines,

9
00:00:29,360 --> 00:00:32,080
and articles and closure all fit together.

10
00:00:32,080 --> 00:00:34,480
What a case actually is 520 words.

11
00:00:34,480 --> 00:00:36,040
So what exactly is a case?

12
00:00:36,040 --> 00:00:40,200
A case is one record for one customer issue that needs an answer or a fix, and the issue

13
00:00:40,200 --> 00:00:44,600
could be a damaged product, a billing question, a login problem, or a request for help using

14
00:00:44,600 --> 00:00:45,600
a service.

15
00:00:45,600 --> 00:00:48,920
HeroTemps the thing, one customer can have several cases at once.

16
00:00:48,920 --> 00:00:53,080
A single customer might ask about an invoice on Monday, report a failed device on Tuesday,

17
00:00:53,080 --> 00:00:54,920
and need help changing an address on Friday.

18
00:00:54,920 --> 00:00:58,840
Those are separate problems, so Dynamics 365 keeps them in separate case records instead

19
00:00:58,840 --> 00:01:02,160
of piling every conversation into one confusing thread.

20
00:01:02,160 --> 00:01:05,280
When an agent creates a case, they link it straight to the customer.

21
00:01:05,280 --> 00:01:09,400
That customer may be a contact you meaning an individual person or an account meaning

22
00:01:09,400 --> 00:01:10,600
the company they work for.

23
00:01:10,600 --> 00:01:14,520
So if Jamie from Northwind traders reports a problem, the case can point to both Jamie and

24
00:01:14,520 --> 00:01:18,920
the company, and anyone opening the record can see who needs help and which organization

25
00:01:18,920 --> 00:01:20,600
the issue belongs to.

26
00:01:20,600 --> 00:01:24,240
The case also needs a plain description of the problem, usually starting with a title

27
00:01:24,240 --> 00:01:29,680
like "Oprinter stops after software update AU" or "O will customer charge twice for annual

28
00:01:29,680 --> 00:01:35,600
plan" AU and that title helps people scan a list of open cases without opening every record.

29
00:01:35,600 --> 00:01:37,920
Below that title the agent adds the detail.

30
00:01:37,920 --> 00:01:39,560
What happened when did it begin?

31
00:01:39,560 --> 00:01:42,760
What has the customer already tried, which product it involves and whether it automates a

32
00:01:42,760 --> 00:01:45,160
question, a request, or a fault?

33
00:01:45,160 --> 00:01:48,920
These details turn a vague message into work that somebody can own and solve.

34
00:01:48,920 --> 00:01:50,480
Letotemps break it down further.

35
00:01:50,480 --> 00:01:53,800
A case can carry a subject, product, priority, and case type.

36
00:01:53,800 --> 00:01:57,840
The subject groups the issue into an area like billing or technical support, the product

37
00:01:57,840 --> 00:02:02,720
identifies what the customer uses, the priority tells the team how quickly to look at it, and

38
00:02:02,720 --> 00:02:07,320
the case type gives the team another way to sort work based on their support process.

39
00:02:07,320 --> 00:02:11,120
None of these fields solve the customer or temers problem by themselves, but they help

40
00:02:11,120 --> 00:02:15,280
the support team see the work clearly, especially when hundreds of cases arrive from different

41
00:02:15,280 --> 00:02:16,280
customers.

42
00:02:16,280 --> 00:02:19,920
A team dealing with a serious service failure should know, temate, have to search through

43
00:02:19,920 --> 00:02:21,400
general questions to find it.

44
00:02:21,400 --> 00:02:25,120
Now a case is no attempt to just form someone fills in and forgets.

45
00:02:25,120 --> 00:02:27,920
It becomes the working record for the whole conversation.

46
00:02:27,920 --> 00:02:32,000
Emails can connect to the case, phone calls can appear there, and an agent can add notes

47
00:02:32,000 --> 00:02:35,960
after a chat, set a follow-up task, or record an appointment.

48
00:02:35,960 --> 00:02:40,480
Each activity stays with the same customer problem, so the next person does now attempt,

49
00:02:40,480 --> 00:02:42,520
need to rebuild the story from scratch.

50
00:02:42,520 --> 00:02:46,480
Imagine an agent starts working the morning and then hands the case to a product specialist

51
00:02:46,480 --> 00:02:47,480
after lunch.

52
00:02:47,480 --> 00:02:51,120
Without a case record, the specialist might receive one short message like, "Oh, can

53
00:02:51,120 --> 00:02:52,120
you look at this?"

54
00:02:52,120 --> 00:02:54,360
A/O, which is now admit enough.

55
00:02:54,360 --> 00:02:57,920
With the case record, they can see the original issue, customer details, what happened during

56
00:02:57,920 --> 00:03:00,760
the call, and what the first agent already checked.

57
00:03:00,760 --> 00:03:02,880
That autumn is a much better hand off.

58
00:03:02,880 --> 00:03:07,440
Dynamics 365 keeps the case in a clear state as it moves through the support process.

59
00:03:07,440 --> 00:03:11,200
It can stay active while the team investigates, and once the team fixes the issue or gives

60
00:03:11,200 --> 00:03:13,600
the final answer, they resolve it.

61
00:03:13,600 --> 00:03:17,280
If the request no longer needs work, "Oh, maybe it came in by mistake or the customer

62
00:03:17,280 --> 00:03:19,960
withdrew, it how the team can cancel it."

63
00:03:19,960 --> 00:03:21,960
Active, resolved, and canceled.

64
00:03:21,960 --> 00:03:26,800
Now, those three states give the team a shared view of where each issue sits, so nobody

65
00:03:26,800 --> 00:03:31,840
needs to guess whether a case still needs attention and managers don't know, Tim, Artet,

66
00:03:31,840 --> 00:03:36,320
need to treat old finished work like a fresh customer problem.

67
00:03:36,320 --> 00:03:41,240
One record gives you control, and the full customer history gives the agent context.

68
00:03:41,240 --> 00:03:43,400
The customer's story behind the case.

69
00:03:43,400 --> 00:03:45,360
A case tells you what needs fixing.

70
00:03:45,360 --> 00:03:48,080
The customer record tells you what led to this moment.

71
00:03:48,080 --> 00:03:52,760
When an agent opens a case in Dynamics 365 customer service, they can look beyond the latest

72
00:03:52,760 --> 00:03:53,760
message.

73
00:03:53,760 --> 00:03:57,480
They see the bigger picture are you, earlier cases, past emails, the products connected to

74
00:03:57,480 --> 00:04:02,360
the customer and their support history, context changes the conversation, why does context

75
00:04:02,360 --> 00:04:03,360
matter?

76
00:04:03,360 --> 00:04:05,440
Imagine a customer reports a device failure.

77
00:04:05,440 --> 00:04:09,760
If the agent only sees today's message, they may start with basic questions.

78
00:04:09,760 --> 00:04:10,760
What model is it?

79
00:04:10,760 --> 00:04:11,760
When did it start?

80
00:04:11,760 --> 00:04:12,760
Did you restart it?

81
00:04:12,760 --> 00:04:16,520
But the customer has already contacted support twice this week, the first agent sent

82
00:04:16,520 --> 00:04:20,480
troubleshooting steps, the second arranged a replacement part, a third agent who sees

83
00:04:20,480 --> 00:04:23,000
that history won't ask the customer to start over.

84
00:04:23,000 --> 00:04:26,680
Instead, they say, "I can see you already tried those steps and the replacement part didn't

85
00:04:26,680 --> 00:04:27,680
fix it.

86
00:04:27,680 --> 00:04:28,680
Let's try the next thing."

87
00:04:28,680 --> 00:04:32,400
That feels very different from, "Can you explain the problem again?"

88
00:04:32,400 --> 00:04:35,240
This is often called a 360 degree customer view.

89
00:04:35,240 --> 00:04:36,920
The name sounds fancy, but it's simple.

90
00:04:36,920 --> 00:04:41,560
It means the agent sees the customer from more than one angle, not just one isolated message.

91
00:04:41,560 --> 00:04:45,600
The agent sees the person, they see the company, they see earlier support requests, previous

92
00:04:45,600 --> 00:04:47,760
conversations and the products connected to them.

93
00:04:47,760 --> 00:04:50,960
For a support team, that replaces guessing with a clear starting point.

94
00:04:50,960 --> 00:04:53,480
Now not every customer receives the same kind of support.

95
00:04:53,480 --> 00:04:57,680
A customer might have bought a warranty, their company might pay for a set number of support

96
00:04:57,680 --> 00:05:02,400
hours, or they might have a contract that allows a certain number of cases or premium support

97
00:05:02,400 --> 00:05:03,400
with faster help.

98
00:05:03,400 --> 00:05:06,920
Dynamics 365 tracks all of this through entitlements.

99
00:05:06,920 --> 00:05:10,920
An entitlement is the customer outtempt support agreement inside the system.

100
00:05:10,920 --> 00:05:13,680
Think of it as the service terms attached to their account.

101
00:05:13,680 --> 00:05:18,040
Before an agent promises an engineer over a TMS time or starts chargeable work, they check

102
00:05:18,040 --> 00:05:19,360
what support applies.

103
00:05:19,360 --> 00:05:20,640
That avoids awkward surprises.

104
00:05:20,640 --> 00:05:24,200
For example, a customer might still have warranty cover for a failed product.

105
00:05:24,200 --> 00:05:26,040
The case can follow that path.

106
00:05:26,040 --> 00:05:28,520
Another customer may have used all their support hours.

107
00:05:28,520 --> 00:05:31,320
The agent sees that before committing to work outside the agreement.

108
00:05:31,320 --> 00:05:33,840
It also helps the support team treat customers fairly.

109
00:05:33,840 --> 00:05:37,360
The agent doesn't need to search through old contracts or ask another department.

110
00:05:37,360 --> 00:05:41,080
The support terms sit with the customer information right where the agent can find them, then

111
00:05:41,080 --> 00:05:42,400
there's the knowledge base.

112
00:05:42,400 --> 00:05:44,760
The TMS solve the same problems over and over.

113
00:05:44,760 --> 00:05:49,000
Password resets, set up instructions, a known error after an update, a billing question

114
00:05:49,000 --> 00:05:52,760
with a standard answer, a knowledge article stores that answer in one place.

115
00:05:52,760 --> 00:05:56,400
Inside the service workspace, an agent can search for articles while working on a case.

116
00:05:56,400 --> 00:06:00,960
An article might include a plain explanation, steps, a screenshot, or the exact checks the

117
00:06:00,960 --> 00:06:02,280
team should complete.

118
00:06:02,280 --> 00:06:06,240
Instead of each agent writing their own version from memory, they use a shared answer the

119
00:06:06,240 --> 00:06:07,520
team has reviewed.

120
00:06:07,520 --> 00:06:08,920
That keeps support consistent.

121
00:06:08,920 --> 00:06:10,480
It also helps newer agents.

122
00:06:10,480 --> 00:06:14,240
They don't need years of experience to handle common problems well because the team's known

123
00:06:14,240 --> 00:06:16,760
fixes are available when they need them.

124
00:06:16,760 --> 00:06:20,280
Co-pilot case summaries help with another common problem, long case histories.

125
00:06:20,280 --> 00:06:23,400
A case can collect many emails, notes, and updates over time.

126
00:06:23,400 --> 00:06:26,080
Reading everyone takes time, especially after a hand off.

127
00:06:26,080 --> 00:06:30,600
Co-pilot creates a short case summary that pulls together the case title, customer, subject,

128
00:06:30,600 --> 00:06:33,880
product, priority, case type, description, and recent activity.

129
00:06:33,880 --> 00:06:36,000
It's a quick brief before the agent starts work.

130
00:06:36,000 --> 00:06:38,640
The agent still checks the record and uses their judgment.

131
00:06:38,640 --> 00:06:42,480
But they understand the situation faster that helps when the customer is waiting and the

132
00:06:42,480 --> 00:06:44,760
case has passed through several hands.

133
00:06:44,760 --> 00:06:48,400
Once the agent understands the customer and the problem, the case needs to reach the right

134
00:06:48,400 --> 00:06:50,960
person.

135
00:06:50,960 --> 00:06:54,840
From intake to the right queue, a customer can ask for help in many ways.

136
00:06:54,840 --> 00:06:59,360
Email, phone call, chat, social media, a self-service portal, the channel changes but the support

137
00:06:59,360 --> 00:07:02,520
team still needs one clear place to manage the request.

138
00:07:02,520 --> 00:07:07,280
Dynamics 365 can create cases from those conversations when the setup includes record creation

139
00:07:07,280 --> 00:07:08,280
rules.

140
00:07:08,280 --> 00:07:11,440
Think about an email arriving at a shared support address.

141
00:07:11,440 --> 00:07:15,120
Instead of leaving it in a mailbox until someone spots it, a rule turns that email into

142
00:07:15,120 --> 00:07:16,120
a case.

143
00:07:16,120 --> 00:07:18,840
The message becomes the start of work inside customer service.

144
00:07:18,840 --> 00:07:20,520
That cuts down on manual copying.

145
00:07:20,520 --> 00:07:23,160
The same idea applies to other connected channels.

146
00:07:23,160 --> 00:07:27,680
The team chooses which messages create a new case and which belong on an existing one.

147
00:07:27,680 --> 00:07:29,960
A reply to an open issue stays with that issue.

148
00:07:29,960 --> 00:07:31,680
A new question gets its own case.

149
00:07:31,680 --> 00:07:33,960
Then the case needs a home while someone takes ownership.

150
00:07:33,960 --> 00:07:35,240
That home is often a queue.

151
00:07:35,240 --> 00:07:37,360
A queue is a shared work tray for a team.

152
00:07:37,360 --> 00:07:41,480
It isn't one agent's inbox and it doesn't belong to the person who first saw the request.

153
00:07:41,480 --> 00:07:44,800
Instead it gives the whole team a place to see work waiting for attention.

154
00:07:44,800 --> 00:07:49,040
Imagine a company with a billing team, a technical support team and a returns team.

155
00:07:49,040 --> 00:07:50,440
Each team has its own queue.

156
00:07:50,440 --> 00:07:54,400
Billing questions go to billing, product faults go to technical support.

157
00:07:54,400 --> 00:07:56,960
Return requests go to the people who know the return process.

158
00:07:56,960 --> 00:07:58,600
That sounds simple because it is.

159
00:07:58,600 --> 00:08:02,040
Clear sorting saves people from passing work around blindly.

160
00:08:02,040 --> 00:08:03,400
Routing rules help with that sorting.

161
00:08:03,400 --> 00:08:07,800
A routing rule checks the details on a case and sends it to the right queue or person.

162
00:08:07,800 --> 00:08:10,840
A case about a specific product goes to the product team.

163
00:08:10,840 --> 00:08:13,280
A case from a certain region goes to local support.

164
00:08:13,280 --> 00:08:15,320
A serious issue goes to an urgent queue.

165
00:08:15,320 --> 00:08:17,520
A general question waits with the standard team.

166
00:08:17,520 --> 00:08:19,880
Some organizations root work based on skill.

167
00:08:19,880 --> 00:08:23,200
For example, a customer writing in French needs an agent who speaks French.

168
00:08:23,200 --> 00:08:26,000
A technical issue needs someone trained on a certain product.

169
00:08:26,000 --> 00:08:30,560
Routing puts the case closer to the person who can solve it instead of treating every request the same.

170
00:08:30,560 --> 00:08:32,960
Automation helps but people still make decisions.

171
00:08:32,960 --> 00:08:36,680
A team lead might look at a difficult case and assign it directly to a senior agent.

172
00:08:36,680 --> 00:08:38,720
Maybe someone already knows the customer.

173
00:08:38,720 --> 00:08:42,520
Maybe the problem crosses several products and needs experience a rule can't judge.

174
00:08:42,520 --> 00:08:45,560
Manual assignment gives the team room for that human choice.

175
00:08:45,560 --> 00:08:47,240
Ownership can change during a case.

176
00:08:47,240 --> 00:08:50,480
An agent might need more information and return the case to a queue.

177
00:08:50,480 --> 00:08:53,320
A team might discover the issue belongs to another department.

178
00:08:53,320 --> 00:08:57,400
Or an urgent request might need escalation when the normal team can't resolve it.

179
00:08:57,400 --> 00:09:01,600
Dynamics 365 keeps the work moving instead of leaving it with someone stuck.

180
00:09:01,600 --> 00:09:04,640
Now, sometimes one issue creates many cases.

181
00:09:04,640 --> 00:09:07,400
Picture a software outage affecting dozens of customers.

182
00:09:07,400 --> 00:09:11,160
Each customer contacts support separately, so each report needs its own case.

183
00:09:11,160 --> 00:09:13,680
But all reports connect to one larger problem.

184
00:09:13,680 --> 00:09:18,920
A parent case tracks that wider issue while child cases track individual customer reports beneath it.

185
00:09:18,920 --> 00:09:20,800
That gives the support team two views at once.

186
00:09:20,800 --> 00:09:23,400
They work on the underlying outage through the parent case.

187
00:09:23,400 --> 00:09:26,160
While each child case keeps the right customer informed.

188
00:09:26,160 --> 00:09:30,080
When they find the fix, they don't investigate the same outage from scratch for every caller.

189
00:09:30,080 --> 00:09:32,800
Duplicate cases create a similar problem on a smaller scale.

190
00:09:32,800 --> 00:09:35,400
A customer might email and call about the same issue.

191
00:09:35,400 --> 00:09:38,440
Or two agents might open cases before noticing the other one.

192
00:09:38,440 --> 00:09:42,080
Instead of splitting effort, the team can merge similar cases.

193
00:09:42,080 --> 00:09:45,080
One case becomes the main record and the work stays together.

194
00:09:45,080 --> 00:09:47,200
Nobody should solve the same problem twice,

195
00:09:47,200 --> 00:09:50,240
getting a case to the right queue and person starts the work.

196
00:09:50,240 --> 00:09:53,920
And the customer expects a response within the time they were promised.

197
00:09:53,920 --> 00:09:57,120
Keeping promises with SLA's and guided work.

198
00:09:57,120 --> 00:09:59,240
Getting a case to the right person is only half the job

199
00:09:59,240 --> 00:10:01,960
because the customer also expects help within the time you promised.

200
00:10:01,960 --> 00:10:03,560
And that's where a service level agreement,

201
00:10:03,560 --> 00:10:06,120
I'll call it an SLR, comes in.

202
00:10:06,120 --> 00:10:08,080
An SLA attaches a clock to the case,

203
00:10:08,080 --> 00:10:11,000
so the team knows exactly how long they have to meet a customer promise.

204
00:10:11,000 --> 00:10:14,320
Whether it's replying for the first time or fully resolving the issue.

205
00:10:14,320 --> 00:10:15,960
But here, O, to miss the thing.

206
00:10:15,960 --> 00:10:17,800
Those are not always the same deadline.

207
00:10:17,800 --> 00:10:20,720
Take a customer who expects an acknowledgement within one hour,

208
00:10:20,720 --> 00:10:24,680
even if the technical team needs two business days to find and test the fix.

209
00:10:24,680 --> 00:10:27,560
Dynamics 365 tracks the first response target

210
00:10:27,560 --> 00:10:29,280
and a resolution target separately,

211
00:10:29,280 --> 00:10:33,160
so the team can act quickly without pretending every issue can be fixed instantly.

212
00:10:33,160 --> 00:10:35,720
Now, imagine a customer who's service has stopped working.

213
00:10:35,720 --> 00:10:37,880
They don't expect a complete repair in 10 minutes,

214
00:10:37,880 --> 00:10:40,600
but they do expect someone to confirm the problem is known,

215
00:10:40,600 --> 00:10:43,040
explain what happens next and keep them informed.

216
00:10:43,040 --> 00:10:45,360
The first response target tracks that first contact,

217
00:10:45,360 --> 00:10:48,840
while the resolution target tracks the full path to an answer or fix.

218
00:10:48,840 --> 00:10:51,120
And different customers can have different promises.

219
00:10:51,120 --> 00:10:53,800
A company with premium support gets faster response targets

220
00:10:53,800 --> 00:10:55,560
than a customer on a standard plan.

221
00:10:55,560 --> 00:10:59,280
A high priority outage gets a shorter deadline than a routine.

222
00:10:59,280 --> 00:11:00,680
How do I question?

223
00:11:00,680 --> 00:11:04,200
Support agreements, priority and case type all shape the time rules that apply

224
00:11:04,200 --> 00:11:06,080
that keeps the process fair and clear.

225
00:11:06,080 --> 00:11:09,160
Without SLA's, an agent might work from the oldest item in a list

226
00:11:09,160 --> 00:11:11,840
while a time sensitive case quietly passes its deadline.

227
00:11:11,840 --> 00:11:14,760
With SLA's, the case screen shows time indicators

228
00:11:14,760 --> 00:11:17,400
that tell the agent which promise needs attention first.

229
00:11:17,400 --> 00:11:18,760
So you'll see the pressure building.

230
00:11:18,760 --> 00:11:20,760
A case with plenty of time left needs work,

231
00:11:20,760 --> 00:11:24,480
but a case nearing its response deadline needs attention now.

232
00:11:24,480 --> 00:11:26,640
Teams can also set alerts or escalation steps

233
00:11:26,640 --> 00:11:28,800
when a target is close or has already passed

234
00:11:28,800 --> 00:11:31,960
so a supervisor can step in before the customer has to chase the team.

235
00:11:31,960 --> 00:11:36,400
Time targets guide urgency and business process flows guide the work itself.

236
00:11:36,400 --> 00:11:39,800
A business process flow is a set of stages shown inside the case.

237
00:11:39,800 --> 00:11:41,760
It gives an agent a clear pass to follow

238
00:11:41,760 --> 00:11:44,360
based on how the organization once case is handled.

239
00:11:44,360 --> 00:11:47,600
The stages may move from intake to investigation to resolution

240
00:11:47,600 --> 00:11:49,720
with the right questions and checks at each point,

241
00:11:49,720 --> 00:11:52,200
think of it as a checklist with a place in the process.

242
00:11:52,200 --> 00:11:54,560
A new agent doesn't have to guess which details matter

243
00:11:54,560 --> 00:11:56,600
before sending a case to a specialist.

244
00:11:56,600 --> 00:11:58,360
The flow can ask for the product,

245
00:11:58,360 --> 00:12:01,600
issue type, impact, and other information the next team needs.

246
00:12:01,600 --> 00:12:03,440
A more experienced agent can move faster,

247
00:12:03,440 --> 00:12:06,600
but the shared path still keeps the team working in the same direction.

248
00:12:06,600 --> 00:12:09,800
Here's a scenario, a high priority service outage arrives.

249
00:12:09,800 --> 00:12:13,240
The case enters the urgent queue and its SLA starts counting down.

250
00:12:13,240 --> 00:12:15,280
The agent confirms the customer's details,

251
00:12:15,280 --> 00:12:17,720
records the impact and sends the first response

252
00:12:17,720 --> 00:12:19,880
before that response target expires.

253
00:12:19,880 --> 00:12:23,080
Next, the process flow moves the case into diagnosis,

254
00:12:23,080 --> 00:12:26,080
where the team gathers error details and checks for related reports.

255
00:12:26,080 --> 00:12:27,640
The case then moves into resolution

256
00:12:27,640 --> 00:12:29,280
when the team identifies the cause

257
00:12:29,280 --> 00:12:30,920
and prepares the customer update.

258
00:12:30,920 --> 00:12:33,760
That sequence gives managers a clearer picture too.

259
00:12:33,760 --> 00:12:36,040
They can see whether cases slow down during intake,

260
00:12:36,040 --> 00:12:38,520
diagnosis, or the final customer response.

261
00:12:38,520 --> 00:12:40,520
The flow doesn't solve the problem for the team,

262
00:12:40,520 --> 00:12:43,560
but it stops basic steps from disappearing during a busy day.

263
00:12:43,560 --> 00:12:46,760
Dynamics 365 can also control which status changes agents

264
00:12:46,760 --> 00:12:48,240
can choose at different points.

265
00:12:48,240 --> 00:12:50,800
These are called status reason transitions,

266
00:12:50,800 --> 00:12:53,080
which sounds technical, but the idea is simple.

267
00:12:53,080 --> 00:12:55,080
A case should move through sensible steps.

268
00:12:55,080 --> 00:12:57,120
You don't want someone to mark a case resolved

269
00:12:57,120 --> 00:12:59,520
while it still waits for a required internal check

270
00:12:59,520 --> 00:13:02,840
or jump from a new case straight to cancelled without recording why.

271
00:13:02,840 --> 00:13:05,400
The allowed choices can change as the case changes.

272
00:13:05,400 --> 00:13:07,800
For example, a case under investigation may allow an agent

273
00:13:07,800 --> 00:13:10,560
to place it on hold while waiting for customer details.

274
00:13:10,560 --> 00:13:13,760
After the customer replies, the agent can return it to active work.

275
00:13:13,760 --> 00:13:16,280
When the issue is fixed, the case can move to resolve.

276
00:13:16,280 --> 00:13:17,920
That creates a cleaner case history.

277
00:13:17,920 --> 00:13:19,640
A reply alone doesn't finish the work.

278
00:13:19,640 --> 00:13:21,920
The team needs to record how the issue ended,

279
00:13:21,920 --> 00:13:24,040
then close the case properly.

280
00:13:24,040 --> 00:13:26,680
Resolution, learning, and better service.

281
00:13:26,680 --> 00:13:29,040
Sending a reply doesn't automatically close a case.

282
00:13:29,040 --> 00:13:30,520
The team needs to record the resolution,

283
00:13:30,520 --> 00:13:32,360
which means writing down what fixed the issue

284
00:13:32,360 --> 00:13:34,480
or what final answer the customer received.

285
00:13:34,480 --> 00:13:38,000
That might be replacement device sent, duplicate payment refunded,

286
00:13:38,000 --> 00:13:40,720
or customer updated the setting that blocked access.

287
00:13:40,720 --> 00:13:42,680
That note becomes part of the customer record

288
00:13:42,680 --> 00:13:45,040
and it gives the next agent a useful starting point.

289
00:13:45,040 --> 00:13:47,480
If the same customer contact support again months later

290
00:13:47,480 --> 00:13:50,200
with a related problem, sometimes the first fix doesn't work.

291
00:13:50,200 --> 00:13:53,320
Maybe the customer follows the instructions and the error returns.

292
00:13:53,320 --> 00:13:55,920
Maybe a replacement part arrives but doesn't solve the fault.

293
00:13:55,920 --> 00:13:58,320
In that situation, the team can reopen the case

294
00:13:58,320 --> 00:14:00,280
or place it back in a queue for more work

295
00:14:00,280 --> 00:14:03,240
rather than starting a brand new record with no history.

296
00:14:03,240 --> 00:14:05,280
The case continues from where the team left off.

297
00:14:05,280 --> 00:14:06,720
That matters when ownership changes.

298
00:14:06,720 --> 00:14:09,160
A new agent can see what the previous agent tried,

299
00:14:09,160 --> 00:14:11,840
what the customer confirmed, and what still needs checking.

300
00:14:11,840 --> 00:14:13,960
The customer doesn't need to explain the whole story

301
00:14:13,960 --> 00:14:15,920
from the beginning just because a different person

302
00:14:15,920 --> 00:14:16,800
picked up the work.

303
00:14:16,800 --> 00:14:19,520
Over time, all those cases also tell the support team

304
00:14:19,520 --> 00:14:21,600
what's happening beyond one customer problem.

305
00:14:21,600 --> 00:14:23,840
Managers can look at time to resolution

306
00:14:23,840 --> 00:14:27,000
which tracks how long cases take from opening to closure.

307
00:14:27,000 --> 00:14:28,560
They can look at stage time which shows

308
00:14:28,560 --> 00:14:30,040
where cases spend their time.

309
00:14:30,040 --> 00:14:32,400
They can also watch first contact resolution,

310
00:14:32,400 --> 00:14:34,320
meaning how often the first person who speaks

311
00:14:34,320 --> 00:14:36,760
to the customer can solve the issue without a handoff.

312
00:14:36,760 --> 00:14:38,000
Workload matters too.

313
00:14:38,000 --> 00:14:40,080
If one queue fills up every Monday morning,

314
00:14:40,080 --> 00:14:41,200
the team can see it.

315
00:14:41,200 --> 00:14:44,240
If technical cases spend days waiting for an internal check,

316
00:14:44,240 --> 00:14:46,080
that delay appears in the case data.

317
00:14:46,080 --> 00:14:47,640
If one team closes cases quickly,

318
00:14:47,640 --> 00:14:49,280
but customers keep reopening them,

319
00:14:49,280 --> 00:14:50,800
the team has a reason to look closer

320
00:14:50,800 --> 00:14:52,840
at the quality of those first fixes.

321
00:14:52,840 --> 00:14:55,000
The numbers don't explain everything by themselves.

322
00:14:55,000 --> 00:14:57,640
They point the team to what questions worth asking.

323
00:14:57,640 --> 00:14:59,440
Why are cases about one product rising?

324
00:14:59,440 --> 00:15:02,480
Why does a certain case type take longer than expected?

325
00:15:02,480 --> 00:15:05,080
Why are agents repeatedly searching for the same answer,

326
00:15:05,080 --> 00:15:07,240
but not finding a useful knowledge article?

327
00:15:07,240 --> 00:15:10,200
Patterns turn daily support work into practical learning.

328
00:15:10,200 --> 00:15:12,760
A rise in similar cases may point to a product fault.

329
00:15:12,760 --> 00:15:15,240
It may show that a recent update confused customers.

330
00:15:15,240 --> 00:15:18,200
It may reveal that an instruction guide needs clearer steps.

331
00:15:18,200 --> 00:15:20,400
Instead of treating every request as unrelated,

332
00:15:20,400 --> 00:15:22,760
the team can spot the shared cause and work on it.

333
00:15:22,760 --> 00:15:24,400
That can reduce future case volume.

334
00:15:24,400 --> 00:15:26,120
Customer feedback belongs in that picture too.

335
00:15:26,120 --> 00:15:29,040
A closed case may show that the team met its response target,

336
00:15:29,040 --> 00:15:31,000
but the customer may still feel frustrated

337
00:15:31,000 --> 00:15:33,520
if they had to contact support three times.

338
00:15:33,520 --> 00:15:34,960
Looking at both the case history

339
00:15:34,960 --> 00:15:37,720
and feedback gives managers a fuller view of the experience.

340
00:15:37,720 --> 00:15:40,120
Some customers would rather avoid creating a case at all.

341
00:15:40,120 --> 00:15:41,760
That's where a self-service portal can help.

342
00:15:41,760 --> 00:15:44,400
Through a portal, customers can create a request,

343
00:15:44,400 --> 00:15:46,560
check its status, add new information,

344
00:15:46,560 --> 00:15:48,240
or read approved support articles

345
00:15:48,240 --> 00:15:49,880
without calling the support team.

346
00:15:49,880 --> 00:15:53,040
For simple questions, that can save time for everyone.

347
00:15:53,040 --> 00:15:55,040
A customer can check a delivery status

348
00:15:55,040 --> 00:15:57,360
or follow a setup guide when it suits them.

349
00:15:57,360 --> 00:15:59,600
Meanwhile, agents can spend more time on issues

350
00:15:59,600 --> 00:16:01,720
that need a person to investigate, explain,

351
00:16:01,720 --> 00:16:02,880
or make a decision.

352
00:16:02,880 --> 00:16:05,520
Dynamics 365 customer service can also connect

353
00:16:05,520 --> 00:16:08,200
with familiar Microsoft tools around the case process.

354
00:16:08,200 --> 00:16:10,360
An agent may work with email throughout look,

355
00:16:10,360 --> 00:16:13,000
a team may discuss a difficult issue in teams.

356
00:16:13,000 --> 00:16:15,400
Documents and shared information can live in SharePoint.

357
00:16:15,400 --> 00:16:18,120
Power BI can turn case data into reports and dashboards

358
00:16:18,120 --> 00:16:21,040
while power platform tools can support extra forms, alerts,

359
00:16:21,040 --> 00:16:23,760
or automated steps around the team's own process.

360
00:16:23,760 --> 00:16:25,240
Each tool has its own job.

361
00:16:25,240 --> 00:16:27,160
The case remains the place where the support issue

362
00:16:27,160 --> 00:16:28,840
and its history stay connected,

363
00:16:28,840 --> 00:16:31,520
even when people use other tools to communicate, share files,

364
00:16:31,520 --> 00:16:32,720
or review the work.

365
00:16:32,720 --> 00:16:35,520
Case management isn't really about filling out a ticket screen.

366
00:16:35,520 --> 00:16:37,720
It's about giving every customer issue a clear path

367
00:16:37,720 --> 00:16:41,040
or recorded answer and a team that can learn from what happened.

368
00:16:41,040 --> 00:16:42,040
Conclusion.

369
00:16:42,040 --> 00:16:44,000
Keep the whole customer story together.

370
00:16:44,000 --> 00:16:46,040
So here's the real takeaway.

371
00:16:46,040 --> 00:16:49,640
Dynamics 365 case management keeps the issue, the work,

372
00:16:49,640 --> 00:16:52,320
the promise, and the result in one record.

373
00:16:52,320 --> 00:16:54,280
No more lost context or repeated fixes.

374
00:16:54,280 --> 00:16:56,000
Look at your own support process.

375
00:16:56,000 --> 00:16:58,400
Oh, where does customer information disappear?

376
00:16:58,400 --> 00:17:00,960
That's where bringing it all together changes everything.

377
00:17:00,960 --> 00:17:02,960
Subscribe on your favorite podcast platform

378
00:17:02,960 --> 00:17:04,920
for more Microsoft knowledge nuggets from me,

379
00:17:04,920 --> 00:17:07,320
Mirko Peters at M365, FM,

380
00:17:07,320 --> 00:17:08,840
where we explain the Microsoft tools

381
00:17:08,840 --> 00:17:10,680
behind everyday work in plain English.