When an Intake Integration Fails: Reconcile Missing MyCase and Clio Records

By Michael Brunman, Co-Founder & CEO of Clerx, Former Litigator

The direct answer

Intake integration reconciliation compares the interactions the firm received with the destination records staff need to act on. When a record is missing, the process identifies the affected inquiry, assigns recovery, and confirms that the next action was completed without creating conflicting duplicates.

This is an operating procedure to arrange with the provider, not a claim that Clerx includes a particular reconciliation dashboard, automatic replay control, or guaranteed delivery mechanism. The MyCase integration and Clio integration establish relevant connected workflows. Account-specific failure handling needs its own demonstration.

For a lean practice, the goal is simple: a software interruption should become visible work rather than an inquiry nobody knows to review.

Define successful delivery by destination

A receptionist completing a call does not prove that MyCase or Clio received the expected information. An email notification does not prove that the responsible staff member reviewed it.

Define success separately for the conversation, contact or lead, summary, appointment, and any payment step. Not every inquiry needs every object. The expected result should follow the firm’s approved workflow.

The intake and practice-management guide helps assign those responsibilities. A clear definition makes it possible to detect a missing handoff without treating every difference as a failure.

Start with a bounded comparison

Choose a review period and compare the relevant interaction list with the destination records. Use approved identifiers such as an interaction reference, timestamp, caller details, and expected next step. Do not rely solely on a name, especially for households sharing a number.

This can begin as a manual check if the tools do not provide a native reconciliation view. Keep the process proportionate to volume and risk. A solo practice does not need an elaborate system to review a small number of exceptions reliably.

The handoff leakage guide addresses ownership. Here the narrower task is to identify which records failed to arrive and confirm repair.

Distinguish delay, omission, and mismatch

A delayed record may eventually arrive. A missing record may require recovery. A record attached to the wrong person needs a different correction from an absent one.

Ask the provider what delivery behavior is expected, how delays are visible, and what evidence is available. Do not invent an acceptable delay threshold or a service guarantee from a general “real-time” description.

For Clio, the official Clerx listing distinguishes Manage communication entries from the Grow Inbox. Search the intended destination before declaring failure. A record in the wrong review location can be operationally missing even when technically created.

Give exceptions an owner and a containment route

Someone should review the affected inquiries and decide which need immediate staff attention. Record the responsible person, next action, and status. Sending a support message is not the same as serving the prospective client.

Use the ownership and escalation framework to separate ordinary repairs from issues affecting appointments or time-sensitive requests. Internal review targets should not become unsupported promises to callers.

If a connection is unavailable, agree the temporary intake route with the provider. That might be a staff-review process using approved information already available. It should not expose sensitive data through an improvised channel.

Avoid blind replay

Retrying a write can create duplicate contacts, notes, or appointments if the first attempt succeeded but its confirmation was lost. Before replaying, establish what reached the destination.

Ask the provider how repeated requests are handled and whether stable identifiers support safe recovery. Do not claim native idempotency or automatic deduplication unless demonstrated. Where uncertainty remains, staff review may be required.

The MyCase repeat-caller record guide covers identity and duplication in normal intake. Reconciliation is different: staff are determining what happened during a delivery problem, not merely matching a returning person.

Separate calendar and payment recovery

A missing note should not trigger another payment request. A missing appointment notification should not be treated as proof that no appointment exists.

Inspect the relevant calendar and payment records before taking financial or scheduling action. Clerx scheduling and payments provides product context, but every connected step needs an observable status in the implementation.

For MyCase, partner documentation describes calendar bookings and optional LawPay collection. For Clio’s own paid-booking workflow, Clio Payments is distinct. Keep these ecosystem relationships accurate during recovery.

Preserve the original account of the inquiry

Staff may need to recreate a missing record from an approved source. Label what was reconstructed and when. Avoid editing the underlying interaction to make the history appear cleaner.

The security checklist supports reviewing access and data handling. Recovery should use authorized systems and people, with the minimum necessary information.

If an incorrect attachment exposed one person’s information in another record, follow the firm’s correction and incident process. That is more consequential than an ordinary missing field and should not be handled as a cosmetic note edit.

A realistic Clio interruption example

Consider a fictional Massachusetts firm receiving six inquiries while an integration permission has expired. The receptionist handles the conversations, but the intended Clio records do not appear.

The first task is to establish the affected period and expected destinations. Staff compare the interaction record with Manage or Grow, review whether any bookings succeeded independently, and identify unresolved next actions.

The provider restores the authorized connection through its supported process. Before replay, staff check whether any delayed records arrived. They then verify that each affected inquiry has one appropriate record and a current owner.

