Skip to main content

Format A: Regular Enquiry

1. General description

  • The Regular Enquiry process isrepresents the defaultstandard, full client lifecycle usedfor whenhandling amost legal and professional matters submitted via the Advocate Abroad website enquiryinto isBackOffice, handledfrom asinitial awebsite standardform legalsubmission through professional contact, quotation, case work, payment declaration, completion, feedback and GDPR anonymisation or professionaldeletion. matter in BackOffice, without being pre-flagged as Paid Consultation only and without using a pre-packaged Direct Service strategy.

  • It coversclosely thefollows journey“Process from1 – Complete Lead Lifecycle” (website or AI receptionist intake, through admin triage andsubmission, assignment, professionaluser contact and quotation, ongoingclient case managementresponse and work, payment declaration, to completion, survey handling and GDPR-drivencompletion), anonymisationand is used when the enquiry is not flagged as Direct Service or deletion.
  • Paid
  • AConsultation only.

    Regular EnquiryEnquiries is firstare created when a validated website formforms submission isare mapped via Laravel to an Enquiry Type and country in the Laravel layer and a BackOffice client record is opened in BackOffice with status New Enquiry.

  • Enquiry,
  • Admin confirms that the lead is correctly classified and, via autoassign or manual routing, ensures that an appropriate professional is assigned.
  • Thethen assigned User(or isleft thenin responsibleNPD forif contactingassignment the client, completing a Strategy Guide, sending written offers where appropriate,fails) and progressing the caseprogressed through statuses such as Created Lead,Lead, In ProgressProgress, and Waiting for ResponseResponse, untilCompleted itand reachesClosed. aThis finalprocess outcome.
  • is
  • Regular Enquiries are deliberately useddesigned for higher-higher‑value or more complex matters becausethat theyjustify consume significantsubstantive professional time, typically involving structured calls or videomeetings, meetings combined withand tailored written proposals.
  • proposals,
  • Adminusing thereforeStrategy assessesGuides eachand incomingquotation leadprofiles to decideframe whetheroffers itand warrantsfollow‑on work.

    The process is inherently cross‑platform: the RegularWebsite Enquirycaptures flow,and takingvalidates intoclient accountdata and submits to a Laravel endpoint; Laravel maps the client’ssubmission apparentto seriousness,Enquiry Type, country and configuration rules; and BackOffice provides the likelyoperational valueinterface offor thestatus mattermanagement, communication, payments, tasks, Updates Record auditing, and theGDPR availabilityworkflows. 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 dependact 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 formas the baseline flow against which specialised flowsprocesses such as Direct Service offers, Paid Consultation-Consultation‑only engagementsengagements, NPD recovery, OOO reassignment and recurringRecurring principal or delegatee recordsServices are defined.

2. Business goals & objectives

  • ConvertEnsure every valid, serious website submission intobecomes a singlesingle, correctly classified BackOffice client record with the (correct Enquiry Type,Type, country andcountry, initial statusstatus) so that no qualified enquiry is lostlost, duplicated or duplicated.handled off‑system.
  • Route each Regular Enquiry to an appropriate professional using configured routing rules for (Enquiry Type,Type, country, profession, language coverage,language, availability, capacitycapacity, performance), and performance,surface whileany clearly flaggingrouting failures as NPD casesstates thatrequiring requireexplicit admin action.intervention.
  • Enforce a status-status‑driven lifecycle, typically moving from (New Enquiry to Created Lead to In Progress or/ Waiting for Response and thenCompleted to Completed and ClosedClosed, or toEliminated Eliminated,/ Rejected or/ Unsuitable,Unsuitable) with popups enforcingthat require elimination reasons and completion or completion/payment confirmation whereto required.support accurate reporting and compliance.
  • Maintain accurate,complete, auditable financial informationrecords in the Payments tab soto thatdrive automatic commission calculations, invoices, internal commissionprofessional statements and partner settlements canthat be generated automatically and reconciledreconcile against thedeclared work performed.work.
  • Provide a completerobust audit trail in the Updates Record, capturing (status changes, Enquiry Type changes, assignment and NPD events, payments, admin overridesoverrides) andso other key actions, to supportthat quality assurance, dispute resolutionresolution, and reporting.KPI reporting by Enquiry Type, country, status and user are possible.
  • EnableSupport GDPR-GDPR‑compliant data retention and anonymisation by ensuring that once Regular Enquiries becomecan inactivebe andmarked reachinactive, then anonymised or deleted by background jobs after configured agetime thresholds, anonymisation and deletion jobs can run reliably, leaving only non-non‑identifying statistics.
  • Protect professional time and network reputation by steeringfunnelling only serious andserious, properly scoped matters into the full Regular Enquiry flowflow, andwhile byenabling offeringquick clearelimination mechanismsor redirection to eliminate,Direct freezeService, Paid Consultation or re-routeother casesprocesses thatwhere are not progressing.appropriate.

