Lead/Enquiry Architecture (The 3 Formats)


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.

Format B: Paid Consultation

1. General description

Paid Consultation is a consultation-only workflow in BackOffice where a client pays for a scheduled time-slot (video or phone call) without committing to a full legal service engagement.

Paid Consultation is used for exploratory or lower-value enquiries where the client wants professional advice before deciding whether to proceed with a full service.

When a client is classified as Paid Consultation, the system sets the is_consultation_only flag on the client record, which tailors the behaviour of the Strategy Guide, notifications, and status flow.

Paid Consultation records can later be upgraded to full-service leads by executing the ConvertPreliminaryToLead action, which removes consultation-only constraints while preserving the consultation history.

This process sits primarily in BackOffice, with configuration and scheduling support coming from Laravel (enquiry type settings, consultation durations, calendar integration and email templates).

2. Business goals and objectives

The Paid Consultation workflow is designed to monetise enquiries that may not immediately convert into full legal services while maintaining clear separation in reporting.

  • Monetise exploratory enquiries by charging for a structured advice session instead of providing extensive free advice by email or telephone (many people contact us seeking information, but only some of them are prepared to pay money for legal assistance - we must filter-out those who are not intending to ever pay for a service or the Lawyers will become unhappy with our service and potentially leave the network).
  • Provide efficient triage so Users can quickly determine whether there is a viable case before investing effort in full strategies and quotations.
  • Offer client decision support by allowing clients to discuss options and next steps before committing to higher fees.
  • Maintain workflow hygiene by separating consultation-only records from full-service leads in dashboards and statistics.
  • Suppress inappropriate automated reminders to clients who only requested a one-off consultation, reducing the perception of aggressive chasing.

3. Detailed behaviour and step-by-step flow

