If you landed here, you probably just opened CCC ONE and saw something like:
MT10720 — Unable to process request. The service returned an unexpected response.
A workfile that was supposed to go out to State Farm, Progressive, Geico, or a downstream data subscriber didn't ship. The shop is calling the front desk. The estimator is staring at a red icon. Someone is going to blame the IT guy.
This post is the plain-English version of what MT10720 actually is, what causes it, how to fix it right now, and how to stop it coming back next week.
What MT10720 Actually Is
MT10720 is a CCC-internal message-transport code. "MT" stands for message transport. The number identifies the class of failure — in this case, the outbound envelope reached the CCC transport service, but the service could not hand the payload off to the consuming partner.
It is not an estimate error. It is not a data validation error. The estimate itself is almost always fine. The problem is between CCC ONE on the shop machine and CCC's cloud transport layer, or between CCC's transport layer and the receiving trading partner.
You see it on three kinds of actions:
- Secure Share sends to insurance carriers, rental partners, or parts procurement services.
- API-driven workfile pushes when an integrated platform (yours or a vendor's) tries to pull or push a workfile programmatically.
- Supplements where the follow-up estimate has to re-register with the carrier's claim record.
The Three Real Causes (In Order of Frequency)
1. The CCC ONE Workfile service stopped or got wedged
This is roughly 60% of cases. The local Windows service that handles outbound messages has either stopped, hit a memory issue, or is still running but stuck on a previous send that never completed. Restarting the service usually clears it.
To check: on the shop machine, open services.msc and look for CCC ONE Workfile Service. If it is not Running, start it. If it is running but you are still getting MT10720, stop it, wait 10 seconds, and start it again.
2. Secure Share authentication drifted
Secure Share subscriptions are tied to credentials that periodically rotate. If a partner rotated their side, or the shop's token expired, every send after that expiration will throw MT10720 until someone re-authenticates.
To check: open CCC ONE, go to Configure → Secure Share → Subscriptions, and look for any subscription that is not green. Click into it and re-enter credentials or re-trigger the auth handshake.
3. TLS / certificate trust on the shop machine is broken
This is the one that takes longest to find. Windows updates, antivirus root-store tampering, or expired intermediate certificates can all make the outbound HTTPS handshake fail. CCC surfaces that as MT10720 because — from its point of view — the service returned an unexpected response (nothing, in this case).
To check: open a browser on the shop machine and try to hit https://secureshare.cccis.com. If the browser warns about the certificate, you've found it. Fix the cert store, reboot, try the workfile again.
The Fix Sequence That Clears ~90% of MT10720 Cases
- Restart the CCC ONE Workfile service on the affected machine.
- Re-send the blocked workfile. If it goes, you're done.
- If still failing, re-authenticate Secure Share subscriptions from Configure → Secure Share.
- If still failing, check certificate trust by hitting the CCC Secure Share URL in a browser on the same machine.
- If it's still failing and you see MT10720 on multiple machines, it is almost certainly a CCC-side incident or a trading-partner outage. Open a ticket with CCC and attach the workfile ID plus exact timestamps. Do not let the ticket sit in triage — MSOs with large volumes should escalate the same day.
What Usually Doesn't Help
- Rebuilding the workfile from scratch. The estimate content is not the problem.
- Uninstalling and reinstalling CCC ONE. Occasionally fixes it, but almost always by side effect (it resets the service and clears credentials).
- Trying again tomorrow. Sometimes it clears on its own when the partner's transport recovers. But if the root cause is on your side, it will recur.
How MSOs Make MT10720 Stop Mattering
The real pain of MT10720 isn't any single occurrence — it's discovering an hour later, or the next morning, that a handful of sends failed silently and nobody pushed them through. That's how a State Farm DRP score slips or a parts vendor misses a cutoff.
The fix we've built for MSO customers is a small watcher job that runs against CCC ONE's event log and the Secure Share send history. It does three things:
- Alerts in Slack (or email, or Teams) the instant an MT10720 is logged at any shop.
- Automatically retries the send after a configurable delay.
- Keeps a rolling count so leadership can see "we had 4 MT10720 events this week, all at Shop 7" — which is how you catch a machine-specific problem before it becomes a carrier-relationship problem.
A single shop can live without this. Anything over five shops, and the silent-failure risk is real. At 20+ shops, the first time you catch a cascade before the carrier does, it pays for itself.
TL;DR
- MT10720 is a CCC message-transport error, not an estimate error.
- Most cases are fixed by restarting the CCC ONE Workfile service and re-authenticating Secure Share.
- Stubborn cases are usually certificate/TLS trust on the shop machine.
- MSOs should not be finding out about MT10720 from CSRs — they should have a watcher that alerts and retries automatically.