Skip to main content

Format A: Regular Enquiry

1. General description

A

  • The Regular Enquiry process is the default,default full client lifecycle flow used when a website enquiry is routed into BackOfficehandled as a standard legal/legal or professional matter (notin BackOffice, without being pre-flagged as Paid Consultation only and notwithout using a pre-packaged Direct Service).Service Thestrategy.
    • process
  • It runscovers the journey from website form submission or Elevenlabs AI Receptionistreceptionist Call,intake, through Adminadmin manual assignment in Laravel to create a Client Record in the BackOffice, the Strategy Guidetriage and statusassignment, management,professional contact and quotation, ongoing case management and payment declaration, to payment recording, completion, survey and eventual anonymisation/deletion under GDPR rules.

    Regular Enquiries use the full Strategy Guidehandling and quotationGDPR-driven 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 preferred way to assign client enquiries as the engagement by the lawyers through phone callanonymisation or video-conferencedeletion.

    • provide
  • A theRegular bestEnquiry chanceis offirst created when a positive outcome, however it is costly in terms of lawyer's time and only those enquiries deemed to be sufficiently serious in intent and with appropriate User profile's are considered for this format of Enquiry.

    The specific type of enquiry is not so important in this evaluation - more important is the client profile and apparent intent: is the client serious and likely to proceed? This is why this part of the process is inherently manual, since it requires Admin to evaluate:

    • the seriousness of the client's intent
    • the value of the legal enquiry
    • the availability of any lawyer - or a suitable lawyer - to whom the legal enquiry can be safely assigned

    2. Specific goals & objectives

    • Ensure that every validvalidated website form submission is convertedmapped to an Enquiry Type and country in the Laravel layer and a client record is opened in BackOffice with status New Enquiry.

    • Admin confirms that the lead is correctly classified and, via autoassign or manual routing, ensures that an appropriate professional is assigned.
    • The assigned User is then responsible for contacting the client, completing a Strategy Guide, sending written offers where appropriate, and progressing the case through statuses such as Created Lead, In Progress and Waiting for Response until it reaches a final outcome.
    • Regular Enquiries are deliberately used for higher-value or more complex matters because they consume significant professional time, typically involving structured calls or video meetings combined with tailored written proposals.
    • Admin therefore assesses each incoming lead to decide whether it warrants the Regular Enquiry flow, taking into account the client’s apparent seriousness, the likely value of the matter and the availability of a suitable professional.
    • Leads that do not justify this level of engagement may instead be handled as Paid Consultations, Direct Services or may be eliminated quickly.
    • Within the Advocate Abroad ecosystem, Regular Enquiries depend on coordinated behaviour across the Website, Laravel and BackOffice platforms.
    • The Website is responsible for capturing and validating client data, Laravel for routing form endpoints to Enquiry Types and countries and applying configuration rules, and BackOffice for operational handling of statuses, communication history, payments, recurring-service flags and GDPR workflows.
    • Regular Enquiries form the baseline against which specialised flows such as Direct Service offers, Paid Consultation-only engagements and recurring principal or delegatee records are defined.

2. Business goals & objectives

  • Convert every valid, serious website submission into a single BackOffice client record with the correct Enquiry Type (ET), country,country and initial status (Newso Enquirythat no qualified enquiry is lost or NPD – Awaiting Assignment).

    duplicated.

  • Route each enquiryRegular Enquiry to an appropriate professional viausing autoassign,configured takingrouting intorules accountfor ET,Enquiry Type, country, professionprofession, language coverage, availability, capacity and availability;performance, ifwhile thisclearly fails,flagging markfailures as NPD andcases alertthat Admin.

    require admin action.

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

    confirmation where required.

  • Maintain accurate, auditable paymentfinancial data,information in the Payments tab so that invoicesinvoices, andinternal commission statements and partner settlements can be generated automatically and tiedreconciled toagainst recordedthe Paymentswork entries.

    performed.

  • MaintainProvide a fullcomplete audit trail of activity viain the Updates Record,Record, includingcapturing status changes, ETEnquiry Type changes, assignment and NPD events, assignment,payments, payments,admin overrides and Adminother interventions.

    key actions, to support quality assurance, dispute resolution and reporting.
  • Enable

    Support GDPR-GDPR-compliant retention,data withretention by ensuring that once Regular Enquiries become inactive and reach configured age thresholds, anonymisation and deletion appliedjobs automaticallycan run reliably, leaving only non-identifying statistics.

  • Protect professional time and network reputation by steering only serious and properly scoped matters into the Regular Enquiry flow and by offering clear mechanisms to inactiveeliminate, enquiriesfreeze accordingor tore-route configuredcases timelines.

    that are not progressing.

