DocketWise Case-Status Calls: Help Existing Clients Without Losing New Inquiries

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

Existing clients need clear answers and access to their legal team. New callers need a timely first response. A small immigration firm can support both through separate, well-defined call paths.

The direct answer

For an immigration firm using DocketWise, case-status calls should follow an existing-client service workflow. Establish why the person is calling, offer firm-approved help accessing information the firm has shared, and route questions requiring review to the responsible team. Keep this path separate from new-client screening and consultation booking.

DocketWise already provides a client portal where clients can view shared USCIS receipt-tracking information and communicate with the firm. Its client-facing portal guide explains those features. The operational opportunity is to help clients reach the appropriate resource or person while giving new inquiries their own intake path.

Clerx AI Receptionist can support firm-approved inbound conversations and routing. That does not establish permission or technical capability to retrieve and disclose a client's live immigration status. A useful implementation can capture and route a request without reading the case file aloud.

Separate the caller's actual question

"I need an update" can describe several different needs. Someone may want to find a status already shared in the portal. Another person may have received a new notice. A third may be asking what an update means for their work, travel, or family. Those conversations should not receive an identical response.

Start with a short question: "Are you calling about a matter our firm is already handling, or would you like to discuss a new matter?" Then establish the general purpose of the call without requiring a full history.

The new-lead and existing-client routing guide supplies the broader framework. Here, the important distinction is between navigation help, a request for staff attention, and a question requiring legal judgment. Recognizing the difference gives the caller a more useful next step.

Use DocketWise's existing portal before adding another information channel

Review what clients can already access in the firm's DocketWise configuration. DocketWise's portal administration guide documents resource sharing and secure messaging, with settings controlled by the firm.

Staff should know which information has actually been shared with a particular client. An account may have portal access while the relevant resource is unavailable there. Do not tell a caller that a document or update is waiting unless the responsible team has established that fact.

For routine navigation, the receptionist can use approved instructions explaining where an invited client signs in or how to contact staff for access help. It should never request a password or an authentication code.

A portal route should be useful assistance, rather than a way to dismiss the call. If the client cannot use it, cannot find the information, or still needs an explanation, capture the remaining question for the team.

Keep navigation separate from interpretation

Helping someone find the portal is an administrative task. Explaining the legal consequences of a case update is a different task. Approve wording that preserves that boundary.

For example: "Your portal may show tracking information the firm has shared. If you need an explanation of what an update means for your situation, I can send that question to your legal team." That wording does not assert a particular status or tell the client whether to act. It describes the available route.

If the caller reports a new notice or mentions a date, record what they say under the firm's instructions. Let the legal team evaluate the document and its implications. The receptionist should not calculate a response deadline, predict an approval, or decide whether the person can travel.

The firm's escalation policy should identify the kinds of reported developments that need prompt human review. Those rules belong to the attorney and should be specific enough for staff and implementers to follow.

Capture a useful callback request

An existing client should not have to repeat a new-prospect questionnaire merely to reach their team. A practical message can include the caller's name, callback details, person or team requested, broad reason for calling, and preferred language.

Record any reported new document or requested callback window accurately. Ask only for the identifiers the firm has approved for that channel.

The message should preserve the question, not replace it with an assumption. "Caller asks whether the firm received a document" is more useful than "document received" when no one has checked. Likewise, "caller reports receiving a notice yesterday" does not mean staff have reviewed the notice. Clear attribution helps the next person understand what remains to be verified.

If the caller is contacting the firm for someone else, record that relationship and follow the firm's disclosure policy. A familiar phone number or a shared surname should not, by itself, authorize access to case information.

Verify what the Clerx-DocketWise integration actually does

The Clerx DocketWise integration connects intake with the firm's immigration workflow. DocketWise's official Clerx guide documents inbound screening, creation of new cases, and transfer of call summaries and intake information. Those documented new-inquiry capabilities do not establish existing-case lookup, client authentication, portal administration, or case-status disclosure.

Ask the implementer to demonstrate any additional action the firm intends to use. For an existing-client call, identify the actual message destination and staff notification. If attaching a request to an existing case is supported, verify the matching and update behavior. Otherwise, agree on a reviewable staff handoff rather than assuming the new-case workflow is appropriate.

The DocketWise intake integration overview explains the first-contact use case. Evaluate the service branch separately so a repeat client is not automatically treated as another new inquiry.

Give unanswered service requests an owner

The caller needs to know what will happen next, and someone at the firm needs responsibility for making it happen. Assign a primary reviewer and a backup for existing-client messages. Decide when live transfer is appropriate and what happens when the recipient does not answer. The warm-transfer guide helps structure that decision.

