Skip to main content

Format A: Regular Enquiry

1. General description

The Regular Enquiry process represents the standard, full client lifecycle for handling most legal and professional matters submitted via the Advocate Abroad website into BackOffice, from initial website form submission through professional contact, quotation, case work, payment declaration, completion, feedback and GDPR anonymisation or deletion. It closely follows “Process 1 – Complete Lead Lifecycle” (website submission, assignment, user contact and quotation, client response and work, payment and completion), and is used when the enquiry is not flagged as Direct Service or Paid Consultation only.

Regular Enquiries are created when website forms are mapped via Laravel to an Enquiry Type and country and a BackOffice client record is opened with status New Enquiry, then assigned (or left in NPD if assignment fails) and progressed through statuses such as Created Lead, In Progress, Waiting for Response, Completed and Closed. This process is designed for higher‑value or more complex matters that justify substantive professional time, structured calls or meetings, and tailored written proposals, using Strategy Guides and quotation profiles to frame offers and follow‑on work.

The process is inherently cross‑platform: the Website captures and validates client data and submits to a Laravel endpoint; Laravel maps the submission to Enquiry Type, country and configuration rules; and BackOffice provides the operational interface for status management, communication, payments, tasks, Updates Record auditing, and GDPR workflows. Regular Enquiries act as the baseline flow against which specialised processes such as Direct Service offers, Paid Consultation‑only engagements, NPD recovery, OOO reassignment and Recurring Services are defined.

2. Business goals & objectives

  • Ensure every valid, serious website submission becomes a single, correctly classified BackOffice client record (correct Enquiry Type, country, initial status) so that no qualified enquiry is lost, duplicated or handled off‑system.
  • Route each Regular Enquiry to an appropriate professional using configured rules (Enquiry Type, country, profession, language, availability, capacity, performance), and surface any routing failures as NPD states requiring explicit admin intervention.
  • Enforce a status‑driven lifecycle (New Enquiry → Created Lead → In Progress / Waiting for Response → Completed → Closed, or Eliminated / Rejected / Unsuitable) with popups that require elimination reasons and completion/payment confirmation to support accurate reporting and compliance.
  • Maintain complete, auditable financial records in the Payments tab to drive automatic commission calculations, invoices, professional statements and partner settlements that reconcile against declared work.
  • Provide a robust audit trail in the Updates Record (status changes, Enquiry Type changes, assignment and NPD events, payments, admin overrides) so that quality assurance, dispute resolution, and KPI reporting by Enquiry Type, country, status and user are possible.
  • Support GDPR‑compliant data retention and anonymisation by ensuring Regular Enquiries can be marked inactive, then anonymised or deleted by background jobs after configured time thresholds, leaving only non‑identifying statistics.
  • Protect professional time and network reputation by funnelling only serious, properly scoped matters into the full Regular Enquiry flow, while enabling quick elimination or redirection to Direct Service, Paid Consultation or other processes where appropriate.

3. Detailed behaviour & step‑by‑step flow

3.1 Website submission & record creation

  1. Client completes a service form on the Advocate Abroad website for a specific Enquiry Type (for example, Property Purchase, Divorce, Tax, Immigration, Business Formation, Administrative procedures), with client‑side validation of required fields, email and phone formats, and GDPR consent.
  2. On submission, the website POSTs the form data to a configured Laravel endpoint; Laravel captures the submission URL, matches it against the Enquiry Type routing table, derives the country from URL or domain, and prepares to create a BackOffice lead.
  3. Laravel maps the submission to an Enquiry Type and country; on staging, this mapping is validated by submitting test enquiries and checking that the resulting BackOffice record shows the expected Enquiry Type, jurisdiction and initial status.
  4. 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 (Overview, Enquiry Details, Strategy Guide, Emails, Messages, Documents, Payments, Additional Services, Tasks, GDPR, Updates Record).
  5. Autoassign is attempted according to configuration, but in current production any effective assignment is manual: if no trusted automatic assignment is in place, admin chooses an Assigned User on the Overview tab and saves; if no assignment is made or autoassign fails, the record enters an NPD state.

