Using MyCase and DocketWise Together: Define One Immigration Intake Handoff

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

The direct answer

An immigration firm using MyCase and DocketWise should define which system owns the initial inquiry, consultation record, accepted engagement, and immigration preparation work. Clerx can support configured intake connections, but two available integrations do not establish automatic synchronization between the two practice systems.

8am DocketWise is an immigration-specific platform. 8am MyCase is a broader practice-management platform that also offers immigration-related capabilities. Some firms use one; some use both. This article is specifically for firms already using both and deciding how intake should reach their team.

The Clerx MyCase integration and Clerx DocketWise integration should be demonstrated separately. The goal is an owned handoff, not the largest possible number of duplicate records.

Begin with how the team already works

Ask where staff first review inquiries, where appointments are managed, and where accepted work proceeds. Do not redesign the entire practice merely to accommodate a new receptionist.

For each stage, name the person who acts and the information they need. A solo owner may perform several roles but still benefit from clear record boundaries.

The intake and practice-management guide helps separate the conversation from downstream case work. The receptionist’s task is to support the next approved action, not to choose which platform the firm should use for legal production.

Choose one initial review destination

If both systems receive an inquiry, staff need to know which record governs the next action. Without that rule, two people may follow up or both may assume the other team is handling it.

The initial destination might be the system the intake assistant already reviews. The firm should base the choice on supported capabilities and its operating process rather than a presumed default for immigration practices.

Use the handoff ownership framework to establish a reviewer, backup, and completion evidence. A record created in two systems has not necessarily received more attention than one created in the right place.

Define the minimum shared context

The first handoff usually needs contact details, broad inquiry, reported location where relevant, working language, contact preference, and agreed next step. Preserve caller-reported dates without converting them into verified legal deadlines.

The intake-question guide can keep this concise. Immigration preparation may eventually require extensive information, but that does not mean the receptionist should collect it all before arranging an initial review.

Label unknowns and avoid inferring status, eligibility, or representation. The lawyer should decide legal issues and approve the information required for each stage.

Verify each connection on its own terms

MyCase’s official Clerx guide describes contacts, notes, consultation calendar entries, and optional LawPay collection. Those facts support a MyCase-centered intake demonstration.

For DocketWise, review the current official materials and show the actual destination and fields. Do not infer read access, write actions, deadline calculation, or two-way updates merely from a partner logo or a description of immigration workflows.

The firm should retain a short capability record: what was demonstrated, what the proposal includes, what staff must do, and what remains unverified. This makes the configuration reviewable without overstating the product.

Keep consultation ownership explicit

Choose which calendar governs consultations. Confirm appointment types, attorney availability, duration, time zones, and the route for changes. Do not assume bookings should be created independently in both systems.

Clerx scheduling and payments provides context for supported consultation workflows. If LawPay is included, verify the configured payment process separately from calendar creation.

An appointment request, confirmed booking, payment, and accepted engagement are different events. Staff should know where each can be verified and which system supplies the current status.

Decide when an inquiry advances

The team should define when a prospect becomes accepted work and what information must move at that point. This may require staff review rather than an automatic action after a call.

The intake and conflict-review guide helps preserve attorney decisions. Capturing names does not establish conflicts clearance, and paying for a consultation does not automatically establish a broader engagement.

If staff transfer information between systems, document the minimum required information and verification step. A manual bridge can be appropriate when it is explicit, bounded, and consistently owned.

Maintain context across conversations

A prospective client may begin by phone and return through the website. Clerx website chat can support configured written intake, but the team should verify where that conversation goes and how it is associated with the original inquiry.

For text messaging, review contact preferences and booking instructions. A shared number should not automatically merge two people’s inquiries.

The immigration language-testing guide is relevant to comprehension. This article’s separate concern is where the information reaches staff and who owns the next action.

A two-system example

Consider a fictional Texas immigration firm. Its operations lead reviews new inquiries in MyCase, while the legal team uses DocketWise for immigration-specific preparation after acceptance. The firm wants the receptionist to reduce initial note entry.

The pilot should show a new inquiry reaching the intended MyCase destination, a consultation following the configured calendar route, and a staff-approved transition into subsequent work. It should not create parallel active intake processes merely because both integrations are available.

Now test an existing DocketWise client calling about a current matter. That person may need a service route rather than another MyCase sales lead. The system should use the firm’s caller classification and escalation policy without offering legal status interpretations.