3. Detailed behaviour & step-by-step‑by‑step flow

text

3.1 Website submission & record creation

    1. The clientClient completes a service form on the Advocate Abroad website for a specific serviceEnquiry categoryType such(for asexample, Property PurchasePurchase, Divorce, Tax, Immigration, Business Formation, Administrative procedures), Divorce,with Tax,client‑side Immigration,validation Business Formation or Administrative procedures.
    2. The website validatesof required fields, such as name, email, phone, enquiry textemail and consent,phone formats, and postsGDPR consent.
    3. On submission, the website POSTs the form data to a dedicated form endpoint configured inLaravel endpoint; Laravel captures the Laravelsubmission adminURL, system.matches it against the Enquiry Type routing table, derives the country from URL or domain, and prepares to create a BackOffice lead.
    4. Laravel maps the submission URL and payload to an Enquiry Type and countrycountry; usingon its routing table, andstaging, this mapping is first confirmed in the staging environmentvalidated by submitting test enquiries and verifyingchecking that the resulting BackOffice recordsrecord showshows the expected Enquiry Type,Type, jurisdiction and initial status.
    5. BackOffice creates a new client record with status New Enquiry, populates Enquiry Type, country, Enquiry Date, Last Activity Date, and fills the Enquiry Details tab with the original enquiry text, while exposing the standard tab layout:layout Overview,(Overview, Enquiry Details,Details, Strategy Guide,Guide, Emails,Emails, Messages,Messages, Documents,Documents, Payments,Payments, Additional Services,Services, Tasks,Tasks, GDPRGDPR, and Updates RecordRecord).
    6. The new record’s statusAutoassign is setattempted according to Newconfiguration, Enquiry,but in current production any effective assignment is manual: if no trusted automatic assignment is in place, admin chooses an Assigned User on the EnquiryOverview Typetab and countrysaves; fieldsif areno populated,assignment is made or autoassign fails, the originalrecord enquiryenters textan appearsNPD in Enquiry Details, and the Enquiry Date and initial Last Activity Date are stored.state.
    7. If autoassign can immediately select a professional, the Assigned User field is also populated at this point.

3.2 AutoassignmentAutoassignment, manual assignment & NPD handling

    1. ThereAutoassign logic (as designed) filters eligible users by profession, country coverage, active status and capacity, scores them by performance and workload, and selects the best candidate; if implemented, it updates the Assigned User, logs the change in Updates Record and sends a notification.
    2. When autoassign finds no eligible user or a technical error occurs, the client is currently no fully implemented or trusted automatic lead assignment in production; any assignment that appears in BackOffice has been made manually by an Admin (or equivalent) choosing an Assigned User and saving the record.
    3. Laravel can compute a suggested assignee (candidate professional) for a lead based on routing configuration, but this suggestion is advisory only, is not automatically applied, and is considered deficient and not reliable for operational use.
    4. All leads that are not explicitly assigned by a human must be treatedflagged as effectively unassigned; NPD states (e.g. NPD – Awaiting Assignment)Assignment, area usedwarning tobanner makeappears, theseUpdates casesRecord visiblenotes the failure, and the lead surfaces in NPD-focusedAdmin admindashboards viewsand rathersummary thanemails leavingfor themmanual silently orphaned.action.
    5. Admin assignsperforms leadsmanual manuallyassignment by selecting an Assigned User from the Overview tab bydropdown; choosing an Assigned User fromif the dropdown; confirmation popups may highlight issues such as assigning to achosen user who is Out of OfficeOffice, anda canwarning offerpopup optionsappears suchoffering asto extendingextend NPD deadlines or sendingsend an immediate notifications.notification before saving the assignment and updating Updates Record.
    6. AnyReferences referencesto “autoassign” in this document or the WikiRegular toEnquiry autoassign describe planned or intended future behaviour only; for current reality, wordingcontext should be interpreted as “Laravel proposes a suggested assignee; Admin must confirmconfirms or overrideoverrides and save the assignmentsaves manually in BackOffice.”BackOffice” until fully automatic, trusted assignment is deployed.