3.2 Autoassignment, manual assignment & NPD

  1. Autoassign 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 flagged as NPD – Awaiting Assignment, a warning banner appears, Updates Record notes the failure, and the lead surfaces in Admin dashboards and summary emails for manual action.
  3. Admin performs manual assignment by selecting an Assigned User from the Overview tab dropdown; if the chosen user is Out of Office, a warning popup appears offering to extend NPD deadlines or send an immediate notification before saving the assignment and updating Updates Record.
  4. References to “autoassign” in the Regular Enquiry context should be interpreted as “Laravel proposes a suggested assignee; Admin confirms or overrides and saves manually in BackOffice” until fully automatic, trusted assignment is deployed.

3.3 User contact & quotation (Created Lead)

  1. The assigned professional is expected to contact the client promptly, typically by phone as the primary channel, followed by email where calls fail or written communication is preferred, with outcomes recorded in the All Actions workflow as non‑answer, wrong person, phone issues and similar codes.
  2. In the Strategy Guide tab, the user selects an appropriate Strategy Guide and, where configured, associated Quotation Profiles for the Enquiry Type and country, then customises questions, proposals and fees to reflect the client’s scenario.
  3. When a workable proposal exists, the main status is moved from New Enquiry to Created Lead, often with a confirmation that a Strategy Guide or equivalent quotation has been prepared, signalling that the enquiry has been qualified and is ready for a concrete proposal.
  4. From Created Lead, the professional sends an offer or quotation email (or, in Direct Service contexts, a structured Direct Service offer) specifying scope, fees, payment structure and next steps; the email is stored in the Emails tab and becomes the basis for whether the case continues as a full Regular Enquiry, a Paid Consultation‑only engagement, a Direct Service, or is later eliminated.

3.4 Client response & work stage (In Progress / Waiting for Response)

  1. When the client confirms they wish to 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 key conversations, documents received and decisions.
  2. If the next action depends on the client or third parties (for example, waiting for documents, decisions, or 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 reminders, list filters (such as Current Clients, Expired Clients) and admin monitoring rely on Waiting for Response combined with Next Progress Date to identify cases that have not been followed up on schedule, feeding into Expired and NPD‑related views if inactivity persists.
  4. Throughout the work stage, users attach and manage emails, internal messages, documents and tasks within the client record so that the full context of the Regular Enquiry remains visible to both professionals and admin, supporting hand‑overs and audits.

3.5 Payments, completion & closure

  1. Each time the client pays fees (consultations, fixed‑fee work, ongoing services), the professional records the payment in the Payments tab, including amount, date, method and notes, ensuring each payment is correctly associated with the relevant part of the work.
  2. BackOffice aggregates payment records and, based on Enquiry Type and user role, calculates Advocate Abroad commission and any referral or delegatee shares, which are later used to generate invoices, internal commission statements and payout summaries.
  3. When the professional considers the work complete, they change the status to Completed; a completion popup requests confirmation of total fees received, compares this with recorded payments, and warns if a mismatch is detected so the user can correct payments before proceeding.
  4. Completed cases appear in admin review lists such as Daily Updates, where admin verifies payments, decides on survey and feedback emails, and confirms that the record is ready to move to Closed.
  5. After admin review, the status is set to Closed, indicating the Regular Enquiry is finished; any remaining surveys or feedback emails are issued, and the record becomes eligible to progress into GDPR anonymisation or deletion according to retention rules.

3.6 Elimination & inactivity‑driven outcomes

  1. If the client clearly does not wish to proceed, selects another provider, remains unresponsive despite reasonable follow‑ups, or the service is outside scope, the user changes status to an eliminating outcome such as Eliminated, Rejected or Unsuitable.
  2. On selecting an eliminating status, a popup requires the user to choose or enter an elimination reason (for example, no response, service not offered, client unsuitable, client withdrew), ensuring follow‑ups are stopped immediately and lost‑lead analytics remain meaningful.
  3. Leads left in NPD – Awaiting Assignment or similar inactive states beyond configured thresholds are surfaced in dedicated Admin views (for example, Expired Clients, Unassigned Leads) and summary emails, 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 tuned without code 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 closed states.

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 ad‑hoc promises 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.

No comments to display

Back to top