Finally, test an inquiry that remains unaccepted. It should retain a clear record without being described as an active immigration case simply because a software object was created.

Review failures and completed handoffs

Use the pre-launch testing process to examine a missing record, wrong destination, duplicate inquiry, and unclear transition. Check what staff can actually observe.

Measure whether each inquiry has one current owner, whether staff repeat data entry, and whether accepted work carries the approved context. These are proposed operating measures, not a claim that using two platforms inherently improves conversion.

The right architecture fits the team’s work. More integrations are useful when they reduce uncertainty, not when they create additional places where an inquiry can be forgotten.

Decide what does not need to move

Not every fact belongs in both platforms. A prospective inquiry may need only enough context for review, while later immigration preparation may use more detailed information. The firm should approve the minimum necessary transfer for each stage.

Avoid building a parallel copy of the entire file just because an integration can create records. Duplicated information can become inconsistent when staff update one system and assume the other changed too.

Ask which fields can be transferred, which are authoritative, and how changes are handled. If synchronization is one-way or limited to a particular event, describe it that way. A narrower connection can still serve the workflow well when the team understands its limits.

Design around one realistic working day

Have the intake owner walk through a day containing a new prospect, an existing client, a booked consultation, and an accepted engagement. Identify where they start each task and what tells them it is complete.

Then repeat the walkthrough with the legal team. The same information may support different work at different stages, but responsibility should not disappear between them.

If both teams maintain separate status lists, explain how disagreements are resolved. For example, a consultation might appear completed in one list while acceptance remains unresolved in another. Those states can coexist if they are labeled clearly; they become a problem when staff treat one as proof of the other.

Review the handoff when the service mix changes

An immigration practice may add another consumer service or hire an assistant who works primarily in one platform. Review whether the original ownership map still fits the team.

The answer may be a small routing change rather than a new integration. Keep the platform names out of generic screening questions unless they help the caller. Prospective clients should experience one coherent office even when several tools support it.

For buying purposes, distinguish configuration work from product capabilities. A vendor may support contacts and summaries while the firm still needs to decide who reviews them and how accepted work advances. That planning is part of implementation, not evidence of a missing legal feature.

A clear two-system design lets the firm evaluate incremental value. Ask what work Clerx removes, what remains with staff, and how the result will be observed. Do not justify another layer simply by naming all the systems it could connect.

Account for the native MyCase-DocketWise connection

The platforms also offer their own connection. DocketWise’s official MyCase integration guide documents synchronization of contacts and matters or cases, with configuration and subscription requirements. Review the current supported attributes and direction in your accounts.

That native connection is distinct from Clerx sending intake information into either platform. Its existence does not prove that every Clerx-created record, summary, appointment, or intake status will propagate as the firm expects.

Bring all relevant connections into one implementation map. Identify the original write, any native synchronization that follows, and the destination the team should review. This can prevent staff from mistaking normal downstream synchronization for a second independent intake event.

Test a new contact, an existing contact, and an updated detail using fictional data. Inspect both systems before deciding which changes need a manual bridge. Do not build unnecessary duplicate entry around a native capability that already supports the requirement.

Conversely, do not assume the native link carries every field needed for the next action. The firm should verify its actual scope and assign any remaining step. The resulting design should reflect demonstrated behavior across the complete chain.

Frequently asked questions

Are MyCase and DocketWise the same product?

No. They are distinct 8am platforms. DocketWise is immigration-specific; MyCase is broader and also offers immigration capabilities.

Must immigration firms use both?

No. This article addresses firms already using both. The right platform setup depends on the firm’s work and verified requirements.

Does Clerx synchronize MyCase with DocketWise?

Do not infer inter-platform synchronization from two integration listings. Verify each supported connection and any separate transfer process.

Where should new inquiries go first?

Choose the supported destination the responsible intake owner actually reviews, with a clear backup and next-action policy.

Should consultations appear twice?

Do not create independent bookings without a deliberate design. Identify the authoritative calendar and demonstrate any additional visibility.

Can staff move accepted work manually?

Yes, where the bridge is explicit and verified. Manual work should have a defined owner, required information, and completion check.

Can AI decide immigration eligibility?

No. Intake can record approved information and route it. Legal analysis and representation decisions remain with attorneys.

What should decide success?

One current owner, correct destinations, accurate consultation status, preserved context, and measured reduction in avoidable re-entry.

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.