3.3 User contact & Strategy Guidequotation (Created Lead)

    1. The assigned professional is expected to contact the client promptly, typically by telephonephone as the firstprimary channelchannel, and thenfollowed by email ifwhere calls are unsuccessfulfail or ifwritten communication is preferred, with outcomes recorded in the clientAll prefersActions writtenworkflow communication.
    2. as
    3. Callnon‑answer, resultswrong person, phone issues and first-contactsimilar 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.codes.
    4. In the Strategy Guide tab, the user selects an appropriate strategyStrategy andGuide quotationand, profilewhere configured, associated Quotation Profiles for the Enquiry Type, and country, then customises questionsquestions, proposals and proposals,fees andto recordsreflect keythe informationclient’s that will later appear in offer or consultation emails.scenario.
    5. ChangingWhen a workable proposal exists, the main status is moved from New Enquiry to Created LeadLead, generallyoften requireswith a confirmation that a Strategy Guide exists or that a suitableequivalent quotation or plan has been prepared, and Created Lead indicatessignalling that the enquiry has been qualified and thatis ready for a concrete proposal can be presented to the client.proposal.
    6. From Created Lead,Lead, the professional can sendsends an offer or quotation email using(or, thein StrategyDirect GuideService content,contexts, a structured Direct Service offer) specifying the scope of services,scope, fees, payment structure and next steps,steps; the email is stored in the Emails tab and this email formsbecomes the basis for deciding whether the case continues as a full Regular Enquiry,Enquiry, a Paid Consultation-Consultation‑only engagement, a Direct Service,Service, or is later eliminated.

3.4 WorkClient phaseresponse & work stage (In Progress &/ Waiting for Response)

    1. OnceWhen the client confirms that they wish to proceed,proceed under the proposed terms, the user sets the status to In Progress and begins substantive work, while adding short notes to the Updates Record to summarise importantkey conversations, milestonesdocuments received and decisions.
    2. If the mainnext action is nowdepends on the client or on a third party,parties such(for asexample, waiting for documents, a decisiondecisions, or anauthority external authority,responses), the user sets the status to Waiting for Response and uses the Next Progress Date field to indicate when the case should be reviewed again.
    3. System remindersreminders, list filters (such as Current Clients, Expired Clients) and admin monitoring often rely on Waiting for Response combined with Next Progress Date to identify cases wherethat nohave follow-not been followed up has occurred on schedule, andfeeding thoseinto rules interact with Expired and NPDNPD‑related processesviews whenif noinactivity updates are recorded.persists.
    4. Throughout the work phase,stage, emails,users attach and manage emails, internal messages,messages, documents and tasks are attached towithin the client record so that the full context of the Regular Enquiry remains visible to both the professionalprofessionals and admin.admin, supporting hand‑overs and audits.