Use callback expectations the firm can support. "I have sent your request to the team" should mean the configured handoff succeeded. "Your lawyer will call in ten minutes" requires an actual commitment from the firm. An internal review target is different from a promise made to a client.

Staff should agree who monitors pending requests and how an unresolved one gets attention. The handoff ownership guide is useful for defining completion beyond sending a notification.

Protect capacity for new inquiries

The goal is to make both service and acquisition work well. New prospects may need practice screening, contact collection, language support, and a consultation route. Existing clients usually need a shorter path connected to the team already working with them. Separate branches help prevent either group from receiving the wrong process.

Consider a fictional two-attorney immigration firm. During a busy hour, one person asks how to access their portal, another requests a lawyer's explanation of a notice, and a new prospect asks about a consultation. The first receives approved navigation help, with staff assistance available if needed. The second leaves a clearly attributed review request under the firm's escalation rules. The third enters new-client intake.

These are suggested workflow outcomes, not a claim that every action is available automatically in every account. No MyCase subscription or two-platform architecture is required for this example. It starts with a DocketWise firm's everyday phone traffic.

Make the language and handoff understandable

For a multilingual practice, test the service branch in each working language. A client needs to understand whether they received navigation instructions, submitted a message, or reached a member of staff. Use the immigration language-testing guide to review the complete exchange.

Check names, dates as reported, callback details, and the resulting summary with someone who understands the language. Avoid a fluent greeting followed by an unexplained switch into English for the next step. Where the requested support cannot be provided, use an approved route to the team's language resources.

Also test the transition from phone to portal. Some clients will prefer staff assistance, and a repeated instruction to sign in will not resolve their request. Capture that obstacle so the next person can help without restarting the conversation.

Test a realistic mix of service and intake calls

Before launch, use fictional calls covering an invited client who can sign in, a client with an access problem, a person asking what a reported update means, and a new prospect. Include a third-party caller and an unanswered transfer.

Inspect what the caller hears and what staff receive. Confirm that the service request has an owner, the message preserves uncertainty, and the new prospect reaches the intended intake path. The go-live testing guide provides a way to record expected and observed results.

Treat an incorrect destination or unsupported disclosure as a failed test, even when the conversation sounded natural. Repeat the relevant checks when team assignments, portal instructions, supported languages, or routing policies change. An accurate launch configuration can become outdated as the practice grows.

Measure completed service work alongside intake

Start by tracking the reasons clients call and what happens next. Useful measures include repeat contacts about the same unresolved question, portal-access requests needing staff help, pending service messages, and time spent completing each handoff.

Track new-inquiry response and consultation outcomes alongside those service measures. A faster service branch is not an improvement if it sends clients in circles. More answered calls are not enough if new prospects still fail to reach the next step. The law-firm intake metrics guide provides broader context.

Compare a defined baseline with the pilot rather than assuming time savings or conversion gains. The useful result is straightforward: clients can reach information or the responsible team, and prospective clients receive an appropriate first response. Measure the staff work needed to deliver that result.

Frequently asked questions

Can DocketWise clients see case-tracking information themselves?

DocketWise documents access to USCIS receipt-tracking information shared through its client portal. Availability depends on what the firm has configured and shared. A portal view is not a substitute for the legal team's explanation.

Can Clerx read a live DocketWise status to the caller?

The official integration guide reviewed for this article does not establish that capability. Verify any proposed lookup and disclosure workflow separately, including access controls and firm authorization.

Should an existing-client call create a new case?

Define a separate service route and verify its destination. A new-case integration intended for screened inquiries should not be assumed to handle existing-client requests appropriately.

What if the client cannot access the portal?

Offer approved navigation guidance and route unresolved access problems to staff. The receptionist should not collect passwords or authentication codes.

What if the caller received a new notice?

Capture the caller's description and follow the firm's review and escalation policy. The legal team should assess the notice, its significance, and any required action.

Does this workflow require both MyCase and DocketWise?

No. It is designed for a firm using DocketWise. The relevant requirements are its service process, configured intake connection, portal setup, and staff responsibilities.

Can the same public number serve prospects and current clients?

Yes, with distinct, tested routing paths. The caller's purpose should determine whether they receive new-client screening or an existing-client service response.

What should decide whether the workflow helps?

Review resolved requests, repeat contacts, accurate handoffs, staff effort, and new-inquiry outcomes. Evaluate the observed result without promising that automation will eliminate every callback.

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.