Customer support office workflow for legal practices

Planning model: arrival, context, ownership, continuation

Use four stages to plan the workflow:

1. **Arrival:** give visitors one clear reception link and a public boundary statement. 2. **Context:** collect only name, organization or relationship, and general purpose. 3. **Ownership:** route to an intake role, client-service host, matter team, or shared queue. 4. **Continuation:** use chat, browser phone, video, screen sharing, or a private room only when the practice's own process permits it.

This model keeps the public experience understandable without pretending that Kiguri is a legal intake, conflicts-checking, document-management, or compliance system. Start with the [Kiguri customer reception](/) and review the Kiguri guides.

Stage one: make the public boundary clear

Open with a branded reception message that says what visitors can request and what they should not submit publicly. Explain that an inquiry is for routing and general orientation, does not automatically create an attorney-client relationship, and does not guarantee representation or a response. The practice should review and approve its own wording.

Do not invite detailed facts, privileged communications, opposing-party information, passwords, or confidential documents. If a visitor begins sharing sensitive information, use the practice's approved message to pause and redirect to a secure process. Public arrival should be easy without encouraging unsafe disclosure.

Stage two: collect limited support context

Use plain-language purpose choices such as existing-client service, request an introductory conversation, referral partner, or general office question. Ask for a name and organization or relationship context only when the practice can safely use it for routing. Add a short free-text explanation, not a full case narrative.

The AI receptionist can answer approved general questions about the office and how to request a host. It must not give legal advice, analyze a dispute, recommend a strategy, predict an outcome, or imply a lawyer reviewed a message. When a visitor needs legal judgment, the next step is a human through the practice's process.

Stage three: make ownership visible

Assign an owner and backup for each purpose. Intake staff may review prospective-client requests. Client-service staff may handle administrative questions. Existing matters may route to a designated team. Referral partners may have a relationship contact. A general queue can catch requests that do not fit.

Kiguri includes employee roles, member presence or status, and a shared response queue. Use those signals to offer a live handoff only when someone can actually continue. Presence is not acceptance of a matter, a conflicts check, or a promise of legal advice.

When nobody is available, confirm that the inquiry has been received and explain the follow-up process. Preserve non-sensitive context for the next owner. If a different person joins, explain the role and avoid asking the visitor to repeat unnecessary information.

Keep queue states simple and meaningful: new, claimed, waiting for visitor, waiting for practice review, and complete may be enough. The exact labels should match the practice's work. A queue is not a matter record, and moving an inquiry to “claimed” should not imply that a lawyer has accepted representation. Tell visitors what each public status means and keep internal case details out of the map and AI answers.

Define an after-hours rule. The practice may allow a visitor to leave a general inquiry, or it may direct them to an approved office channel. Either way, write the message before launch and review it when staffing changes. Avoid language that suggests a legal deadline, emergency response, or guaranteed review unless the practice has deliberately established that process.

Stage four: choose a controlled continuation

Chat may handle an office direction. Browser phone or video can support an approved introduction. A private consultation room can be used after the practice handles identity, authorization, and confidential communication through its own process. Screen sharing should be limited to a clearly approved, non-confidential purpose.

Kiguri supports reception-only entry, approved destinations, visitor access rules, and private consultation rooms. Use the Kiguri map preview to separate public reception from practice areas. Do not describe a room or channel as proof of privilege, confidentiality, security, or compliance.

Review the workflow with intake staff

Test a prospective client, existing client, referral partner, general visitor, and after-hours request. Check whether the reception asks only approved questions, whether the queue shows enough context, and whether visitors understand that an inquiry may wait.

Read real threads with the appropriate practice stakeholders. If visitors share too much, shorten the intake and strengthen the boundary message. If staff cannot tell the purpose, revise the choices. If a channel is too complex, keep the request in chat. Do not claim better outcomes, response times, confidentiality, security, or compliance without practice-approved evidence.

Close each support exchange with an explicit owner and next operational action. The host can tell the visitor whether another team member will follow up, whether the visitor should use a secure channel, or whether the inquiry remains in a queue. This keeps the front desk from becoming an accidental promise of legal advice or representation.

Review retention and access settings with the responsible owner. Confirm current Kiguri pricing, visitor rules, and workspace limits before publishing a capability or plan promise.

Train every host on the same public boundary so visitors receive consistent guidance across offices and time zones. Revisit the script whenever the practice changes its approved channels or intake policy, staffing, or public message, as needed, for consistency.

Consistent wording helps the practice avoid accidental promises in every location.

FAQ

Is Kiguri a legal support or matter-management system?

No. It provides customer-facing reception, bounded intake, employee routing, and controlled destinations. The practice remains responsible for legal work and records.

Can the AI answer a client’s legal question?

Use only approved general information about the practice and reception. Route matter-specific questions to an authorized human through the practice's own process.

Can one workflow serve prospective and existing clients?

Yes. Visitor-friendly purposes and relationship context can route each inquiry while preserving one recognizable arrival.

What if no staff member is available?

Keep the inquiry in a response queue and give an honest follow-up message. Do not promise representation or immediate legal review.

Make support helpful without expanding the public intake

A legal-practice support workflow should make the next human owner clear while limiting what the public front door collects. Kiguri brings together branded arrival, bounded AI intake, roles, presence, queue ownership, and controlled destinations while the practice retains legal and confidentiality responsibilities.

[Explore Kiguri](/) and design a support office around the processes your practice can actually maintain.

Sources and further reading

• [Kiguri customer reception](/) • Kiguri pricing and plan overview • Kiguri map preview • Kiguri guides

Sources and further reading

Kiguri product overview, Kiguri pricing, security information, and Kiguri guides.