3.5 Payments, completion & closure

    1. WhenEach time the client pays fees,fees whether for (consultations, fixed-fixed‑fee work orwork, ongoing services,services), the professional records eachthe payment in the Payments tab, including amount, method,date, datemethod and any relevant notes, andensuring associateseach itpayment is correctly associated with the correctrelevant part of the work.
    2. The systemBackOffice aggregates paymentspayment records and, based on Enquiry Type and appliesuser Enquiryrole, Typecalculates and role-based rules to calculate Advocate Abroad’sAbroad commission and any referral or delegatee shares, and these figureswhich are later used to generate invoices, professionalinternal commission statements and payout summaries.
    3. When the professional considers the work complete, they change the status to Completed;Completed; a completion popup asks forrequests confirmation of the total fees receivedreceived, compares this with recorded payments, and compares the figure against declared payments, issuing warningswarns if there is a mismatch is detected so that the user can correct thepayments record.before proceeding.
    4. Completed cases appear in admin review queueslists such as Daily Updates,Updates, where admin verifies payments, checksdecides whetheron surveyssurvey orand feedback emails should be sentemails, and ensuresconfirms that the record is ready to bemove finalised.to Closed.
    5. After any necessary admin review, the status is set to Closed,Closed, indicating that the Regular Enquiry is fully finished; at this point, any remaining surveysurveys or feedback emails are sent if they have not already been triggered,issued, and the record beginsbecomes movingeligible towardsto progress into GDPR anonymisation or deletion according to GDPRretention settings.rules.

3.6 Elimination & inactivity-inactivity‑driven outcomes

    1. If the client clearly does not wish to proceed, choosesselects another provider, remains unresponsive despite repeatedreasonable chasersfollow‑ups, or the service is outside scope, the user changes the status to an appropriate eliminating outcome such as Eliminated,Eliminated, Rejected or Unsuitable.Unsuitable.
    2. WhenOn the status is changed toselecting an eliminating outcome,status, a reason popup requires the user to choose or enter aan clearelimination justification,reason and(for thisexample, informationno supportsresponse, analyticsservice onnot lostoffered, leadsclient andunsuitable, ensuresclient thatwithdrew), automatedensuring follow-follow‑ups are stopped immediately.immediately and lost‑lead analytics remain meaningful.
    3. Leads that remainleft in NPD – Awaiting Assignment or in similar inactive states for longer thanbeyond configured thresholds are surfaced to admin in specificdedicated Admin views (for example, Expired Clients, Unassigned Leads) and summary emailsemails, prompting Admin to assign, eliminate, freeze or otherwise resolve them rather than leaving them indefinitely unhandled.

4. Confusions, edge cases & known issues

  • Users may assume autoassign is fully automatic, but the design documents and Trello‑driven updates clarify that suggested assignment from Laravel is not yet a trusted, production autoassign and Admin must still confirm or override assignments manually.
  • NPD states can be misunderstood as final outcomes rather than temporary flags indicating missing assignment; the NPD Recovery process exists precisely to ensure Regular Enquiries do not remain stuck without a professional.
  • Direct Service and Paid Consultation flows share statuses and Enquiry Types with Regular Enquiries but have distinct flags and automation; confusion arises when users expect Direct Service follow‑ups or consultation‑only rules to apply automatically in a standard Regular Enquiry unless correctly configured.
  • Out‑of‑Office and reassignment logic can create edge cases where Regular Enquiries are temporarily unassigned or misrouted; OOO and NPD rules need to be applied consistently so that clients are not left without an active responsible professional.

5. Permissions & access rules

  • Standard Users (professionals) and Admins can view and work Regular Enquiries assigned to them; only Admins can freely reassign clients, override Enquiry Types and edit certain Overview fields such as country in line with the BackOffice permissions model.
  • Changing Enquiry Type as a User is generally allowed only while the status is New Enquiry or Created Lead; Admins can perform Enquiry Type changes at any status and can bypass country restrictions when correcting misclassified leads.
  • Direct Service and Paid Consultation flags and some associated status transitions (for example, setting Direct Service, marking Consultation‑only) are reserved to Admin roles and specific popups, to keep the Regular Enquiry lifecycle consistent and auditable.
  • NPD management actions (marking Client Not Proceeding from NPD banners, bulk assignment from NPD/Expired lists) are Admin‑driven, ensuring that Regular Enquiries do not silently disappear from operational responsibility.

6. Timing, automation & background jobs

  • Website submission to BackOffice record creation is expected to happen within seconds, with autoassign (where configured) attempted within a few seconds and notification emails sent within approximately 30 seconds of form submission.
  • NPD expiry logic treats NPD – Awaiting Assignment for longer than a configured window as Expired, surfacing those Regular Enquiries in Admin dashboards and weekly summary emails, while not automatically changing to Eliminated.
  • Direct Service flows, when combined with Regular Enquiries, may trigger automated reminder emails at 48 hours and 7 days after an offer if no response is detected, then mark offers as expired for admin attention after a longer period.
  • GDPR anonymisation and deletion jobs run in the background based on status (for example, Eliminated or Closed) and age thresholds, progressively stripping or deleting personal data from Regular Enquiries while retaining aggregate statistics.