3. Step-Detailed behaviour & step-by-step procedureflow

(Regulartext Enquiry
lifecycle)

3.1 Website submission & record creation

    • The

      Clientclient completes a service form on the Advocate Abroad website (e.g.for a specific service category such as Property Purchase, PropertyDivorce, Purchase,Tax, Divorce,Immigration, Business Formation or Administrative procedures, Probate)procedures.

    • The

      Websitewebsite validates required fieldsfields, (such as name, email, phone, enquiry text,text consent)and consent, and posts the data to a dedicated form endpoint configured in Laravel.

      the Laravel admin system.

    • Laravel maps the submission URL and payload to an ETEnquiry Type and country according tousing its routing table; misconfigured URLs can cause wrong ET assignmenttable, and mustthis bemapping caughtis first confirmed in Staging.

      the staging environment by submitting test enquiries and verifying that the resulting BackOffice records show the expected Enquiry Type, jurisdiction and initial status.
    • BackOffice

      Acreates a new BackOffice client record iswith createdthe with:standard Overview,tab layout: Overview, Enquiry Details,Details, Strategy Guide,Guide, Emails,Emails, Messages,Messages, Documents,Documents, Payments,Payments, Additional Services,Services, Tasks,Tasks, GDPR and Updates Record tabs.​

      .
    • The

      Statusnew record’s status is set to New Enquiry;, the Enquiry Type, Country, Assigned User (if autoassigned) and Enquirycountry Datefields are populated, and the original enquiry text is visibleappears in Enquiry Details.

      Details, and the Enquiry Date and initial Last Activity Date are stored.
  • If
    • autoassign
    can
    immediately
    select
    a
    professional,
    the
    Assigned
    User
    field
    is
    also
    populated
    at
    this
    point.

    3.2 Autoassignment & NPD

    handling
      • There

        is currently no fully implemented or trusted automatic lead assignment in production; any assignment that appears in BackOffice attemptshas autoassignbeen made manually by an Admin (or equivalent) choosing an Assigned User and saving the record.

      • Laravel can compute a suggested assignee (candidate professional) for a lead based on the ET’s routing configurationconfiguration, inbut Laravelthis (profession,suggestion country,is availability,advisory capacity,only, performanceis not automatically applied, and otheris businessconsidered rules).

        deficient and not reliable for operational use.
      • All

        Ifleads that are not explicitly assigned by a suitablehuman Usermust isbe found,treated Assignedas Usereffectively isunassigned; set,NPD statusstates remains(e.g. New Enquiry, a New Client Assigned notification email is sent, and the assignment is logged in Updates Record.​

      • 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”) isare sent,used andto themake leadthese appearscases onvisible Adminin NPD/UnassignedNPD-focused dashboards.

        admin views rather than leaving them silently orphaned.
      • Admin

        Adminassigns can thenleads manually assign the lead from the Overview tab,tab overridingby ET/country checks if necessary, withchoosing an explicitAssigned User from the dropdown; confirmation popuppopups (includingmay warningshighlight ifissues such as assigning to ana Out-of-user who is Out of Office User).​

        and can offer options such as extending NPD deadlines or sending immediate notifications.
  • Any
    • references
    in
    this
    document
    or
    the
    Wiki
    to
    autoassign
    describe
    planned
    or
    intended
    future
    behaviour
    only;

    for current reality, wording should be interpreted as “Laravel proposes a suggested assignee; Admin must confirm or override and save the assignment manually in BackOffice.”

    3.3 User contact & Strategy Guide (Created Lead)

      • The assigned Userprofessional contactsis expected to contact the client,client usuallypromptly, typically by phonetelephone first,as the first channel and then by email;email if calls are unsuccessful,unsuccessful “Didn’tor answer” options inif the client prefers written communication.

      • Call results and first-contact attempts may trigger standard “we tried to reach you” messages, and the All Actions workflow can automatically record outcomes such as non-answer, another person answering, or phone issues, often combined with follow-up emails.
      • In the Strategy Guide and/or call result buttons send auto-emails explaining contact attempts.

      • The User completes a Strategy Guide intab, the Strategyuser Guide tab, selectingselects an appropriate strategy and quotation profile for the ET,Enquiry addingType, textcustomises tailoredquestions and proposals, and records key information that will later appear in offer or consultation emails.

      • Changing the main status from New Enquiry to Created Lead generally requires confirmation that a Strategy Guide exists or that a suitable quotation or plan has been prepared, and Created Lead indicates that the enquiry has been qualified and that a concrete proposal can be presented to the client’s situation.

        client.
      • From

        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.​

      • From Created Lead, the Userprofessional can send an Offeroffer Emailor (proposal)quotation to the clientemail using the Strategy Guide,Guide content, specifying the scope of services, fees, payment structure and next steps;steps, and this isemail forms the basis for deciding whether the case continues as a preconditionfull forRegular Enquiry, a Paid Consultation-only engagement, a Direct Service, or Directis Servicelater decisions, but still within the Regular Enquiry flow.

        eliminated.

    3.4 Work phase (In Progress /& Waiting for Response)

      • Once the client agreesconfirms that they wish to proceed (verbally or in writing),proceed, the Useruser sets the status to In Progress and begins substantive work;work, adding short notes to the Updates Record entries should brieflyto summarise conversationsimportant conversations, milestones and progress.

        decisions.

      • If the Usermain hasaction contactedis now on the client andor ison nowa third party, such as waiting for documents/instructionsdocuments, a decision or aan decision,external status is set to Waiting for Response, and Next Progress Date is used to track when to follow up again.

      • 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. Whenauthority, the clientuser 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 changessets the status to Completed,Waiting triggeringfor a completion popup that requests confirmation of total feesResponse and cross-checks them against recorded payments; discrepancies trigger warnings.​

    4. After Admin review in Daily Updates and any final checks, Admin oruses the UserNext canProgress setDate the statusfield 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 immediatelyindicate 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 feescase should be confirmedreviewed by email.

      again.
    • System

      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)reminders and breaksadmin invoicing;monitoring Adminoften thenrely hason 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 combined with no updated Next Progress Date and no Updates comments, making it difficult for Admin to assessidentify whethercases clientswhere 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 theno follow-up horizonhas beyondoccurred abouton two weeks,schedule, and Adminthose explicitlyrules requestsinteract single-linewith Expired and NPD processes when no updates ifare recorded.

    • Throughout the nextwork actionphase, isemails, weeksinternal away.

      messages,
      • documents
    • and

      GDPR retention: inactive enquiries (Eliminated, Closed)tasks 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 triedattached 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.​

    • Channels & usage:

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

      • Internal messaging between AA Admin and Users occurs in Messages tab and occasionally via external email; these internal messages often drive business logic changes (e.g., “Don’t forget to add payment”, “Please send Offer Email”, “Change status to Eliminated”).

    12. Historical changes & deprecations

    • 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., NIF Application Portugal must be PT-only).

      • 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 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 Enquiries that become ongoing engagements.​

    • GDPR automation: 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 AAthe canfull monitorcontext serviceof qualitythe Regular Enquiry remains visible to both the professional and ensureadmin.

      • auditability;
    adding
    their
    own

    3.5 emailPayments, addressescompletion as& closure

    3.6 Elimination & inactivity-driven outcomes





    Back to top