Skip to main content

Format A: Regular Enquiry

1.

. Metadata

General description

A Regular Enquiry is the default, full client lifecycle flow used when a website enquiry is routed into BackOffice as a standard legal/professional matter (not pre-flagged as Paid Consultation only and not a pre-packaged Direct Service). The process runs from website form submission, through autoassignment, Strategy Guide and status management, to payment recording, completion, survey and eventual anonymisation/deletion under GDPR rules.

Regular Enquiries use the full Strategy Guide and quotation mechanism, require manual status progression by the assigned User, and rely on accurate payment declarations in the Payments tab for commission and invoicing. They are the primary way most client matters move through the system, across Property, Family, Administrative, Probate and other law categories.


text
id: regular-lead-enquiry
system:
[Website,
BackOffice,
Laravel]
type:
process applies_to_roles: [Client, User, Admin] related_ETs: [All standard Enquiry Types configured as Regular Enquiry (not Paid Consultation-only, not Direct Service-only)]

2. BusinessSpecific Overviewgoals (for& Developers)

objectives

The Regular

Enquiry (Regular
Lead)
is
the
standard
workflow
for high-value,
commercially
interesting legal
and
professional
services
such
as
Property Purchase, Inheritance, Divorce, Litigation, Business Set-Up, etc. It covers all channels through which a serious client can arrive: Website forms, telephone calls to the Elevenlabs AI Receptionist, and email enquiries (both direct to lawyers and via generic inboxes like info@).​

Business-wise, this workflow exists to ensure that commercially attractive leads are contacted fast, on-platform, and progressed through a consistent lifecycle: Intake → Strategy → Offer → Engagement → Payment → Completion → Closure, with clear audit trails and commission tracking. It differs from Paid Consultation and Direct Service in that it assumes a full engagement is the target outcome, with a formal Strategy Guide and an Offer Email generated and sent from within BackOffice, and full application of the 24-Hour Rule and reminder/expiry logic.

Success is defined by:

  • AAEnsure (Admin)that takingevery controlvalid ofwebsite the firstform contact submission is converted into a BackOffice client record with the clientcorrect Enquiry Type (ET), country, and initial status (New Enquiry or NPD – Awaiting Assignment).

  • Route each enquiry to avoidan losingappropriate themprofessional tovia competitorsautoassign, taking into account ET, country, profession and toavailability; preventif off-platformthis communication.fails, mark as NPD and alert Admin.

  • Enforce a status-driven lifecycle (New Enquiry → Created Lead → In Progress / Waiting for Response → Completed → Closed or Eliminated), with popups for elimination reasons and completion/payment confirmation.​

  • UsersMaintain workingaccurate, strictlyauditable viapayment BackOffice (emails, strategy, payments)data, so that commissionthat invoices and performance commission statements can be monitoredgenerated automatically and invoicedtied correctly.to recorded Payments entries.

  • LeadsMaintain eithera convertingfull audit trail of activity via the Updates Record, including status changes, ET changes, NPD events, assignment, payments, and Admin interventions.

  • Support GDPR-compliant retention, with anonymisation and deletion applied automatically to ongoinginactive workenquiries (Inaccording Progressto →configured Completed → Closed) or being clearly eliminated/frozen, with appropriate follow-up rules and GDPR anonymisation.timelines.

3. GoalsStep-by-step procedure (Regular Enquiry lifecycle)

3.1 Website submission & Non‑Goals

record

Goals

creation

Non‑Goals

4. Actors & Scope

Actors

Scope

5. Step-by-Step Workflow

Phase 1 – Intake & Classification

Preconditions

Actors

User Actions (Admin Intent)

System Behaviour

UI Elements

Phase 2 – 24-Hour Rule, Assignment & Scheduling

Preconditions

Actors

User Actions

System Behaviour

UI Elements

Phase 3 – Strategy Formulation (Strategy Guide)

Preconditions

Actors

User Actions

System Behaviour

UI Elements

Phase 4 – Meeting & Offer Email

Preconditions

Actors

User Actions

System Behaviour

UI Elements

Phase 5 – Client Response, Reminders, Freeze & Expiry

Preconditions

Actors

User Actions

System Behaviour

Expiry logic (Ongoing leads)

UI Elements

Phase 6 – Engagement, Payment & Completion

Preconditions

Actors

User Actions

System Behaviour