7. Dependencies & interactions

  • Regular Enquiries depend on correct Website→Laravel form routing, including accurate URL‑to‑Enquiry Type mapping, country detection and field mapping to BackOffice; misconfigured forms can create wrongly classified or unusable Regular Enquiries.
  • The process relies on Lead Assignment & Autoassign, NPD Handling, Out‑of‑Office Management and Strategy Guide/Quotation Profile modules operating correctly, as these determine who owns the enquiry, how quickly clients are contacted, and how offers are structured.
  • Recurring Services build on Regular Enquiries by converting suitable cases into principal/delegatee structures and monthly payment tracking; completion and elimination in Regular Enquiries can interact with recurring service termination and continuation rules.
  • Notification, list and redirect behaviours (Daily Updates, Current Clients, Unread Emails, New Enquiries, Expired Clients) all assume that Regular Enquiries move through statuses according to the documented lifecycle so that operational dashboards remain reliable.

8. Error handling, recovery & idempotency

  • If autoassign fails due to configuration or technical error, the system records an NPD state plus an Updates Record entry and sends an admin notification, allowing Admin to recover the Regular Enquiry by manual assignment without data loss.
  • Status change popups for Completed and Eliminated act as safeguards: if payment totals do not match or elimination reasons are missing, users are warned and must correct data or confirm before the status change is committed.
  • Repeating actions such as re‑saving a Strategy Guide, resending an offer, or re‑attempting assignment are designed to be safe, with Updates Record preserving a chronological history rather than overwriting previous entries.
  • Trello‑driven fixes for NPD expiry, OOO reassignment, unread email counts and redirect anomalies aim to reduce scenarios where Regular Enquiries become “lost” in navigation or mis‑flagged in lists, improving recoverability.

9. Performance & scalability considerations

  • Lead creation, status changes and assignment updates are expected to be near‑real‑time so that Admin and Users see new Regular Enquiries quickly in New Enquiries, Current Clients and NPD lists.
  • BackOffice list views (Daily Updates, Current, All, Unread, New, Expired) use pagination and filters to keep navigation responsive even as the number of Regular Enquiries grows.
  • Autoassign, NPD scanning, and GDPR anonymisation are implemented as lightweight, rule‑based operations or background processes, so they can scale without noticeably blocking user actions on individual Regular Enquiries.

10. Configuration & customisation

  • In Laravel, Enquiry Types are configured with names, categories, allowed countries, required professions, routing and assignment settings, pricing and commission defaults, recurring flags and reporting rules, all of which influence how Regular Enquiries are created and assigned.
  • Strategy Guides and Quotation Profiles are configured in Laravel with questions, proposals, default fees and additional services flags, then selected and customised per client in BackOffice during the Regular Enquiry lifecycle.
  • Autoassign enablement, NPD popup behaviour, Out‑of‑Office settings, notification preferences, and some status behaviours (for example, Direct Service flags) are configurable per user or per Enquiry Type and can be assigned,tuned eliminated,without frozencode changes.
  • GDPR retention periods, anonymisation rules and some survey/feedback email templates are configurable in line with the broader BackOffice and notification configuration structure, affecting Regular Enquiries once they reach inactive or otherwiseclosed resolvedstates.

11. Notifications & communication rules

  • New Regular Enquiries (especially where autoassign succeeds or fails) trigger notifications to professionals and/or Admin, including New Client Assigned, Autoassign Failed and related templates, with links to the client record.
  • Incoming client emails and third‑party emails linked to a Regular Enquiry generate Unread indicators and one notification per unique email, with unread counts and list entries controlled by the Email Client and Unread Logic rules.
  • Payment declaration events can trigger Payment Declared notifications for Admin and relevant stakeholders, while Out‑of‑Office daily summaries and system error alerts ensure operational visibility over Regular Enquiries even when individual users are absent.
  • Survey and feedback emails are sent after completion or closure of Regular Enquiries using predefined templates, supporting client satisfaction monitoring and quality control.

