MyCase Intake Duplicate Records: A Repeat-Caller Workflow for Immigration Firms

By Michael Brunman, Co-Founder and CEO of Clerx

The direct answer

To reduce duplicate MyCase intake records, define when an incoming conversation belongs to an existing contact, when it represents a new inquiry, and when staff must review an uncertain match. A phone number helps locate a record. It does not prove that two callers are the same person or that two requests concern the same matter.

For an immigration firm already using MyCase, the useful unit is a person with a history of inquiries and interactions. One family may share a phone. One person may ask about several relatives. A prospective client may begin on website chat and call again before the team has reviewed the first message. Treating each interaction as a fresh lead can distort both client service and reporting.

This is a workflow design problem as much as a software problem. The Clerx and MyCase integration supports connected intake information and call summaries. The firm should separately verify the matching, record-creation, and exception behavior configured for its account.

Distinguish four things before changing the software

A contact is a person or organization. An inquiry is a request for help. An interaction is one call or message. A matter is the firm's case-management record, created according to its policies. These can have different relationships.

Consider a fictional prospect, Elena. She chats about a family petition, calls the next morning from her husband's number, and later asks whether the firm handles a separate employment issue. That is not necessarily three people, one matter, or three new marketing leads. The first task is to preserve what happened without making unsupported assumptions.

The distinction between practice management and intake software helps assign responsibility. Intake gathers the information needed for review. The practice-management system holds the authoritative working records. A conversation summary should not silently redefine the firm's contact or matter policy.

Write these definitions into the intake playbook. Staff, software implementers, and the person reviewing reports should use the same vocabulary. Otherwise an apparent improvement in lead count may simply reflect more duplicate entries.

Build a matching policy that tolerates uncertainty

Start with the clues the caller can comfortably provide: name, callback number, preferred email when available, and whether they have contacted the firm before. Ask a short question such as, "Have you already spoken or exchanged messages with our office about this request?"

A confirmed existing reference can be useful. A similar name is weaker. A phone number shared by family members is ambiguous. If the caller identifies another person as the potential client, record both roles without turning the helper into the applicant.

Define three outcomes: a confident match handled through the approved update path, a clearly new contact handled through the creation path, and an uncertain match assigned for review. These are recommended operating categories, not claims that every integration exposes these exact controls.

Never disclose information from a candidate record merely to test whether the caller recognizes it. Ask the caller to supply identifying context and use the firm's verification process. The AI receptionist security checklist is a useful companion when evaluating access and information handling.

Keep identity separate from conflict review

Finding an existing person does not establish that the firm can accept the new request. Nor does failing to find a match establish that there is no conflict. Identity handling and professional conflict review serve different purposes.

The ABA's prospective-client rule addresses duties involving information learned from prospective clients. The operational implication is to gather only what the next review requires and protect it appropriately.

Use the AI intake and conflict-check workflow to define when the conversation pauses for staff review. An uncertain identity should not trigger a longer collection of sensitive facts just because the software wants more fields filled in.

Decide what happens across phone, chat, and SMS

A caller should not need to repeat a full story because they changed channels. Yet joining conversations automatically without reliable identity information can attach one person's facts to another person's record.

At the channel transition, preserve the interaction time, supplied identity details, broad request, current status, and responsible staff member. If the firm sends an approved booking link, make sure the team can connect the resulting appointment to the reviewed inquiry.

Website chat intake and text-message intake can support continuity with phone intake. Demonstrate that continuity using your configured system. Ask which fields identify the person, which identify the inquiry, and what happens if the sender uses a different number.

For a two-attorney practice, a small exception list reviewed each morning may be more useful than complicated rules nobody maintains. The important result is a visible unresolved match, rather than an invisible wrong match.

Design the update path before the create path

New-record creation is easy to demonstrate. Repeat contact is a better test of daily usefulness. Give the implementer an existing test contact and ask them to run the same inquiry twice through Donna's inbound call workflow.

Check whether the second conversation preserves the original record, produces a separate interaction, overwrites a useful fact, creates a second contact, or stops for review. Record the observed behavior. Then test a person with the same surname, a shared phone, and a new matter request.

Do not use automatic merging as a substitute for a review policy. Merging can erase useful distinctions, and the wrong merge may require substantial correction. Confirm available permissions, history, and recovery procedures before enabling any destructive cleanup operation.

Where an update fails, the caller-facing response and staff-facing record should remain honest. "Your request has been received for review" is different from claiming the consultation or matter record is complete.

Give staff a short reconciliation routine