UI Elements

Phase 7 – Closure, Anonymisation & Backend Accounting

Preconditions

Actors

User Actions (Admin)

System Behaviour

UI Elements

6. Edge Cases, Confusions & Common Errors

IssueCause / ExplanationResolution / Best Practice
Offer Email sent but User “sees nothing” in Emails tabNo active conversation thread until client replies or payment added; UI doesn’t highlight the outbound offer. ​Educate Users to check Emails tab sent items; consider UI enhancement later (but behaviour is currently as designed). ​
Misclassification (Regular vs Paid Consultation vs Direct)Admin misjudges commercial relevance / client intent at intake. ​Admin can reclassify ET/flags early; ensure classification guidance is clear in Assignment Interface.
Multi-ET (multi-service) cases are complexCurrent process for multiple ETs in a single Offer Email is complicated. ​Use Additional Services and carefully constructed Strategy/Offer; future AI-based Intelliquote may simplify. ​
Intelliquote confusionUsers unsure what fee to propose; Intelliquote concept not yet implemented. ​Current state: User uses default fee ranges & personal judgement; Intelliquote is a future AI enhancement only. ​
Contact details maskedClient contact info is hidden until Strategy Guide is completed. ​Complete Strategy Wizard to unmask; this enforces on-platform strategy preparation before direct contact. ​
24-Hour Rule unassigns lead unexpectedlyUser did not Accept/Reject within 24 hours. ​Ensure Users know to act quickly; Admin reassigns from NPD; consider adjusting comms and training.
Cannot mark Completed / cannot Eliminated with paymentsHard rules: Completed requires payments; Eliminated disallowed if payments exist. ​Correct payments or status; follow financial audit requirements. 

7. Permissions & Access Control

8. Timing, Automation & Background Jobs

Underlying jobs use:

9. Related Processes & Dependencies

Prerequisites

Dependencies

Downstream triggers

10. Error Recovery & Retry Logic

ScenarioSystem BehaviourRecovery
Auto-assign or 24h rule leaves NPDStatus NPD; Admin alert; NPD banner. Admin uses Unassigned Leads / NPD tools to assign or mark Not Proceeding.
Elevenlabs/email enquiry not convertedContact remains outside BackOffice; risk of unmanaged PII. ​Admin must create/import a Client record, send Authorization email for GDPR consent, classify.
Offer Email send failureEmail not sent; error surfaced.Retry sending; if persistent, escalate to technical support.
Payment mismatch on CompletedCompletion wizard blocks and warns. Correct Payments tab entries; re-attempt completion.
Freeze mis-configuration (wrong Next Date)Lead may not unfreeze when expected, or unfreezes too early/late. ​Admin/User adjusts Next Progress Date; system re-evaluates Expired/Freeze logic.

Most user-level retries (resend Offer, re-save Strategy, re-change status within rules) are safe but may generate duplicate client emails; automated retries should be implemented cautiously to avoid spam.

11. Configuration & Customisation

12. Notifications & Communication

13. Compliance & Legal Considerations

14. Backend Processes & Code Mapping (for Developers)

(High-level; map to actual class/method names in your codebase.)

You’re right to prefer the original version of section 14. It’s clearer for developers because it’s organized by data model → endpoints → services → jobs → UI components, which matches how they think about the system.​

Here is the final Section 14 you can use for the Regular Enquiry page, with small tweaks to include the extra intake channels (Elevenlabs + email) but otherwise keeping your original structure and wording:

14. Backend Processes & Code Mapping (for Developers)