12. Historical changes & Trello‑driven updates

  • The v2.0 Business Logic manual expands earlier high‑level descriptions of the lead lifecycle into detailed, step‑by‑step workflows for each stage of the Regular Enquiry, including UI elements, validation rules and popups.
  • Trello and JSON conversations have driven refinements to autoassign edge cases, NIF Portugal and Translation Enquiry Type routing, unread email logic, status/list redirects, NPD expiry handling, and OOO reassignment, all of which directly affect Regular Enquiry behaviour.
  • Direct Service, Paid Consultation, Recurring Services and NPD Recovery have been formalised as distinct but related processes, clarifying where the Regular Enquiry flow should be used versus where these specialised workflows apply.

13. Compliance & legal constraints

  • Regular Enquiries must support GDPR obligations by allowing data to be anonymised or deleted after appropriate retention periods, while retaining an audit trail and anonymised statistics necessary for business reporting.
  • Payment tracking and commission calculation within Regular Enquiries underpin tax and financial reporting, so accurate recording of amounts, dates, methods and commission splits is required for internal and partner accounting.
  • Updates Record entries for status changes, Enquiry Type changes, assignment events, payments and admin overrides provide an auditable history of how each Regular Enquiry was handled, which is important for disputes, client complaints and internal QA.

14. Backend services & integration points

  • Website–Laravel integration handles form submission, URL capture, Enquiry Type routing, country detection and field mapping before creating or updating Regular Enquiries in BackOffice via internal APIs.
  • Laravel modules manage Enquiry Type catalogues, user capabilities, commission settings, Strategy Guides, Quotation Profiles and some task and notification behaviours that directly shape Regular Enquiry behaviour.
  • Background jobs and cron‑like services handle NPD expiry detection, Out‑of‑Office summaries, some Direct Service follow‑ups, and GDPR anonymisation tasks that affect the status and visibility of Regular Enquiries over time.

15. Behavioural guardrails & Project Manager guidance

  • Users should not close a Regular Enquiry as Completed or Closed until all client payments have been declared accurately in the Payments tab and the completion popup confirmation matches recorded amounts, which is enforced by the Completed‑status payment confirmation popup and, where required, blocking “Add Payment” tasks that must be completed before other navigation is allowed. Admin will also check payments declared against email exchanges manually in Daily Updates List review.
  • Off‑platform handling of enquiries (for example, using private email accounts or untracked phone numbers) is discouraged and mitigated by requiring that client contact details are captured from website forms into BackOffice, by routing all system emails through the integrated Email Client, and by logging every email in the Emails tab so Admin can see whether communication is happening on‑platform.
  • To reduce untracked private communication, the intended implementation pattern is that: (1) website forms capture the primary client email and phone before any professional contact, (2) replies to system‑generated emails are automatically linked back into the client record, including replies from third‑party addresses, and (3) email notification rules can distinguish registered system users from external email addresses so that “off‑system” participants are recorded but cannot work the case without a user account.
  • Where a client sends new emails after a Regular Enquiry has been marked Closed, Completed or Eliminated/Rejected, the Email Client and notification templates are intended to surface this as a new event to the assigned professional and Admin (for example via admin‑facing notifications or dashboards), so that the team can decide whether to reopen the case, convert it to a new enquiry, or respond without silently ignoring post‑closure contact.
  • When in doubt between eliminating a case or leaving it idle, the rule is to either eliminate with a clear reason (using the mandatory elimination popup) or actively assign and progress it, with NPD and Expired‑client dashboards highlighting Regular Enquiries that have been left unassigned or inactive past defined thresholds so Admin can intervene.
  • Users should rely on Strategy Guides and Quotation Profiles, rather than remainingad‑hoc indefinitelypromises unhandled.in free‑text emails, with the Strategy Guide tab and its “Select Strategy Guide” / “Save Strategy Guide” flow providing the mechanism to standardise questions, proposals and fees before offers are sent from the integrated Email Client.