Assign one owner to review possible duplicates and unmatched interactions. For each exception, show the incoming details, candidate record reference, reason for uncertainty, time received, and next action. Keep access limited to those who need it.

The reviewer should confirm identity through the approved process, attach or document the interaction appropriately, and close the exception with a reason. If the same pattern recurs, change the matching instructions instead of asking staff to repair it forever.

The guide to preventing intake handoff leakage explains the broader ownership problem. Here, ownership means someone is accountable for unresolved identity, not simply notified that another message arrived.

Keep original source information when adding later interactions. A repeat call should not automatically replace the acquisition source or restart the response-time clock. This allows reports to distinguish new demand from ongoing conversation.

Measure cleaner records without hiding work

Use a small baseline sample before launch. Count distinct reviewed inquiries, contacts created, possible duplicates, incorrect matches, and minutes spent on reconciliation. Repeat the measurement after a comparable period and describe any change in channel mix.

An illustrative calculation: if staff spend four minutes repairing each of fifteen duplicate contacts, that is sixty minutes of repair work. It does not establish the software will save an hour. It identifies an existing task that a pilot can measure.

The intake metrics guide provides broader context. For this workflow, a useful indicator is the share of repeat interactions correctly associated after review. Pair it with wrong-match incidents so that a lower duplicate count cannot conceal more misidentification.

Avoid using this operational improvement as a promise of immigration outcomes. The goal is a reliable record and clear next action, with legal analysis remaining with the attorney.

A practical demonstration brief

Bring fictional examples rather than confidential live files: one repeat caller, one shared family phone, one alternate spelling, one person with a new request, and one interrupted integration attempt. Ask the vendor to show the downstream records after each scenario.

The MyCase integrations overview independently lists Clerx among its integrations. That confirms the relationship; it does not certify every identity rule your firm needs.

Some immigration firms use 8am DocketWise, an immigration-specific platform, instead of or alongside MyCase. This article is specifically for firms already using MyCase. If both systems are in use, designate which system owns each record and verify the additional handoff separately.

A worked repeat-caller example

Imagine a two-attorney immigration firm already using MyCase. A prospective client chats on Monday, then calls on Tuesday because she has not received a confirmation. Her husband supplies the callback number during the second interaction. The receptionist should preserve both conversations and the relationship between the people, while avoiding a premature merge.

The staff reviewer finds the original inquiry, confirms the identity through the approved process, and records the second interaction against the appropriate record. If Tuesday's call introduces a different person's request, it remains distinguishable. The review result should explain the action rather than merely mark the exception complete.

Now change one fact: the second caller gives the same surname but a different prospective client. The workflow should tolerate that difference without forcing a match. Comparing those two test cases reveals whether the implementation is preserving identity or merely reducing the number of visible records.

This example is fictional. Its purpose is to make acceptance criteria observable: retain the conversation, avoid unauthorized disclosure, resolve uncertainty with an owner, and preserve the original inquiry history. It does not imply that a matching rule alone can eliminate all duplicates.

Frequently asked questions

Does connecting Clerx to MyCase automatically remove duplicates?

Do not assume so. The public integration description supports connected intake and summaries. Ask for a demonstration of matching, updates, duplicate handling, and staff review in your actual configuration before relying on any automated cleanup.

Is a phone number enough to match a caller?

It is a useful clue, but families can share numbers and people can change them. Use the firm's approved identification process and send ambiguous matches for review rather than exposing an existing record.

Should every call create a new matter?

Only if that follows the firm's approved policy for that specific call. Repeat inquiries, existing-client messages, and family-member calls may require different handling. Keep contact, interaction, inquiry, and matter decisions separate.

What if the prospective client uses a different name spelling?

Preserve the spelling supplied in the current interaction and flag the possible match for review. Avoid silently overwriting an established name or joining records solely because two spellings appear similar.

Can one family have several contacts?

Yes. A shared household does not make everyone the same client. Record who called, who needs help, and the relationship between them. The attorney determines representation and the appropriate matter structure.

What should a failed update trigger?

A visible exception with an owner and a callback or review plan. Do not tell the caller that the downstream system has been updated unless the configured workflow can verify that result.

How can a small firm test this affordably?

Use a small fictional dataset with deliberate repeat inquiries and ambiguous identities. Inspect the resulting records, record staff repair time, and expand only after the update and exception paths behave as agreed.

What should the demo prove?

That the same person can return without losing context, a different person is not wrongly matched, and unresolved cases reach staff. Those outcomes matter more than watching a single new contact appear.

Book a demo with Clerx today.