(Class and path names below are illustrative; fill with actual C#/Laravel names when wiring the wiki to the codebase.)

Data Model

BackOffice Client record (C# / DB)
Fields (see Business Logic doc):

Payments

Updates Record

Controllers & Endpoints (Conceptual)

Website → Laravel

Elevenlabs Intake

Email Intake

BackOffice API (C#/Web API, conceptual)

Services / Handlers

Autoassign Service

Status Management Service

Notifications Service

Strategy & Offer Services

Jobs / Cron

NPD Expiry Job

24-Hour Rule Job / Timer

Reminder & Survey Job

Freeze / Expired Job

Anonymisation Job

Accumulation / Invoicing Job

Frontend Components (Conceptual)

Website

BackOffice

3.2 Autoassignment & NPD

  1. BackOffice attempts autoassign based on the ET’s routing configuration in Laravel (profession, country, availability, capacity, performance and other business rules).

  2. If a suitable User is found, Assigned User is set, status remains New Enquiry, a New Client Assigned notification email is sent, and the assignment is logged in Updates Record.​

  3. If autoassign fails because no eligible user is available or a technical error occurs, the record is set to NPD – Awaiting Assignment, an NPD warning banner is shown, an Admin alert email (“Autoassign Failed”) is sent, and the lead appears on Admin NPD/Unassigned dashboards.

  4. Admin can then manually assign the lead from the Overview tab, overriding ET/country checks if necessary, with an explicit confirmation popup (including warnings if assigning to an Out-of-Office User).​

3.3 User contact & Strategy Guide (Created Lead)

  1. The assigned User contacts the client, usually by phone first, then by email; if calls are unsuccessful, “Didn’t answer” options in the Strategy Guide and/or call result buttons send auto-emails explaining contact attempts.

  2. The User completes a Strategy Guide in the Strategy Guide tab, selecting an appropriate strategy and quotation profile for the ET, adding text tailored to the client’s situation.

  3. Converting from New Enquiry to Created Lead requires the User to confirm or create a Strategy Guide; this status indicates a proper lead with a proposal ready.​

  4. From Created Lead, the User can send an Offer Email (proposal) to the client using the Strategy Guide, specifying services, fees, and next steps; this is a precondition for Paid Consultation or Direct Service decisions, but still within the Regular Enquiry flow.

3.4 Work phase (In Progress / Waiting for Response)

  1. Once the client agrees to proceed (verbally or in writing), the User sets status to In Progress and begins substantive work; Updates Record entries should briefly summarise conversations and progress.

  2. If the User has contacted the client and is now waiting for documents/instructions or a decision, status is set to Waiting for Response, and Next Progress Date is used to track when to follow up again.

  3. Automated reminders and Admin prompts may be tied to Waiting for Response and NPD/non-contact timeframes (e.g., 48+ hours without contact leads to reminder or elimination decisions).

3.5 Payments & completion

  1. When the client pays fees (consultation, fixed fee, or ongoing work), the User records the payment(s) in the Payments tab, including amount, date, method, and any notes (e.g., “Renta service for 2019”, “Monthly fiscal client – July & August”, “Eviction action fees”).

  2. The system aggregates payments and calculates Advocate Abroad’s commission based on ET and role; monthly invoices or commission statements are generated automatically using this data.

  3. When work is complete (or all agreed services are delivered), the User changes the status to Completed, triggering a completion popup that requests confirmation of total fees and cross-checks them against recorded payments; discrepancies trigger warnings.​

  4. After Admin review in Daily Updates and any final checks, Admin or the User can set the status to Closed, at which point survey and review emails can be sent or have already been triggered.

3.6 Elimination & NPD expiry

  1. If the client does not proceed, does not respond, chooses another lawyer, or the service is not suitable, the User sets status to Eliminated / Rejected / Unsuitable, choosing a reason in the elimination popup.

  2. Direct Service follow-ups (if any flag was applied earlier) and automated reminders stop immediately when the record is set to Eliminated.

  3. NPD leads that remain unassigned for configured time (e.g., 72 hours) move into Expired or Expired Clients views for Admin, and are included in weekly Admin summaries; Admin must either assign, eliminate, or extend deadlines manually.

4. Common confusion, mistakes & misunderstandings

  • Not updating status after contact: Users sometimes forget to change from New Enquiry to Created Lead or In Progress after talking to the client; this can trigger duplicate automatic emails or give the impression that the client has not been contacted.

  • Skipping Offer Email: Some Users provide substantial advice on the first call without sending an Offer Email or consultation confirmation, leading to later disputes about what was promised; the business rule is that services and fees should be confirmed by email.

  • Recording payments late or not at all: Payments are sometimes taken but not added to the Payments tab, which blocks Completed status (or misaligns totals) and breaks invoicing; Admin then has to chase for manual corrections or add payments retroactively.

  • Using the wrong ET or country: Misconfigured form endpoints or ET changes without understanding restrictions (e.g., NIF Application Portugal) cause routing and reporting problems, requiring Admin overrides.

  • Leaving clients “in limbo”: Cases remain In Progress or Waiting for Response with no updated Next Progress Date and no Updates comments, making it difficult for Admin to assess whether clients are being neglected; several internal messages explicitly request short Updates Record summaries and proper Next Progress Date management.

5. Permissions & access control rules

  • Only Admin and system autoassign can set the Assigned User for new enquiries by default; Users do not self-assign regular leads unless Admin workflows explicitly allow this.​

  • Only Admin can override ET country/profession restrictions and force ET changes at any status; Users can change ET only while the client is New Enquiry or Created Lead, and only to compatible ETs.​

  • Certain flags – Direct Service and Consultation Only – can be set only by Admin; these flags alter available statuses, templates and follow-ups, but Regular Enquiries operate without requiring these flags.​

  • Tasks created by Admin (e.g., “Add Payment”, “Upload Document”, “Complete Billable Actions”) can be marked as blocking, preventing Users from accessing other client records until completed; this is particularly used when a payment is clearly received but not registered.

  • Out-of-Office settings are configured by Users (period and behaviour), but Admin can see an OOO dashboard and can reassign leads or override OOO if necessary.​

6. Timing, deadlines & automation rules

  • Website-to-BackOffice creation: record must appear immediately after form submission (within a few seconds), including ET, country and status.​

  • Client contact SLA: system texts and internal messages emphasise contacting clients within around 24 hours; if calls fail, standard “We tried to reach you” emails are sent automatically.

  • NPD expiry: NPD leads older than a configured duration (e.g., 72 hours) are flagged as Expired and appear in Admin lists and summary emails; they do not automatically eliminate, but require Admin action.​

  • Waiting for Response / Next Progress Date: Users are expected to set Next Progress Date whenever they extend the follow-up horizon beyond about two weeks, and Admin explicitly requests single-line updates if the next action is weeks away.

  • GDPR retention: inactive enquiries (Eliminated, Closed) are anonymised after about six months and deleted after about twelve months, with configuration per jurisdiction; these jobs run automatically and are tracked for audit.

  • Email notifications: system sends New Client Assigned, We tried to reach you, Payment Declared, Client Response, and survey invitations based on specific triggers (assignment, call result buttons, payment additions, status changes to Completed/Closed).

7. Related processes & dependencies

Prerequisites:

  • Website forms and Laravel endpoints must be configured and tested (Form-to-ET mapping, country detection, confirmation emails) for Regular Enquiries to flow in correctly.

  • ETs in Laravel must be configured with routing, commission, recurring flags and any special rules (e.g., NIF Portugal, Translation, Recurring ETs).

Downstream / dependent processes:

  • NPD recovery (Process 2): handles reactivation and manual assignment when Regular Enquiries fall into NPD (e.g., OOO issues, no eligible Users).​

  • Out-of-Office lead reassignment (Process 3): ensures new Regular Enquiries are not stuck with OOO Users and that Admin can redistribute them.​

  • Recurring services (Process 4): some Regular Enquiries (e.g., Income Tax, Monthly Fiscal) evolve into principal/delegatee recurring records after initial work; that flow is handled by the recurring service process.​

  • Additional Services / ASP referrals: Regular Enquiries can spawn ancillary client records (translation, accounting, mortgage, insurance) via Add Service; these are linked but follow their own flows.

Parallel or conflicting workflows:

  • Paid Consultation and Direct Service flows reuse parts of the Regular Enquiry pipeline (Strategy Guide, Offer Emails), but enforce different constraints on templates, follow-ups and elimination; this page assumes the non-flagged Regular Enquiry case.

  • Recurring principal / delegatee records use Hibernated, In Progress and special completion flows; those should not be confused with one-off Regular Enquiries.​

8. Error recovery & retry logic

  • Form submission errors: If a website submission fails validation or ET mapping, Admin receives alerts, and test enquiries in Staging are used to confirm mapping before live deployment.

  • Autoassign failure: When autoassign fails, the process is idempotent in the sense that re-running autoassign after configuration fixes either assigns a suitable User or leaves the record NPD with clear reasons; repeated attempts do not create duplicate clients.

  • Email send failures: When an email cannot be sent (e.g., Terms & Conditions email failures), the system shows an error (“Email could not be sent; please try again or contact support”) and logs the failure for Admin, while Users are advised to verify addresses manually.

  • Payment save errors: If payment insertion fails, a generic error is shown, and Admin receives technical details; the User can safely re-enter the payment once the issue is resolved without duplicating commissions, as totals can be cross-checked manually.​

  • Duplicate notifications / unread anomalies: Historic issues where third-party emails produced multiple notifications or persistent unread counts are treated as regressions; the rule is one notification per inbound email and consistent read/unread state across all views.

  • Manual recovery: Admin can correct ETs, reassign leads, adjust payments, reopen Closed/Eliminated records, or create new linked records when earlier steps are irrecoverably broken (e.g., wrong ET, wrong user, or an incomplete record).

9. Performance & scalability considerations

  • Autoassign and record creation must complete fast enough that Users can see new Regular Enquiries in New Enquiries and Current Clients lists almost immediately; delays confuse Users about whether a lead exists.​

  • Email notifications (New Client Assigned, Client Response, etc.) are generated and sent within seconds to avoid Users missing time-sensitive contact windows (e.g., within 24 hours).

  • Background jobs for anonymisation, deletion, OOO summaries and NPD expiry run on schedules that balance performance with timely updates (e.g., daily or weekly summaries), but exact scheduling is implementation-level and outside the business logic page.

  • Lists (Current Clients, New Enquiries, Unread Emails, Daily Updates) use filters and pagination (e.g., 50 per page) to remain responsive even with large numbers of Regular Enquiries; redirect rules ensure Users are returned to the correct list after editing.​

10. Configuration & customisation options

  • ETs can be configured in Laravel with routing, pricing, commission defaults, recurring flags, reporting inclusion/exclusion, and country/profession constraints (e.g., NIF Application Portugal, Translation Service).

  • Website form endpoints are configurable (URL patterns, fields, confirmation texts) and must be explicitly mapped to ET and country; new or changed endpoints must be tested in Staging with sample enquiries.

  • OOO behaviour per User (reassign vs hold vs Admin list) is configurable via the Out-of-Office settings popup.​

  • Notification templates (New Client Assigned, Client Response, Payment Declared, We tried to reach you, survey emails) are centrally managed and updated as needed; only texts intentionally saved as templates appear in selection lists, avoiding clutter from one-off emails.

  • Recurring service behaviour (principal/delegatee flags, next payment dates, auto-accumulate) is configured at ET level and via the Recurring Service popup.​

11. Notification & communication rules

  • Who gets notified:

    • Assigned User: on new assignment, client email received, payment recorded, and sometimes on key status changes.

    • Admin: on autoassign failure (NPD), system errors (assignment, email, payment), and for NPD/Expired leads and other special events.

    • Client: on Terms & Conditions, We tried to reach you, Offer Emails, Direct Service or consultation offers where applicable, and survey invitations after completion.

  • When notifications are sent:

    • Immediately on assignment, inbound emails, and recorded payments.

    • On status changes to Completed/Closed (survey / feedback emails).

    • On daily/weekly basis for OOO summaries and Expired/NPD summaries.

  • Content & deduplication:

    • Inbound third-party emails (e.g., other lawyers) linked to a client record generate at most one notification per new email; duplicates or persistent unread notifications are considered defects.

    • Some automated notifications include partial previews (e.g., first 100 characters of a client email) but require the User to click through to the client record for full content.​

  • KeyChannels controls:& usage:

    • Status dropdownEmail is the primary external communication channel; telephone and WhatsApp are used by Users for direct contact, with associatedthe popups.​main record of activity stored in Updates Record and Emails/Messages tabs.

    • AssignedInternal User dropdownmessaging withbetween OOOAA warnings.​

      Admin
      • and
    • Users

      Strategyoccurs Guidein selectorMessages popup,tab scriptand downloadoccasionally button,via external email; these internal messages often drive business logic changes (e.g., “Don’t forget to add payment”, “Please send Offer EmailEmail”, generator.

      “Change
      • status
    • to

      Completed Wizard popup.​

  • Admin interfaces:

    • Laravel Assignment Interface (for web, Elevenlabs, email leads)Eliminated”).​

    • Unassigned Leads, NPD and Expired dashboards; OOO dashboard.

    • Any

    code
    that

    12. Historical changes the& meaning,deprecations

    allowed
    values,
    or
    side
    effects
    of status, 

    • Trello-derived rules were added to strengthen:

      • Out-of-Office autoassign behaviour (no leads blocked on OOO users).

      • NPD handling and assignment failure logging (NPD / Awaiting Assignment, with logged reasons).

      • ET country-specific configuration (e.g., orNIF flagsApplication suchPortugal as isconsultationonly and isdirectservice must be carefullyPT-only).

        reconciled

      • Email notification deduplication and third-party email read/unread consistency.

      • Form submission URL mapping and staging validation.

    • Earlier versions of the business logic were higher-level and did not specify detailed UI behaviour (popups, badges, list redirect rules, blocking tasks); v2.0 introduces a field-level, step-by-step spec for all main flows, including Regular Enquiry.​

    • Some historic behaviours (e.g., recurring popup skipping after two payments, auto-creation of templates from one-off Offer Emails) are treated as legacy quirks and are explicitly corrected in the updated rules.

    13. Compliance & legal considerations

    • Regular Enquiries must respect GDPR by:

      • Storing client data securely and only as long as necessary for service and legal/accounting retention.

      • Providing mechanisms to exercise rights of access, rectification, erasure, restriction, portability and objection through a defined BackOffice GDPR workflow (receive request, verify identity, export, deliver, anonymise/delete, confirm).

      • Keeping an audit trail of who accessed or modified client data via Updates Record.

    • For financial and tax compliance:

      • Payments recorded in the system are used as the basis for invoicing and commission calculations and therefore must reflect actual receipts; retroactive corrections are possible but administratively complex.

      • Documents such as invoices, tax forms (e.g., M210, IRNR, Renta) and proof of payments are often stored in Documents tab for evidence and future audits.

    • Terms & Conditions and legal information emails explicitly explain the relationship between Advocate Abroad (as a platform/marketing entity) and independent professionals, clarifying responsibility for professional advice and data handling.

    14. Known backend processes / code services

    (This section names behaviourally relevant backend processes without becoming a technical spec.)

    • Form submission & routing service: Accepts website form posts, maps submission URLs to ETs and countries, creates BackOffice client records, and triggers autoassign.

    • Autoassign engine: Applies ET/profession/country/availability rules and scoring, sets Assigned User and logs failures with this NPD status on error.

    • Notification service: Generates outbound emails for assignment, client responses, payments, surveys, OOO summaries and errors; enforces one-notification-per-email rule.

    • Status & task engine: Enforces valid status transitions, triggers popups and reminders, and handles blocking tasks that gate access to other clients.​

    • Recurring service engine: For ETs flagged as recurring, manages principal/delegatee records, next payment dates, and “Complete Service” operations; used by some Regular Lead/EnquiryEnquiries that become ongoing engagements.​

    • GDPR automation: process,Handles scheduled anonymisation and deletion based on status and age, and supports manual GDPR requests.

    15. Control & behavioural guardrails

    This section captures the “soft” behavioural rules that sit above the technical flows, derived from Administrator–User conversations.

    • Guardrail: don’t give free substantive advice without written confirmation.
      Users are repeatedly advised to send an Offer Email or consultation confirmation before providing detailed advice, to avoid disputes about promises and to evidence the client’s agreement to services and fees.

    • Guardrail: always record payments before closing.
      Admin messages emphasise that Users should not mark a client as Completed or Closed without first entering all received payments in Payments; invoices are generated automatically, and corrections after the fact are cumbersome.

    • Guardrail: keep Updates Record and Next Progress Date current.
      Admin often requests brief 1–2 line summaries and proper Next Progress Dates to ensure that clients are not forgotten and that long-running cases are monitored; leaving these blank is considered poor practice.

    • Guardrail: use the platform email and messaging system, not private channels.
      Users are encouraged to send client emails from within the client record so that AA can monitor service quality and ensure auditability; adding their own email addresses as client emails is explicitly discouraged because it sitsconfuses atsystem logic.

    • Guardrail: avoid “zombie” clients.
      When there is no realistic prospect of work (no response for a long period, or client clearly not proceeding), Admin pushes Users to eliminate the heartenquiry ofrather leadthan tracking,leave performanceit measurement,indefinitely in Ongoing, both to keep statistics accurate and commission/invoicingto logic.trigger surveys where appropriate.

    • Guardrail: respect Out-of-Office and workload limits.
      Users are blocked from receiving unlimited new Regular Enquiries if OOO, overloaded, or unresponsive; Admin may reassign or pause leads for such Users to protect client experience and network reliability.





    Back to top