The firm should also decide whether any caller needs an update. A technical repair that creates notes but leaves promised callbacks unfinished has not completed recovery.

Test failure before relying on the connection

Ask for a safe demonstration of missing permission, interrupted delivery, delayed confirmation, and a repeated request. Use fictional information and avoid disrupting live client records.

The go-live testing guide supports expected-versus-observed checks. The weekly quality guide can help maintain sampling after launch.

Count missing records, time to detection, time to operational recovery, duplicate writes, and staff repair effort. These are proposed metrics, not a guarantee that failures can be eliminated. A credible integration is one the firm can verify and recover, not one described as incapable of failing.

Build a recovery record with enough evidence

For each exception, retain the interaction reference, expected destination, observed result, reviewer, and next action. Add the technical issue only when known. A missing record should not automatically be labeled an outage if the actual cause is an incorrect expectation or a staff search in the wrong location.

Keep sensitive content inside approved systems. The recovery record can point to the underlying conversation rather than copying a full transcript into another tool. That makes it easier to preserve access boundaries while still tracking completion.

Record whether the person has already received a response. A repair queue should help staff avoid contacting someone twice merely because a technical record is being reconstructed.

Ask the provider specific reliability questions

Ask how authorization expires, whether delivery errors are visible, what information support needs to investigate, and what happens when a write succeeds but its confirmation is lost. These questions are more useful than asking whether the integration is “reliable.”

Also establish what the firm can do without provider assistance. Some repairs may be available to an authorized administrator; others may require implementation support. Document the distinction so staff do not attempt an unsupported workaround during a busy day.

Where monitoring or alerts are included, demonstrate who receives them and what the notification means. An alert saying a connection needs attention should not be mistaken for a complete list of affected inquiries.

Close recovery through operational evidence

A technical fix is one checkpoint. Recovery is complete when the relevant records are correct and every affected inquiry has reached the approved next action or an explicitly owned unresolved state.

Review a small sample after restoration, including a new inquiry and an existing-client call. Then compare the affected period again to identify delayed records or duplicate writes. Keep the test bounded rather than repeatedly replaying everything.

If a consultation was promised but not confirmed, staff should resolve the appointment status. If a caller received an inaccurate message, the firm should decide what correction is appropriate. These are service responsibilities, not automatic consequences of reconnecting an account.

After the incident, note the detection gap and the smallest useful process improvement. A permission-expiry reminder may address one cause; a destination-review habit may address another. Do not claim a universal fix from a single event. The lesson should follow the evidence and remain proportionate to a small firm’s operating capacity.

Include partial success in the acceptance record

A useful failure test does not simply disconnect everything. Ask what happens when the contact is created but the summary is absent, or when the appointment exists but the staff notification fails. These partial outcomes require different repairs.

The reviewer should establish which parts succeeded before deciding the next action. Recreating the entire inquiry may add conflicting records while leaving the original uncertainty unresolved.

Keep the observed evidence with the recovery decision. A screenshot or log may support internal investigation, but sensitive information should remain under the firm’s approved access and retention rules. Avoid distributing a full transcript when a reference and status are enough.

Test the reverse situation too: the destination record exists, but staff cannot locate it because they searched a different product or view. That is an operating or mapping issue rather than proof of failed delivery.

Finally, ask the provider how the firm learns which inquiries are affected when an error occurs. A connection-level alert may reveal that attention is needed without supplying an itemized recovery list. The implementation should identify how that list will be established.

These checks make the reliability discussion concrete. They help the firm understand both the available controls and the work that remains with its own team.

Frequently asked questions

What is intake reconciliation?

Comparing received interactions with expected destination records, then resolving omissions or mismatches through an owned recovery process.

Does a completed call prove CRM delivery?

No. Check the intended destination and required records separately from the conversation itself.

Does Clerx include automatic replay controls?

Do not assume a particular recovery feature. Ask the provider to demonstrate available controls and required staff steps.

Should staff immediately retry every missing record?

First check for delayed or partially successful writes. Blind retries can create duplicates.

Is a missing summary the same as failed booking?

No. Inspect notes, appointments, and payment status separately before repairing the workflow.

Who should own recovery?

A named firm operator should own client-facing next actions, with the provider responsible for the technical steps agreed in the implementation.

Can this start manually?

Yes. A bounded comparison and clear exception owner can be appropriate for a small practice.

What should be measured?

Detection time, affected inquiries, recovery completion, duplicate records, and repair effort using stable definitions.

Book a demo with Clerx today.

About the author

Michael Brunman is Co-Founder & CEO of Clerx, helping law firms improve client intake and communication. A former litigator, software engineer, and McKinsey consultant with an MBA from Harvard Business School, he brings legal, technical, and business experience to the challenges of running a law firm.