The Paid Consultation behaviour covers intake classification, offer preparation, payment recording, calendar scheduling, consultation delivery, and post-consultation decisions.

  1. Phase 1: Intake and classification
    1. Client submits an enquiry via website form or via a call captured in Elevenlabs and pushed into BackOffice.
    2. Admin reviews the enquiry in the Laravel assignment interface and decides whether it should be treated as Regular Enquiry, Direct Service Offer, or Paid Consultation.
    3. If the enquiry is exploratory, lower-value, or the client explicitly asks for a consultation, Admin selects the Paid Consultation workflow for that record.
    4. The system sets is_consultation_only = true on the client record, activating consultation-only behaviour such as 'Benefits of a Consultation' instead of Strategy Selection and notification suppression.
  2. Phase 2: Preliminary email drafting and review
    1. When the client record is created in BackOffice, usually no User is assigned initially; Admin first selects or drafts a Preliminary Email to propose a Paid Consultation.
    2. The Preliminary Email is generated using the standard Legal Consultation Email AI prompt and is intended to show empathy, demonstrate expertise, outline typical problems and possible steps, and present the proposed consultation fee.
    3. If the Preliminary Email template has not been previously reviewed by a lawyer, Admin assigns the record to an appropriate User and clicks Request Feedback to send the email draft for legal and fee review.
    4. The assigned User receives a notification, reviews and edits the Preliminary Email, then clicks Confirm to return the approved version to Admin for sending to the client.
    5. If the chosen email template has already been reviewed and approved, Admin may send it to a new client without requesting feedback - often the fee for a Paid Consultation will lie between €120 - €350, with a majority in the €150 - €200 area, so Admin will feel confident if the fee is set around these levels without requesting feedback from a User who has not yet provided this specific Paid Consultation, since other Users have approved the legal references in the text and the fee is 'standard'. the record will typically remain unassigned until the client responds. This is important as it means lawyers are not required to do any work and are only notified when they receive confirmation of client authorization to proceed with the Paid Consultation.
  3. Phase 3: Consultation offer preparation
    1. Once the client responds positively to a Preliminary Email, Admin will assign a User (if not already done) and use the 'Convert to Lead' button which sends a notification email to the assigned User with link to the client record in order to move to the next stage of the process whihc is to send the 'Paid Consultation Offer Email' to the client
    2. For consultation-only records, the Strategy Guide tab displays a simplified interface focused on consultation pricing and scheduling instead of full service proposals.
    3. The User sets consultation parameters, including fee, duration, date/time options, and communication channel, using data such as the client’s timezone available on the record.
    4. The User then generates an offer email that includes the consultation fee and VAT, proposed date/time slots, duration, payment instructions, and a brief description of what will be covered in the session.
    5. The User clicks Send Offer Email; the system sends the email, logs a copy in the Emails tab, leaves the record in its preliminary lead state, and adds an Updates Record entry indicating that a consultation offer was sent.
  4. Phase 4: Client confirmation and payment
    1. The client reviews the consultation offer and confirms acceptance by replying to the email.
    2. The client pays the consultation fee to the User’s bank account or via the online payment option provided (e.g., PayPal or card link).
    3. The User opens the Payments tab, registers the payment with amount, payment method and payment date, and ticks the Consultation Only checkbox to identify it as a consultation payment - is this correct?
    4. The system records the payment but does not automatically advance the status; the User remains responsible for updating the status as the consultation process progresses - is this correct?
  5. Phase 5: Scheduling on calendar
    1. The User and client agree the final date and time for the consultation - the User must select a date and time before sending the Offer Email, though the client can access the Calendar to select an alternative time when according to the User's synced Calendar, the User is available.
    2. When the User selects the initial date and time for the appointment, a corresponding calendar event using the Laravel scheduling integration; if the channel is video, a Zoom or Teams link is added or generated. This will be updated if the User or Client decide to change it - but only before the time of the scheduled appointment. After that, the User must select a new date and time in the 'My Meetings' section of the BO.
    3. The system updates the client record status to Created Lead, creates or links the calendar event, and logs an Updates Record entry indicating that the consultation has been scheduled.
  6. Phase 6: Consultation delivery
    1. Before the meeting, the User reviews the enquiry details and any previous messages or documents in the client record.
    2. The User conducts the consultation by video or phone at the scheduled time and covers the topics agreed in the offer.
    3. After the session, the User records post-consultation notes in Messages or the Updates Record, summarising key points and agreed next steps.
    4. If the User does not receive payment, and the day of the appointment arrives, the User may use the 'Send Payment Reminder' button to send a pre-formatted email to the Client explaining that, as yet, no payment has been received, and this is a necessary pre-requisite for the Consultation to take place. We should send a reminder to the User the morning of the Consultation - say 8am, with link to the client record (strategy guide section with 'Payment Reminder' button visible - so they can check their bank account and quickly send this email reminder to the client.
  7. Phase 7: Post-consultation decision
    1. After the consultation, the User decides how to progress the record based on the client’s intentions and the viability of further work.
    2. If the client does not require further services, the User sets the status to Completed; a consultation-only completion popup may appear and a client survey can be triggered.
    3. If the client wishes to proceed with full service, the User clicks the Convert to Lead button, which triggers the ConvertPreliminaryToLead backend action, upgrades the record to a standard lead, removes the consultation-only constraint and enables full Strategy Guide and Direct Service options. This process needs to be made more simple. E,g. when setting to Completed, perhaps have simple question: 'Does the client require more services? Yes/No' - if Yes, then converts to lead automatically.
    4. If the client needs time to decide, the User sets the status to Waiting for Response or Freeze, and may set a Next Progress Date as a manual reminder without relying on automated chasers. This could be added to the options in the Does the client require more services? question, so that if selected, they can select a future date for the client record to unfreeze and send a reminder notification to the User to contact the client.

4. Confusions, edge cases and known issues

The Paid Consultation workflow has several recurring points of confusion that affect both Users and Admin.

  • Missing Convert to Lead button: Users may not see the Convert to Lead button if is_consultation_only is not correctly set to true; they must verify the Overview tab and consult Admin if the flag is wrong.
  • Unexpected automated reminders: If a consultation-only record still receives reminder emails, it usually means the consultation-only flag was never set or was cleared; Admin must correct the flag and ensure notification suppression is active.
  • Limited Strategy Guide options: Users sometimes think the Strategy Guide is broken when only consultation-specific options appear; this is expected for consultation-only records and full templates are available only after conversion to a lead.
  • Consultation fee not deducted from full service: Some clients expect the consultation fee to be credited against future work; any deduction must be manually built into the quotation since there is no automatic offset in the system.
  • Status not changing after payment: Users may expect the status to automatically move after a consultation payment is added; statuses must be updated manually as adding payment does not change status for consultation-only records.
  • Calendar and timezone issues: Incorrect video links or time mismatches usually stem from misconfigured Laravel calendar integration or incorrect user timezone settings and must be checked there.

5. Permissions and access rules

Paid Consultation access is controlled through profession, country and role-based rules across Laravel and BackOffice.

  • Users only receive Paid Consultation enquiries that match their Profession and Country tags defined in Laravel and their enabled Enquiry Types.
  • The is_consultation_only flag on the Overview tab is editable by Admin only; Users cannot toggle this flag themselves.
  • When is_consultation_only = true, the Strategy Guide tab is restricted to consultation-focused options and hides full-service templates and quotation profiles.
  • Any assigned User on a consultation-only record can execute the ConvertPreliminaryToLead action via the Convert to Lead button; this upgrade does not require separate Admin approval.
  • Users cannot mark a Paid Consultation as Completed if no payment has been recorded (total payments equal zero); completion is blocked until at least one payment is registered.

6. Timing, deadlines and automation

The Paid Consultation workflow applies looser timing rules than regular enquiries but maintains clear constraints around payment and anonymisation.

  • Paid Consultations do not use the strict “contact within 24 hours” rule used for standard leads, though prompt manual contact is still recommended.
  • Automated reminder emails are suppressed for consultation-only records; they are excluded from reminder cron jobs by the notification suppression logic.
  • Consultations should generally be scheduled with at least 24 hours’ notice to allow time for payment verification and preparation - this is perhaps not adequately controlled. Sometimes lawyers simply don't think and schedule a Paid Consultation at 8pm for the next morning - we should display a warning if the User schedules a time that is less than 48 hours away, such as: "The client must make a payment transfer before the scheduled appointment - are you giving them sufficient time to pay?"
  • Payment for the consultation must be received before the consultation is conducted; there is no built-in support for post-consultation billing in this flow.
  • If a consultation-only record is closed as Eliminated or Completed and never converted to a full lead, it becomes eligible for GDPR anonymisation after six months from closure.

7. Dependencies and related processes

The Paid Consultation flow depends on correct configuration in Laravel and interacts with multiple BackOffice processes.

  • Enquiry Types must be configured in Laravel to support the Paid Consultation workflow, including pricing defaults and flags indicating consultation suitability.
  • User calendar integration in Laravel must be correctly set up for scheduling video or phone consultations and generating links where applicable.
  • User payment details (such as bank account information) must be configured in their profile so that consultation Offer Emails can include correct payment instructions.
  • Paid Consultation Offer Emails rely on the dedicated Paid Consultation Response Email template, managed in the central email template library.
  • When a consultation converts to full service, the ConvertPreliminaryToLead process activates the standard lead lifecycle, including strategy selection, Direct Service offers and recurring service setup.

8. Error handling and recovery

The Paid Consultation process includes specific recovery patterns for assignment, payment and conversion issues.

  • If payment is not received before the scheduled consultation, there is no automatic cancellation; Users are expected to cancel or reschedule and avoid delivering unpaid consultations.
  • If the ConvertPreliminaryToLead action fails technically, Admin can manually clear the is_consultation_only flag and adjust the status to a standard lead, then coordinate with developers to resolve root causes.
  • If calendar integration fails to create or sync the event, the User should create a manual calendar entry and report the issue to Admin for technical follow-up.
  • Because adding a consultation payment does not change status automatically, Users must correct any status mismatches manually if a payment was recorded but the status was left in a preliminary state.

9. Performance and scalability

No specific performance or scalability constraints are documented for the Paid Consultation process beyond general BackOffice and Laravel behaviour.

Developers should ensure that consultation-specific filters in Strategy Guide, notification suppression checks and ConvertPreliminaryToLead actions are implemented efficiently but there are no special pagination or batching rules unique to this workflow.

10. Configuration and customisation

The Paid Consultation workflow is partially configurable via Laravel settings and Enquiry Type configuration.

  • Default consultation fee ranges can be configured per Enquiry Type in Laravel under pricing settings, providing guidance for Users when they set consultation fees. is this true? Is it necessary? The fee is normally set in the Preliminary Email by Admin in consultation with the Users.
  • Available consultation duration options (for example, 30, 45 or 60 minutes) can be configured in Laravel consultation settings. - since deprecated?
  • Video platform preferences (Zoom) are configured in Laravel integrations and determine which platform links are used when scheduling consultations. this is not true, but perhaps should be. Perhaps we could offer Google Meet also - whatever the User is comfortable with using.
  • The Paid Consultation Offer Email template is managed in the email template library and can be customised for wording, structure and placeholders without code changes.
  • The consultation-only behaviour itself, including the is_consultation_only flag, notification suppression and Strategy Guide filtering, is hard-coded business logic that would require code changes to alter.

11. Notifications and communication rules

Paid Consultation uses standard notification mechanisms with additional suppression rules for reminders.

  • When a Paid Consultation enquiry is assigned, the User receives the normal New Client Assigned notification with an indication that the record is consultation-only.
  • Sending a consultation Offer Email to the client is user-triggered and logs a copy in the Emails tab but does not trigger automated follow-ups specific to consultations.
  • Consultation confirmation emails are also user-triggered and contain the final date/time, connection details and preparation instructions.
  • When a consultation is marked as Completed, a client satisfaction survey can be sent depending on survey configuration, similar to other completed cases.
  • Consultation-only records are explicitly excluded from automated reminder email flows, so they do not receive standard lead-chasing campaigns or Direct Service chasers.

12. Historical changes and updates

Paid Consultation behaviour has been refined over time to clarify its separation from Direct Service and Regular Enquiries and to ensure that automated reminders are correctly suppressed.

Adjustments were made to bind consultation-only behaviour to the is_consultation_only flag, restrict Strategy Guide options, enforce payment-before-completion rules, and add the dedicated Convert to Lead upgrade path.

13. Compliance and legal considerations

The Paid Consultation workflow must comply with GDPR and financial audit requirements while preserving clear fee information for clients.

  • Clients must agree to Terms and Conditions and privacy notices before any consultation takes place; this is handled at enquiry or onboarding level.
  • Consultation payments must be received before service to avoid disputes over unpaid work and to ensure accurate commission and revenue reporting.
  • Each consultation payment declaration creates an immutable log entry in the Updates Record and Payments tab; any corrections require a Credit Note workflow rather than silent edits.
  • Offer Emails must state consultation fees and any applicable VAT or taxes clearly, including the currency and taxation basis.
  • Consultation-only records that do not convert to full leads follow the standard anonymisation and deletion timetable after closure, supporting clients’ right to be forgotten.

14. Backend services and integration points

The Paid Consultation workflow relies on several backend components that determine record behaviour and available actions.

  • The is_consultation_only flag on the client record is a boolean field that switches the record into consultation-only mode and is consumed by Strategy Guide, notification logic and status rules.
  • The ConvertPreliminaryToLead backend service upgrades a consultation or preliminary record to a standard lead, preserves the existing history, and lifts consultation-specific restrictions.
  • Notification suppression logic checks is_consultation_only before including records in automated reminder cron jobs, ensuring consultation-only records are excluded.
  • Strategy Guide filtering respects the consultation-only flag, showing only consultation strategies and hiding full-service strategy templates until conversion.
  • The Paid Consultation Response Email template is stored in the central template catalogue and is referenced when generating consultation offer emails.

15. Behavioural guardrails and PM guidance

The Paid Consultation process includes soft rules to protect revenue, client experience and data quality, supported by specific UI and backend mechanisms.

  • Users should avoid giving extensive written advice before a consultation is confirmed and paid; instead,  the Preliminary Email and Paid Consultation offer structure should be used, supported by the dedicated email templates.
  • Users must always record consultation payments in the Payments tab and tick the Consultation Only checkbox before marking the consultation as Completed; the completion wizard enforces this requirement.
  • Consultation-only records should be kept separate from full leads; Users should use the Convert to Lead button rather than manually changing statuses or flags to start full-service work. - Admin uses 'Convert to Lead' button when the client agrees to the Preliminary Email. Is there another 'Convert to Lead' button? I think this is referring to 'Convert to Regular Lead' - but I am not aware of the button. Need to check this.
  • Users should always verify that the consultation date/time in the calendar matches the client’s timezone as displayed on the record, using Laravel integration rather than ad hoc links.
  • If in doubt whether an exploratory enquiry should be treated as Paid Consultation or Regular Enquiry, Admin should favour Paid Consultation for low-commitment cases to ensure time is covered and full-strategy work is reserved for genuinely engaged clients.

Format C: Direct Service Offer Enquiries

General Description


Direct Service Offer is a workflow where the client is immediately offered a clearly defined service package (scope, fee, and payment instructions) rather than an exploratory consultation or open‑ended quotation process. This is preferable to assigning to a User, because the value is low for these services and the risk that the client would use the opportunity presented by a call from a lawyer to obtain information about the legal process.

This would include requests for all types of certificates, and some other low value highly-standardised legal processes that have little variation and can easily be presented to the client by email - if the client responds, agreeing to the proposal, great! If not, no big loss.

It is used when the enquiry fits a standardised service that Advocate Abroad can package and price upfront - typically obtain  and the business goal is to convert quickly with minimal back‑and‑forth.​

When a Direct Service Offer is created, the system marks the record as a Direct Service (isdirectservice = true / Direct Service flag in Overview) and switches on Direct Service–specific behaviours, including templated offer emails and automated follow‑up reminders if the client does not respond.

The client can later be handled as a normal full service lead (Created Lead / In Progress, etc.), but the Direct Service nature of the enquiry remains visible for reporting and automation rules.

Goals & Objectives

Step‑by‑Step Procedure

Phase 1: Intake & Classification

  1. Enquiry Received

  1. Admin Classification

Phase 2: Configure Direct Service Strategy


3. Open Direct Service Configuration

  1. Select Strategy Guide and Template

    In the Direct Service configuration popup:​

  1. Preview & Adjust Offer

Phase 3: Send Direct Service Offer


6. Send Offer Email

  1. Initial Follow‑Up Window

Phase 4: Follow‑Up Automation


8. First Automated Follow‑Up

  1. Second/Final Follow‑Up

  1. Expiry

Phase 5: Client Responds to Direct Service Offer


11. Client Response Handling

  1. Convert to Active Work

    Typical paths after a positive response:

Phase 6: Elimination & Re‑activation


13. Elimination from Direct Service

  1. Client Returns After Elimination

Common Confusion & Errors

Issue Description Resolution
Direct Service vs Paid Consultation Users confuse Direct Service Offer (full service proposal) with Paid Consultation (advice‑only call) because both share some Strategy Guide UI elements. Check the Overview flags: Direct Service flag vs is_consultation_only; only Direct Service records trigger Direct Service chaser emails and use Direct Service templates.
Templates not appearing Users expect one‑off edited texts to show in the Direct Service template dropdown. Only texts saved via Save As New Template appear as reusable Direct Service templates; one‑offs remain bound to the specific client.​
Direct Service follow‑ups still sending after elimination Users forget that follow‑ups continue while status is Direct Service even if they consider the case “dead”. Always change status to Eliminated – Rejected / Unsuitable to stop Direct Service follow‑ups; this immediately cancels scheduled Direct Service reminders.​
Loss of Direct Service context after status change In earlier iterations some flows treated returning clients as regular leads without keeping Direct Service history. Business rule: any status transitions must preserve the Direct Service flag; eliminating and re‑opening should not convert to Paid Consultation or strip Direct Service reporting fields.​

Permissions & Access Control Rules

Timing, Deadlines & Automation Rules

Rule Description
24‑Hour Contact Expectation Direct Service enquiries still fall under the general expectation that the assigned professional contacts the client within about 24 hours, even though the first contact may be a templated offer.​
Direct Service Follow‑Up Schedule First automated Direct Service reminder sent about 48 hours after initial Direct Service Offer if no response; a final reminder follows after an additional delay (around 7 days total).​
Follow‑Up Cut‑Off After the configured final Direct Service follow‑up, no further automatic Direct Service chasers are sent; status remains Direct Service until manually changed.​
Elimination Effect Changing status from Direct Service to Eliminated immediately stops all planned Direct Service follow‑ups.​
GDPR Anonymisation Direct Service enquiries that never proceed to active work and are set to Eliminated become eligible for anonymisation after approximately six months of inactivity, in line with general non‑engaged enquiry rules.​

Related Processes & Dependencies

Error Recovery & Retry Logic

Scenario System Behaviour Recovery Action
Autoassign failure for a potential Direct Service case Lead is created with status NPD – Awaiting Assignment and an Admin alert is sent; no Direct Service Offer can be sent until someone is assigned or Admin intervenes. Admin assigns a suitable user from the Unassigned Leads view or decides not to proceed (Eliminated); then initiates Direct Service Offer if appropriate.
Direct Service Offer email fails to send Email client returns a send error; the UI shows a message such as “Email could not be sent, please try again or contact support.” User retries sending the offer, or contacts Admin/devs if repeated failures occur; no automatic resend loop is configured.​
Client replies but remains in Direct Service with expired follow‑ups Follow‑up scheduler does not change status on email receipt. User manually updates status to Created Lead / In Progress as soon as they start substantive work; this resumes standard workflow and statistics.​
Direct Service flag removed incorrectly Earlier bugs or manual overrides may have stripped the Direct Service flag when switching statuses. Admin corrects Overview flags in the client record and confirms that status logic preserves Direct Service behaviour going forward (do not convert to Paid Consultation).​

Performance & Scalability Considerations

Configuration & Customisation Options
Setting Location Description
Direct Service Offer Strategy Guides Laravel > Strategy Guides Define per‑ET, per‑country Direct Service packages (questions, proposals, default fees) used when constructing Direct Service offers.​
Direct Service Offer Template BO Email Templates / Laravel Templates (Direct Service category) Email bodies for initial Direct Service offers (ID category “Direct Service Offer Template” in notification section).​
Follow‑Up Templates & Delays Laravel / Notification Templates – 9.3 Direct Service Followup Emails Templates for first and second Direct Service chasers and their timing configuration.​
ET‑Level Defaults Laravel > Enquiry Types Default fee ranges, commission, country constraints, and recurring flags that apply to Direct Service strategies for that ET.​

Notification & Communication Rules

Event Recipient Timing Content
Direct Service Offer sent Client Immediately on Send Offer Full Direct Service proposal: scope, fees, VAT, payment instructions, next steps.​
Direct Service Offer sent (internal) Assigned User Immediately Summary that a Direct Service offer has been sent for the client, with link to the record.​
Direct Service follow‑up 1 Client ~48 hours after offer, no response Polite reminder about the Direct Service proposal with reference to original scope and fee.​
Direct Service follow‑up final Client After configured delay (e.g., 7 days total), if still no response Final reminder indicating the offer is still available but may expire; no further automated chasers afterwards.​
Direct Service expiry Admin/User After final follow‑up Dashboard/notification indicating “Direct Service offer expired” so User/Admin can decide whether to Eliminate or re‑engage manually.​
NO Automated Suppression N/A N/A Unlike Paid Consultation, Direct Service records are explicitly included in follow‑up reminder automation until eliminated.

Historical Changes & Deprecations

Backend Processes / Code Services