Contoso Home Services: Triage and Reopen Chaos

Fix at the source first. Make customer mandatory on the portal form and pass product/priority hints from the portal, so the case arrives with usable data rather than being corrected afterwards.

Use the right tool per channel:

• Case creation rules are for interactive defaults and prompts in the app. They are a good fit for phone/agent-created cases where you want the agent to confirm values.
• Power Automate (or a record creation rule for email) is a better fit for portal/API cases, where there is no user to prompt. A flow triggered on case create can look up the contact by email, set customer, derive priority from product, and route to the correct queue. It is asynchronous, retryable, and has visible run history.
• Avoid a synchronous plug-in for this: it runs inside the portal submit call, so a lookup failure surfaces as an error to the customer and blocks case creation. It is also harder to change and monitor.

Verify by creating one test case per channel and confirming customer, priority, queue, and that the rule did not overwrite values an agent deliberately changed. Confirm case creation rule behaviour for portal cases in your environment before relying on it alone.

Duplicates should be merged; related but distinct work should be parent-child.

Merge is for cases that describe the same issue for the same customer:

• Select up to 10 cases for the same customer and choose a primary case.
• Activities and notes from the merged cases move to the primary case, and the others take on a merged state and become effectively read-only.
• This is the right choice for two agents opening a case for the same outage.

Parent-child is for genuinely different work items that belong to a larger effort, such as a repair (parent) and a follow-up parts order (child):

• Child cases can be owned, worked and resolved independently, and the parent rolls up their status.
• This is not a de-duplication tool. Using child cases to hide duplicates inflates case counts, distorts first-response and resolution metrics, and leaves the customer with two live threads.

Set a rule of thumb so agents behave consistently: same customer + same issue within a defined window → merge; different issue or different resolution owner → parent-child. Report merged-case volume separately from child-case volume so the pattern is visible.

Separate waiting from finished. The core problem is that agents use Resolve to mean 'I am blocked'. Introduce an on-hold status reason (for example 'Waiting on parts' or 'Waiting on customer') and tell agents to use it instead of resolving. Then map the SLA pause status reason to that same value so timers behave correctly.

Use Resolve and Cancel for their real meanings:

• Resolve only when the customer's issue is actually fixed, with a resolution type such as 'Problem solved' or 'Information provided'.
• Cancel for invalid or duplicate cases, with a reason. Cancelling is also the correct home for duplicates that are not merged.
• Reopen returns the case to an active status with a distinct reason such as 'Reopened', so it is visible in the queue and in reporting.

Measure: reopen count per case, reopen rate by queue, product and agent, and average time between resolve and reopen. Capture reopen count in a field updated on status change, because the out-of-box history alone is awkward to report on. Present reopen rate alongside resolution time so agents are not incentivised to close quickly.