Business Logic


Lead/Enquiry Architecture (The 3 Formats)


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.
Lead/Enquiry Architecture (The 3 Formats)

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.
Lead/Enquiry Architecture (The 3 Formats)

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

Statuses & Substatuses

Statuses & Substatuses

Status & Sub-Status Architecture

Main Statuses and Sub-Statuses

The platform uses a dual-layer tracking system to manage the lifecycle and audit trail of every client.

A. Main Client Statuses (Lifecycle & Visibility)

Status Definition Visibility Rule Trigger Effects
Created Client has moved beyond a raw website lead and a professional has begun an initial structured response (e.g., quotation, strategy, or confirmation of scope), but full engagement is not yet confirmed or work is only at preparation stage. Appears in Current Clients and All Clients lists; excluded from Daily Updates, New Enquiries and Expired-clients admin views. Set when a New Enquiry is converted to an active lead (for example, via strategy or quotation flow, Direct Service offer accepted in principle, or Paid Consultation confirmed) without yet being marked as Ongoing. Enables standard contact and follow-up automation such as reminders and dashboards; included in workload and pipeline statistics; not yet eligible for completion or anonymisation flows.
Ongoing Client has formally engaged services and active work is in progress (retainer agreed and/or payment declared); used as the main working status for active matters, including delegatee records in recurring services. Visible in Current Clients and All Clients; excluded from New Enquiries and archive-only views; appears in professional dashboards and workload reports. Set manually by the User or Admin once the client confirms instruction and work has started, or when recurring delegatee records are created and activated. Included in inactivity checks and workload monitoring; eligible for blocking tasks such as Add Payment; prevents anonymisation or expiry while active work or recurring cycles continue.
Hibernated Status for recurring services where the principal record sleeps between cycles while ongoing work happens on delegatee records; no day-to-day actions are expected on the principal. Shown in All Clients but excluded from Current Clients lists; principal records may be hidden from some workload views while delegatee records remain visible as Ongoing. Set when configuring or updating a recurring service so that a principal record is parked and a delegatee record handles the live monthly or periodic work. Principal record is excluded from standard reminders and many dashboards; certain actions such as delegatee status changes or payments may be restricted or warned; returns to Ongoing or Closed when the recurring service is resumed or terminated.
Completed Work on the matter is finished and all agreed fees have been declared and recorded in the Payments tab; from the professional’s perspective the case is fully delivered. Visible in All Clients and in admin review queues such as Daily Updates, but not in Current Clients; treated as an archive-ready operational state. Set by the User when confirming completion via the completion popup, including fee confirmation and any required billable-action summary, once final payment is declared. Triggers the client satisfaction survey (Rate your lawyer) and related review workflows; prepares the record for Admin finalisation to Closed and for later anonymisation or deletion timers.
Closed Admin-verified final state indicating the matter is fully finished, payments checked, survey logic handled and reporting or Intelliquote updated; used as the long-term archival status. Visible only in All Clients and archival or historical lists; excluded from Current Clients and most operational dashboards. Set by Admin after reviewing a Completed case, checking payments, surveys and reporting, and confirming that no further operational actions are pending. Starts anonymisation and deletion countdown according to GDPR rules; removed from active metrics except historical reporting.
Non Responsive Status indicating that, after a defined sequence of chaser emails and reminders, the client has not replied and is treated as inactive without explicit elimination. Shown in All Clients but normally excluded from Current Clients and from standard reminder queues; may appear under non-responsive filters where configured. Set automatically after configured non-response thresholds are reached (for example, multiple unanswered chasers), or manually by Admin or User where policy allows. Stops further chaser emails and non-response sequences; case may later be moved to Eliminated or Rejected, or reactivated if the client returns and re-engages.
Eliminated Lead or client that will not proceed, typically due to price, choosing another provider, ghosting after quotation, or explicit refusal; used as a general dead-lead or not-proceeding state. Visible only in All Clients and archive-oriented lists; excluded from Current Clients, New Enquiries and most workload dashboards. Set via a status-change popup where the User or Admin selects a reason; in Direct Service flows, also used when stopping a Direct Service offer that will not convert. Immediately stops all follow-ups and chaser automations, including Direct Service sequences; record becomes eligible for anonymisation and deletion after the configured retention period and may be used in lost-lead and conversion statistics.
Rejected Admin review state for leads that have been eliminated or otherwise not proceeded with, used to confirm classification and decide whether a feedback survey should be sent. Visible in All Clients as part of archive and quality-assurance lists; excluded from Current Clients; may have dedicated reporting views for quality and conversion analysis. Set by Admin when reviewing Eliminated or similar cases to finalise outcome coding and survey behaviour. Can trigger a rejected-or-feedback survey depending on configuration; starts anonymisation timers and finalises conversion-loss categorisation for reporting.
Unsuitable Enquiry Lead classified as invalid or out of scope for Advocate Abroad, for example spam, wrong country or jurisdiction, service not offered, or clearly inappropriate request. Visible only in All Clients and specific admin views for unsuitable or filtered enquiries; excluded from Current Clients and standard lead or engagement metrics. Set when Admin or User determines the enquiry should never proceed, usually during early triage, via a reason popup or classification control. Stops chaser and marketing emails; record is excluded from most performance statistics and routed toward earlier anonymisation or deletion while preserving the minimal audit trail that is required.
Expired Indicates that the Next Progress Date on a client record has passed without being updated, so the file is overdue for review and follow-up even though its main workflow status may still be Ongoing or another active state. Expired records continue to appear in All Clients and, where relevant, in Current Clients according to their underlying workflow status; they also appear in the Expired-clients admin view and as Expired leads in the Daily Updates queue until reviewed. Set automatically when the calendar date moves beyond the stored Next Progress Date and no new date is set; in some configurations further automation may run if a record remains expired beyond a defined grace period. Groups unattended active matters that need attention; Users should review the client, contact where appropriate, update the Next Progress Date or change status to Completed, Closed or Eliminated so the record no longer appears as expired.
Freeze Client Temporary on-hold state that pauses reminder emails, automatic status checks and unassignment rules for a specific client without treating the enquiry as Eliminated or Completed, typically when the client or User has requested a short pause. Frozen records remain visible in the User’s normal client views (for example, Current Clients or All Clients) according to their underlying status, but are excluded from expiry-based auto-elimination and some SLA-driven reminder queues until the freeze period ends. Applied by Admin, usually following a request from the User or client, by setting a future Next Progress Date and marking the record internally as frozen for a specific period. Keeps the enquiry in Created or Ongoing without triggering non-contact workflows, unassignment or auto-elimination while the agreed pause is in effect; manual actions remain possible and, once the freeze date passes or the User acts earlier, normal follow-up rules resume.

B. Sub-Statuses (Action Audit Trail)

Sub-statuses are auxiliary flags set automatically by the All Actions workflow or by specific user actions and system events. They provide a fine-grained audit trail of contact attempts, offers, reminders and GDPR processing without replacing the main lifecycle status.

1. Created

What it is

First live status for a client record. The lead has moved beyond the New Enquiry intake tag and is now an active case, often under a named professional.

For some Paid Consultations and Direct Services, a client record may remain unassigned if a Preliminary Email can be sent without lawyer review and the client never responds.

When it is used

How it differs from New Enquiry

Main behavioural effects

Sub-status behaviour (Created)

Consultation Offer Sent – Pending Client Response

Used in the Paid Consultation workflow when Admin or User has sent a Consultation Offer Email and the system is awaiting the client’s reply/payment.

Offer Email Sent – Pending Reply

Used for regular enquiries when an Offer Email has been sent; status remains Created while the system waits for a response.

If there is no response and no payment within a defined window, reminder emails are sent; ongoing silence typically leads to Eliminated, often with a feedback survey.

Change To Consultation Requested

Used when, after speaking with the client, the User believes the engagement should be limited to a paid consultation and requests Admin approval to switch format.

Preparation – Pending User Review

Indicates Admin has drafted a preliminary email (Paid Consultation or Direct Service) and is awaiting User confirmation before sending to the client.

2. Contacted

This legacy status appears in older descriptions as “User has sent the first email or made the first call”, but is rarely used in the current system.

Modern flows rely on Created/Ongoing plus the Record Contact Results audit trail instead; Contacted should be treated as deprecated with no new behaviour added.

3. Ongoing

What it is / when used

Main behavioural effects

Sub-status behaviour: Call outcomes and non-response

The Strategy Guide “Contact” step and Record Contact Results modal (via All Actions) drive several non-responsive and phone-problem sub-statuses.

Further lack of response can trigger admin reminders and ultimately automatic movement to Eliminated plus a survey email.

Requested Contact By Email

When a client explicitly asks for email-only contact, the User can set Requested Contact By Email; Admin approval typically moves the case to Ongoing with email access but no scheduled calls.

4. Hibernated status

What it is

The Hibernated status is used for clients who receive recurring services (for example, annual non-resident tax, quarterly rental tax, annual income tax returns), where no further work is required until a future period.

When to use Hibernated

In these cases, instead of setting the status to Completed, the User sets the client record to Hibernated so that it is removed from the normal Current Clients list until the service is next due.

How Hibernated works

Typical recurring cycle

  1. Client is assigned and the User receives instructions.
  2. User provides the service for the current period and records the client’s payment.
  3. User sets the status to Hibernated so the file is removed from the active list until the next period.
  4. On the configured date (with some lead time - set by Admin at ET level in 'Recurrence' Section), the system automatically:
    • Returns the status to Ongoing, and
    • Notifies the User with a list of all such clients to start work again.
  5. After the new period’s service is delivered and payment is recorded, the User again sets the client to Hibernated, and the cycle repeats.

Relation to recurring services

For services marked as “On Recurring Payments” or otherwise defined as cyclical, Hibernated is the standard status between service periods: the recurring behaviour begins as soon as the first period’s work has been completed and its payment added, at which point the record is moved to Hibernated instead of Completed.

5. Completed

What it is / When it is used

Completed is the status used when all work for the current engagement has been carried out and the essential financials are in place, but before the final administrative closure in Closed.

Use Completed when:

  • The agreed service has been fully delivered (consultation held, procedure finished, document drafted or executed, tax filing completed, etc.).
  • All payments for that service have been entered in the Payments section; if a required payment is missing, the system can block changing to Completed (users often report “case is terminated but I cannot click on the completed button” until payments are added).
  • The matter is effectively finished and only survey/feedback or admin review is pending.
  • The service is one‑off, not recurring; recurring yearly/quarterly matters should generally go to Hibernated instead so they re‑activate automatically when due.

Main behavioural effects (what Completed means)

  • The file is removed from active day‑to‑day worklists for the user and becomes a finished job awaiting feedback and/or admin processing.
  • A survey decision is required via the Completed Survey Wizard and, depending on the choice, a feedback or review email is sent (or deliberately not sent) to the client.
  • For non‑recurring work, Completed marks the practical end of the service; the next lifecycle step is normally an Admin change to Closed after surveys and reporting (for example Intelliquote, commission checks) are handled.
  • For KPI and reporting, Completed contributes to statistics about finished matters, fees and client satisfaction; mis‑using Completed (for example without recording payments) leads to Admin queries and incorrect figures.

Before changing to Completed, the user should:

  • Add all client payments in the Payments tab for that record.
  • Leave a short comment in Updates Record confirming that the work is finished and adjust the Next Progress Date if requested by Admin practice, even if the file is about to be closed.

Completed Survey Wizard

When the user changes Status to Completed in the client record, a Survey Wizard pops up and guides them through mandatory choices and confirmations. The wizard has been refined so that every Completed file results in one of a small number of clearly logged outcomes.

text
Step 1 – Confirm service really is complete
  • The wizard asks the user to confirm that all agreed work for this enquiry has been completed and that all payments due have been added to the Payments section.
  • If payments are missing, the system may block the transition or warn the user to add them first; problems changing to Completed are often resolved by re‑adding missing payments.

User action: tick the confirmation checkbox(es). If blocked, cancel, add payments, then repeat the status change.

Step 2 – Choose survey type or opt‑out

The wizard then forces the user to choose one of the following options.

  1. Standard internal survey: sends the normal Advocate Abroad feedback survey by email, used when the service was delivered as planned and the user expects a reasonable to good rating.
  2. Google review survey (where available): for some clients (typically with Gmail addresses), offers a Google review option that sends a link so the client can leave a public Google Business review. Internal guidance stresses this should be used only where the lawyer is very confident of a highly positive review, because public criticism can seriously damage future enquiries.
  3. No survey – opt‑out (with reason): allows the user not to send any survey in sensitive or borderline situations; the wizard requires a reason, such as:
    • “I did not in fact deal with this client”.
    • “Service partly delivered / atypical outcome – survey not appropriate”.
    • “Client potentially unhappy or conflictive – high risk of negative or unfair review”.
    These reasons are stored so Admin can see why no survey went out.

User action: select Standard survey, Google survey, or No survey; if No survey is chosen, select or type the reason before proceeding.

Step 3 – Confirm client contact address

To avoid bounced surveys and “I did not receive the link” complaints, the workflow includes a check that the client has a usable email address.

  • If the email field is empty or clearly incorrect, the user is prompted to update Client Details before confirming the survey choice.
  • This is particularly important for Google survey links, which require the client to be able to access the email reliably and, ideally, be logged into the correct Google account.

User action: review the client’s email, correct if necessary, then continue.

Step 4 – Record survey choice and update status
  • The wizard records the survey type or opt‑out and reason against the client record for later reporting (who received which survey, who was excluded, and why).
  • It confirms the change of Status to Completed, so the file moves into the “finished work” pool.
  • It may log a short automatic comment in Updates Record summarising the change (for example “Service has been completed… survey: Standard” or “Completed – survey not sent, reason: did not deal with client”).

User action: click Finish/Confirm in the wizard; the system then queues and sends the chosen survey automatically (no manual sending needed).

Step 5 – Admin follow‑up (context for users)

While not part of the user’s actions inside the wizard, its outputs drive later Admin tasks, such as deciding when to move the record to Closed, investigating missing or problematic surveys, and feeding satisfaction data into performance management.

For the user, the key requirement is: do not bypass the wizard; always make a deliberate survey choice and ensure payments and Updates are correct before completing the status change.

6. Closed

What it is / when used

Closed is an administrative closure state used after Admin verifies that work and payments are complete, survey handling is done and Intelliquote or other reporting has been updated.

Admin does this in the Daily Updates List 

Main behavioural effects

Sub-status: Pending Anonymisation

The Pending Anonymisation sub-status indicates that a record has met GDPR criteria for anonymisation and is queued for anonymisation but not yet processed.

7. Eliminated, Rejected and Unsuitable Enquiry

7.1 What these statuses are

Eliminated is used when a lead is effectively dead from the User’s or client’s perspective, typically because the price is considered too high, the client has stopped responding despite appropriate follow‑up, the User cannot assist with the matter, or the client has chosen another lawyer or service provider.

When a User sets a client record to Eliminated, the platform automatically opens the Elimination Wizard, a mandatory multi‑step dialog where the User must confirm the decision, select or enter a specific elimination reason, and complete any required classification questions before the status change is saved.

Rejected is an Admin‑level review status applied after a lead has been moved to Eliminated, used internally to record that the lead will not be pursued and to decide whether a post‑enquiry survey (for example, “Why did you not proceed?”) should be sent.

Unsuitable Enquiry is used where the “lead” is not a valid commercial opportunity at all, for example spam submissions, enquiries for the wrong jurisdiction, or matters clearly outside the scope of services that Advocate Abroad and the network provide.

7.2 When each status should be used

Use Eliminated whenever there was a real enquiry and some possibility of work, but it has become clear that the client will not proceed with the User (for example, the client goes with another lawyer, refuses to pay realistic fees, or repeatedly ignores chasers and reminders); the Elimination Wizard must be completed in full before the record is actually marked as Eliminated.

Use Rejected only from Admin side, after reviewing an Eliminated lead, to mark that it is definitively closed from a marketing perspective and to control whether a satisfaction or “why did you not proceed?” survey is sent to the client; Admin can also adjust the elimination reason or category during this review step if the User’s selections in the Elimination Wizard were incomplete or inaccurate.

Use Unsuitable Enquiry where proceeding would not make sense regardless of price or follow‑up, such as enquiries in a location where the network has no coverage, obvious non‑legal or non‑serious requests, or repeated problematic contacts that have already been blocked.

7.3 Main behavioural effects in the CRM

Moving any client record to Eliminated launches the Elimination Wizard and, once completed, stores the selected reason and any structured fields for reporting, quality assurance and optimisation of marketing, pricing and assignment strategies.

Once a record is in Eliminated, all automated follow‑up mechanisms for that enquiry stop, including chaser emails, “Didn’t Answer” non‑responsive sequences, operator prompts and internal Admin reminder emails.

For Direct Service enquiries, setting the status to Eliminated stops all Direct Service follow‑ups for that lead but does not clear the internal isdirectservice flag, so the enquiry can still be correctly categorised in reports and dashboards.

Enquiries in Eliminated, Rejected or Unsuitable status are excluded from “Current Clients” and similar active‑pipeline views, and are subject to GDPR‑driven anonymisation or deletion according to the platform’s data‑retention rules once the relevant retention period has expired.

7.4 Sub-statuses and NPD linkage

The NPD (Client Not Proceeding) flag is applied where a client declines to proceed before a proper assignment or paid engagement has been created, typically after receiving a quote or initial explanation of services.

When NPD – Client Not Proceeding is selected (either directly or via the Elimination Wizard), the client record’s status is automatically set to Eliminated, while the NPD flag itself is retained separately so that Advocate Abroad can report on volumes and reasons for non‑conversion at this stage.

NPD records behave like other Eliminated leads for operational purposes (no further follow‑ups, excluded from active lists, subject to retention or anonymisation) but can be filtered and analysed as a distinct subset for business‑intelligence and process‑improvement work.

Note: NPD (Client Not Proceeding) should not be confused with NPD (Next Progress Date) – see the Next Progress Date section for rules on scheduling and expiry

7.5 Common misunderstandings and notes

Users sometimes confuse Unsuitable Enquiry with Eliminated when a client simply decides not to pay or chooses another lawyer; in such cases the enquiry was suitable, so the correct status is Eliminated (optionally with NPD selected in the Elimination Wizard to capture the conversion failure accurately.

Admin may later change an Eliminated enquiry to Rejected for survey and reporting purposes, but this does not reactivate follow‑ups or change historical activity; it only affects internal analytics, post‑enquiry communication rules, and how the original Elimination Wizard data is grouped in dashboards.

8. NPD states

8.1 What they are / when used

  • NPD – Awaiting Assignment: initial intake state where no professional has yet been assigned to the enquiry, either because assignment is pending, an automatic assignment rule did not find a suitable match, or the lead has just been created by an operator and is waiting in the assignment queue.
  • NPD – Unassigned: the enquiry previously had a designated professional, but that link has been removed (for example, the lawyer left the network, the Enquiry Type or location changed, capacity rules forced de‑assignment, or Admin manually removed the user) and the client now requires reassignment.
  • NPD – Client Not Proceeding: the client has explicitly or implicitly declined to proceed at the pre‑assignment or early‑contact stage (for example, by rejecting fees, choosing another provider, or confirming loss of interest); the client record’s main status is automatically set to Eliminated, but the NPD flag and reason are retained for non‑conversion reporting.

8.2 Main behavioural effects

  • All NPD states display an orange NPD badge in list views plus a prominent red “No professional designated” banner at the top of the client record, signalling that the matter is not yet owned by any User and must not be treated as an active assigned client.
  • From the NPD banner, Admin (and any roles with assignment permissions) can take two primary actions: Assign User (open the assignment dialog, select a professional and convert the record out of NPD) or Mark Not Proceeding (set NPD – Client Not Proceeding and move the record to Eliminated while capturing a reason).
  • NPD – Awaiting Assignment that remains unresolved for 72 hours (or the configured SLA) automatically acquires an Expired badge and appears in the “Expired Clients” / expired NPD views, highlighting it as a priority for Admin triage; the status itself does not auto‑change, and no professional is assigned until an explicit assignment action is taken.
  • Records in NPD – Awaiting Assignment or NPD – Unassigned do not trigger lawyer‑side follow‑up automations (no lawyer reminder emails, no “Didn’t Answer” sequences) because there is no responsible User, but they may trigger Admin‑level alerts or dashboards to prevent leads remaining unallocated.
  • Records in NPD – Client Not Proceeding behave operationally like other Eliminated leads (no further client follow‑ups, excluded from active client lists, subject to standard data‑retention and anonymisation rules) while remaining filterable as a specific NPD segment for conversion analysis.

9. Freeze client

9.1 What it is / when used

The Freeze function is a temporary on‑hold mechanism that pauses reminder emails, automatic status checks, and unassignment rules for a specific client record without treating the enquiry as Eliminated or Completed.

It is used when a client explicitly asks to “wait” or “come back later” (for example, while waiting for documents, funds, travel, or a decision), or when the User cannot realistically progress the matter for a short, defined period but expects the enquiry to remain active afterwards.

9.2 Who can freeze and how

Users can request a freeze in 2 ways:

  • Simply messaging Admin, (for example, “Can we freeze it until tomorrow at 12:00 Spanish time?”) or
  • In the 'All Actions' > 'Yes' > 'The Call was Rescheduled by Client' or 'Waiting to Receive Documentation'.

If the 2nd option is used, the system will notify the User that the client will receive an email notification that a call has been scheduled for the expiry date that they set (this avoids the Users abusing this functionality to set a Freeze Expiry date in 2040 and effectively remove the client record from their list with no need to contact the client further or do updates)

Admin can also apply freezing proactively, for example where a client will be unavailable for calls due to time‑zone differences, holidays, or health, or where an automatic unassignment or auto‑elimination would otherwise trigger while the lawyer and client have agreed to pause.

9.3 Main behavioural effects

  • While frozen, the client record remains in its underlying workflow status (usually Created ) and is still visible in the User’s client list, but automatic chaser emails, “Didn’t Answer” sequences, and expiry‑based auto‑elimination rules are suspended until the freeze period ends.
  • The Next Progress Date is set to a future date that reflects the agreed “unfreeze” point; until that date passes, the record will not appear as Expired and will not be unassigned or auto‑eliminated for inactivity, even if it would normally do so under standard SLA rules.
  • Freezing does not interfere with manual actions: Users can still call or email the client, add Updates, change status to Completed or Eliminated, or adjust the Next Progress Date earlier than planned if the client re‑engages sooner than expected.

9.4 Interaction with existing statuses

  • For newly created or Created enquiries where the client cannot be contacted immediately (for example, large time‑zone gap or client travelling), freezing prevents the record from being unassigned or auto‑eliminated when the initial contact SLA expires, while keeping it in Created until the agreed call window.
  • There is no need to Freeze an Ongoing status client since these just require the User to set the NPD to an appropriate future date to avoid receiving notifications - there are no automatic client notifications sent while in Ongoing status 
  • A frozen record is never a substitute for long‑term parking statuses such as Hibernated; where a service is cyclical (for example, annual tax filing), the correct medium‑to‑long‑term status is Hibernated with its own reminder cycle, while freezing is reserved for short, exceptional pauses inside an otherwise active cycle.

9.5 Common usage patterns

  • Short deferral for contact logistics: client and User agree to speak the next day or after a weekend due to time‑zone differences or prior commitments; Admin freezes until the agreed date so automatic “no contact” workflows do not fire prematurely.
  • Client‑initiated temporary hold: client indicates they may proceed “in a few weeks” or “next month” but has not definitively declined; Admin or User arranges a freeze until a specific date, after which the matter is treated again as active and follow‑ups resume (or it is moved to Eliminated if there is still no response).
  • Payment‑dependent work: User does not wish to provide further services until overdue fees are paid, and requests freezing “meanwhile” so that reminders and auto‑elimination do not misrepresent the situation while payment is being chased.

10. On Recurring Payments

Indicates that the client is configured as a recurring service (such as monthly tax or accounting) and that recurring payments are expected and tracked.

In practice, it is used together with Hibernated/Ongoing to mark cyclical services; detailed technical rules for when it is first applied are defined at Enquiry Type and workflow level.

11. Daily Updates List (Admin Review Queue)

The Daily Updates List is the Admin’s working queue for reviewing and correcting client files that reach key “end of lifecycle” or risk states. Admin checks this list every day and applies the actions described below.

1) Files set to Eliminated by the User

Purpose: ensure Eliminated is appropriate, reasons are correct, and survey logic is applied properly.

  • Check the Updates Record and email trail to confirm the client really is not proceeding (price issues, ghosting, unsuitable, duplicated enquiry, etc.).
  • Verify that an appropriate Elimination reason was selected and adjust if necessary so reporting and Intelliquote remain accurate.
  • Decide whether a “rejection” style survey should be sent and, if so, trigger or re‑trigger it; alternatively, mark cases where a survey would be unhelpful (conflictive client, mis‑assignment, spam).
  • If a file was Eliminated in error (for example the client later engages), restore to an active status (typically Ongoing) and update the Next Progress Date.

2) Files set to Completed by the User

Purpose: confirm that Completed has been used correctly and that the Survey Wizard outcome and payments are consistent.

  • Check that the service is genuinely finished for that enquiry type (no obvious pending actions in Updates or recent emails).
  • Verify that all expected payments are recorded and that declared fees match the work done; if not, query the user before allowing the file to move forward.
  • Review the survey decision stored by the Completed Survey Wizard (Standard, Google, or Opt‑out with reason) and correct clearly inappropriate choices (for example high‑value, obviously happy client marked as “no survey” without justification).
  • Once satisfied, move the file on to Closed at the appropriate time, which then starts GDPR retention/anonymisation timers and ensures reporting and commissions are finalised.

3) Files with NPD set to > 2 weeks

These are “No Professional Designated” (NPD) or related states where the Next Progress Date has been pushed more than two weeks ahead.

  • Identify NPD files where the Next Progress Date is unusually far in the future (for example > 2 weeks), especially “NPD – Awaiting Assignment” and “NPD – Unassigned”.
  • Decide whether the delay is justified (client asked to wait, seasonal matter, waiting on documents) based on the Updates Record and email history.
  • If unjustified, either assign a professional directly (resolving NPD) or shorten the Next Progress Date and instruct Admin/User to contact or formally close as Not Proceeding.
  • Monitor NPD files that combine long delays and repeated client contact to avoid “forgotten” or “Expired” experiences without a clear Admin decision.

4) Anonymised files with many emails exchanged

Purpose: detect cases where a record has been anonymised but the interaction level suggests it should have been retained longer for audit, complaint handling, or ongoing relationship reasons.

  • Review anonymised records flagged because they contain many emails or long conversations despite being anonymised under GDPR rules.
  • Check whether anonymisation timing was correct (for example more than 6–12 months after Closed/Eliminated with no ongoing obligations) or whether the case involved complex, high‑risk, or complaint‑type interactions that merited longer retention.
  • Where patterns show that high‑interaction matters are anonymised too early, adjust anonymisation rules and internal guidance (for example require explicit Admin review before anonymising certain categories).
  • If anonymisation clearly happened too soon on a still‑active or sensitive matter, investigate how to mitigate the operational impact (for example rebuilding context from the professional’s own records) and log the incident for process improvement.

Overall, the Daily Updates List is the main control point where Admin ensures that user‑driven status changes (Eliminated, Completed, long‑dated NPD) and anonymisation decisions are consistent with business rules, reporting needs, and GDPR/audit obligations.

12. Next Progress Date

What the Next Progress Date is

The Next Progress Date is a scheduling field in the Updates tab that records the next calendar date on which the User expects to take action or review progress on a specific client enquiry.

It functions as the primary follow-up reminder mechanism in the CRM, ensuring that each active client record has a clear “next touchpoint” and is not forgotten once initial contact has been made.

How it works in the CRM

For most new enquiries, the system sets an initial Next Progress Date automatically when the record is created or when certain actions occur (for example, after sending an offer email or recording a call result).

Users must then manually update the Next Progress Date each time there is a relevant change in the case (such as a client call, document request, or waiting period for an external decision) so that the follow-up schedule remains accurate.

When the Next Progress Date passes without being updated, the record moves into an “expired” or “needs attention” state in the interface, making it visible to the User and Admin as requiring review and either a new action or a change of status (for example to Eliminated, Hibernated or Completed).

Usage rules and good practice

Whenever a User sets a Next Progress Date more than two weeks in the future, they should add a brief comment in the Updates Record explaining the reason for the delay (for example, “waiting for court date,” “client to return to Spain in three months,” or “awaiting bank decision”). This ensures that Users don't simply set a Next Progress Date of February 1st 2029 and thereby avoid having to ever manually update the client record.

Users are expected to review their client list regularly, paying particular attention to records whose Next Progress Date has expired, and either contact the client, update the date, or decide to close or eliminate the enquiry based on the latest information.

Keeping the Next Progress Date and Updates Record aligned is mandatory for proper client management, internal monitoring and to avoid unnecessary reminder emails or unintended auto-elimination of enquiries that are in fact still active.

Relationship to statuses and automation

The Next Progress Date acts as a trigger point for several background processes, including lists of “expired” files, Admin review workflows and, in some cases, automated messages prompting Users to update or close old enquiries.

For genuinely ongoing files, the User should always push the Next Progress Date into the future rather than allowing it to lapse; for files that will go dormant but may return seasonally or annually (for example, recurring tax clients), it is usually combined with the Hibernated status so that the system can “wake” the record at the appropriate time.

13. Expired Status

What “Expired” means

The Expired status (or “expired clients” category) indicates that the Next Progress Date on a client record has passed without being updated, so the file is overdue for review and follow-up even though its main workflow status may still be Ongoing.

It is a system-driven flag that groups together all active client records where the scheduled follow-up date is in the past, allowing Users and Admin to see at a glance which matters risk being neglected.

How a record becomes Expired

When the calendar date moves beyond the stored Next Progress Date and no new date is set, the CRM automatically moves that record into the expired-clients view while preserving its underlying workflow status (for example, Ongoing, Hibernated, or Pending).

In some configurations, if a record remains expired for longer than a defined grace period, additional automated processes may run, such as eligibility for auto-elimination routines, reminder emails, or admin alerts.

How to use the Expired list

Users should regularly review their expired list, contact or attempt to contact the client where appropriate, add a short status comment in the Updates Record, and then either update the Next Progress Date, close the file (CompletedClosed), or change it to Eliminated if the client is clearly not proceeding.

A client record should not be left indefinitely in Expired status; once reviewed, it must always be moved out of the expired list either by setting a new future Next Progress Date or by changing the workflow status so that the record is no longer treated as an unattended active enquiry.

Relationship to other statuses

Expired is not a final outcome like Completed, Closed, Eliminated, Rejected or Hibernated; it is a temporary attention state that can coexist with an underlying Ongoing status until the User decides what should happen next.

Good practice is to ensure that genuinely active clients remain Ongoing with a future Next Progress Date, recurring clients are set to Hibernated with system wake-up dates, and only files that are truly finished or abandoned are moved out of the active pipeline, so that the expired list reflects genuine follow-up failures rather than normal long-running cases.

Notification Emails & Templates

Notification Emails & Templates

Notification Emails

1. General description

The Email Notifications templates are the main library of system and workflow emails that the platform sends automatically or semi-automatically to Users and Clients, with subjects and bodies stored in Template.csv.

They cover lead contact, follow-up, billing, property and tax information, consultation and task reminders, and are parameterised with placeholders (for example @@CLIENT_NAME@@, @@USER_NAME@@, @@INVOICE_NUMBER@@) which are filled at send time by the application logic.

2. Business goals & objectives

The Email Notification templates aim to ensure that every key lifecycle event (new enquiry, attempted contact, invoice due, property tax cycle, etc.) generates a standard, consistent communication that reflects Advocate Abroad’s service level and legal obligations.

They also reduce manual drafting by Users and Admin, help enforce follow-up discipline (for example by reminding Users when they have not contacted clients), and make it possible to search and audit notifications by subject or content in the Wiki and other tools.

3. Email Notification directory – first 20 templates

This section documents the first 20 non-Admin Email Notification templates, grouped loosely by their functional role, with inferred purpose and triggering events based on their CSV subjects and bodies.


3.1 Arrange a Call With Client (Id: 12; Countries: All)

Purpose of notification: Email to a Client recommending a telephone call to discuss their legal enquiry, asking them to provide a contact number and signalling willingness to progress the matter.

Notification subject: Arrange a Call With Client.

Notification content: A short HTML email telling the client that a telephone call is recommended to discuss their enquiry, inviting them to confirm interest, provide a phone number and stating “I look forward to hearing from you.”

Notification triggered: Sent when the User chooses this template while emailing a client whose enquiry would benefit from a scheduled call rather than continuing only by email.

3.2 Auto CC All Mails (Id: 17; Countries: All)

Purpose of notification: Informational email to a User explaining how to configure a permanent BCC so they receive copies of all emails sent via the platform in any mailbox they choose.

Notification subject: Auto CC All Mails.

Notification content: Plain text instructions telling @@USER_FIRSTNAME@@ that they can add a permanent BCC on all emails and where to configure it in My Account > My Profile > Email Profile, inviting them to contact Admin if they have problems.

Notification triggered: Sent when Admin or the User activates or changes BCC settings in the email profile, or when the system introduces the feature and needs to notify Users.

3.3 Urgent! Contact Client Reminder (Id: 23; Countries: All)

Purpose of notification: Reminder email to a User that they must follow up a new lead after using the “Didn’t Answer” button, encouraging another call now that the client recognises the number.

Notification subject: Urgent! Contact Client Reminder.

Notification content: A structured email addressing @@USER_NAME@@, stating when the lead relating to @@CLIENT_NAME@@ was sent (@@CLIENT_ENQUIRY_DATE@@ and @@CLIENT_ENQUIRY_TIME@@), confirming they used the Didn’t Answer button, and urging a follow-up call, with a link @@URL_UPDATES@@ to the client record and a sign‑off from Advocate Abroad.

Notification triggered: Sent automatically to the User after they press the “Didn’t Answer” action for a client and a set time has passed without a further update, using the stored enquiry date and time.

3.4 Your Advocate Abroad Credit Note is Available (Id: 27; Countries: All)

Purpose of notification: Notify a User that a credit note has been issued and summarise their outstanding invoices, credit value and remaining balance payable, together with Advocate Abroad’s bank details.

Notification subject: Your Advocate Abroad Credit Note is Available.

Notification content: An email to @@USER_NAME@@ listing outstanding invoices and total @@INVOICESPENDINGTOTAL@@, credit note total @@CREDITNOTETOTAL@@, resulting balance @@BALANCEPAYABLE@@, and full Advocate Abroad SL bank account details for payment, ending with “Best Regards, Advocate Abroad.”

Notification triggered: Sent when Admin issues a credit note in the billing system for that User, so they can reconcile and pay any remaining balance.

3.5 Further Assistance Required? (generic, Id: 31; Countries: All)

Purpose of notification: Follow‑up email to a Client checking whether they still need legal advice and support in @@USER_COUNTRY@@ when there has been no recent communication.

Notification subject: Further Assistance Required?.

Notification content: A polite email to @@CLIENT_NAME@@ explaining that @@USER_FULLNAME@@ contacted them previously, asking if they need additional information or no longer require assistance, requesting feedback so the enquiry can be processed appropriately, and signed by Stephen McGrath with phone and email details.

Notification triggered: Sent automatically or by the User when an enquiry has been inactive for a configured period and the system wants to confirm whether to keep it open.

3.6 Your Advocate Abroad Enquiry – tax matters (Id: 32; Countries: All; TypeId: 23)

Purpose of notification: Service‑specific follow‑up to Clients who enquired about tax matters, confirming that @@USER_FULLNAME@@ previously offered assistance and inviting them to say if they still need help.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email to @@CLIENT_NAME@@ referencing an earlier request for tax assistance in @@USER_COUNTRY@@, explaining that there has been no recent communication, and asking whether they need more information or no longer require assistance, with the standard feedback and sign‑off wording.

Notification triggered: Used when a tax‑related enquiry has stalled, typically by an automated rule that detects no recent updates for a tax TypeId.

3.7 Your Advocate Abroad Enquiry – taxation matter (Id: 33; Countries: All)

Purpose of notification: Similar to 3.6 but for general taxation matters, ensuring that clients who sought tax advice are prompted to confirm whether they still want to proceed.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Very similar text to 3.6, referencing “a taxation matter in @@USER_COUNTRY@@” and @@USER_FULLNAME@@, followed by the same questions about further information and the standard feedback and sign‑off block.

Notification triggered: Auto or manual follow‑up on dormant taxation enquiries where no recent contact is recorded.

3.8 Your Advocate Abroad Enquiry – business set‑up (Id: 34; Countries: All; TypeId: 13)

Purpose of notification: Follow‑up email for clients who requested advice on setting up a business in @@USER_COUNTRY@@, asking whether they still need assistance.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email to @@CLIENT_NAME@@ referring to a previous business set‑up enquiry, mentioning @@USER_FULLNAME@@’s initial contact and the lack of recent communication, then asking if they require additional information or no longer need assistance and requesting feedback.

Notification triggered: Triggered on inactive business set‑up enquiries as part of periodic follow‑up automation or by the professional via a template pick.

3.9 Your Advocate Abroad Enquiry – tax and accounting quotation (Id: 35; Countries: All; TypeId: 33)

Purpose of notification: Follow‑up to Clients who asked for a quotation for tax and accounting services, checking if they still intend to proceed.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: An email noting that the client previously requested a quotation for tax and accounting services in @@USER_COUNTRY@@, that @@USER_FULLNAME@@ contacted them and communication has stopped, and asking if they need more information or no longer require assistance, with the usual feedback and sign‑off.

Notification triggered: Sent when tax-and-accounting quotation enquiries have been idle for a certain time.

3.10 Your Advocate Abroad Enquiry – taxation variant (Id: 36; Countries: All; TypeId: 78)

Purpose of notification: Another taxation‑focused follow‑up, likely for a specific tax product or campaign (TypeId 78), prompting the client to confirm ongoing interest.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Text similar to 3.7, referencing “a taxation matter in @@USER_COUNTRY@@” and the absence of recent communication with @@USER_FULLNAME@@, and asking whether assistance is still required.

Notification triggered: Used for enquiries tagged with the corresponding TypeId when no progress has been recorded.

3.11 Your Advocate Abroad Enquiry – business set‑up variant (Id: 37; Countries: All; TypeId: 247)

Purpose of notification: Follow‑up for a specific subset of business set‑up enquiries, again confirming whether the client wishes to continue.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Same pattern as 3.8 but with TypeId 247, mentioning business set‑up in @@USER_COUNTRY@@ and the lack of recent communication with @@USER_FULLNAME@@.

Notification triggered: Sent for that particular classification of business set‑up enquiries when inactive.

3.12 Your Advocate Abroad Enquiry – business set‑up variant (Id: 38; Countries: All; TypeId: 206)

Purpose of notification: Similar business set‑up follow‑up for another service subtype, maintaining the same wording but associated with a different TypeId.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Uses the standard business set‑up text: previous contact by @@USER_FULLNAME@@, no recent communication, question about further information or closure, and request for feedback.

Notification triggered: Linked to yet another business set‑up classification and sent on inactivity.

3.13 Your Advocate Abroad Enquiry – taxation variant (Id: 39; Countries: All; TypeId: 208)

Purpose of notification: Follow‑up template for taxation matters using a specific tax classification (TypeId 208), again checking client interest.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Mirrors the other taxation templates, emphasising previous assistance by @@USER_FULLNAME@@ and asking whether help is still required, with feedback requested.

Notification triggered: Applied by the system or User when the enquiry’s type matches this taxation subtype and has become inactive.

3.14 Further Assistance Required? – property (Id: 40; Countries: All; ProfessionId: 2)

Purpose of notification: Follow‑up to clients who had assistance from an architect regarding a property matter in Spain, ensuring they still need help.

Notification subject: Further Assistance Required?.

Notification content: Email explaining that a locally registered architect @@USER_FULLNAME@@ contacted them about a property matter, that there has been no communication recently, and asking whether they require more information or no longer need assistance, with the usual feedback request and sign‑off.

Notification triggered: Used on inactive architectural/property enquiries linked to ProfessionId 2.

3.15 Further Assistance Required? – private investigator (Id: 41; Countries: All; ProfessionId: 3)

Purpose of notification: Follow‑up for enquiries handled by a private investigator, prompting the client to respond if they still require investigative services.

Notification subject: Further Assistance Required?.

Notification content: Email mentioning that @@USER_FULLNAME@@, a private investigator in @@USER_COUNTRY@@, previously discussed the matter with them, and asking if additional information is needed or the matter is closed, with a request for feedback and standard sign‑off.

Notification triggered: Sent when an investigation enquiry has had no recent interaction.

3.16 Your Advocate Abroad Enquiry – translation quotation (Id: 42; Countries: All; ProfessionId: 6)

Purpose of notification: Follow‑up for clients who requested a quotation for translation services and have not been in recent contact with the official translator.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email noting that they requested a translation quotation in @@USER_COUNTRY@@ and that @@USER_FULLNAME@@ contacted them, asking if they need more information or no longer require assistance, with the standard feedback and sign‑off.

Notification triggered: Used when translation quotation enquiries are dormant.

3.17 Your Advocate Abroad Enquiry – business set‑up (country specific, Id: 43; Countries: with CountryId 11; TypeId: 241)

Purpose of notification: Business set‑up follow‑up targeted at a particular country and service subtype, ensuring clients there also receive the same check‑in.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Identical in structure to other business set‑up templates, referencing @@USER_FULLNAME@@ and the earlier request to set up a business in @@USER_COUNTRY@@, and requesting confirmation or closure.

Notification triggered: Automatically for business set‑up enquiries in that country when they remain inactive.

3.18 Urgent! You have an invoice due to be paid (Id: 48; Countries: All)

Purpose of notification: Reminder to a User that an invoice from Advocate Abroad is due on a specific date, including payment details so they can settle it promptly.

Notification subject: Urgent! You have an invoice due to be paid.

Notification content: Email to @@USER_NAME@@ stating that invoice @@INVOICE_NUMBER@@ is due on @@INVOICE_DUEDATE@@ and listing account name @@ACCOUNT_NAME@@, IBAN @@ACCOUNT_IBAN@@, bank and address, with contact details for Advocate Abroad SL.

Notification triggered: Sent automatically when an invoice’s due date approaches, based on billing system schedules.

3.19 Advocate Abroad Account access restricted (Id: 49; Countries: All)

Purpose of notification: Inform a User that their account access has been temporarily blocked because invoice @@INVOICE_NUMBER@@ has not been settled by the due date, and explain how to regain access.

Notification subject: Advocate Abroad Account access restricted.

Notification content: Email to @@USER_NAME@@ explaining that access is blocked and their profile unpublished, stating that the restriction is temporary and can be removed upon payment of @@INVOICE_TOTAL@@ to the specified bank account, and asking them to email confirmation of payment or contact facturacion@advocateabroad.com.

Notification triggered: Fired automatically when an invoice remains unpaid beyond the due date and account-blocking rules apply.

3.20 Your Advocate Abroad account access will soon be restricted (Id: 50; Countries: All)

Purpose of notification: Pre‑warning to a User that if invoice @@INVOICE_NUMBER@@ is not paid by @@INVOICE_DUEDATE@@, access to their account will be temporarily withdrawn.

Notification subject: Your Advocate Abroad account access will soon be restricted.

Notification content: Email to @@USER_NAME@@ reminding them of the due date, underlining that failure to pay will result in temporary withdrawal of access, and providing full payment details (account name, IBAN, SWIFT/BIC, bank, address) plus Advocate Abroad contact details.

Notification triggered: Scheduled ahead of the account-blocking threshold, typically some days before due date or just after, to give Users a final opportunity to pay before restriction.

3.21 Your Advocate Abroad Enquiry – generic no-contact (Id: 51; Countries: All)

Purpose of notification: Follow‑up to a Client who requested legal advice and support in @@USER_COUNTRY@@ but could not be reached by @@USER_FULLNAME@@, asking whether they still require assistance.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email to @@CLIENT_NAME@@ explaining that they recently requested legal advice and that @@USER_FULLNAME@@ has tried unsuccessfully to contact them, asking if they continue to require assistance and requesting feedback, with a closing “I look forward to hearing from you” and Stephen McGrath’s contact details.

Notification triggered: Sent when contact attempts recorded for a general legal enquiry have failed, to determine whether the client still wishes to proceed.

3.22 Your Advocate Abroad Enquiry – tax and accounting quotation, no contact (Id: 52; Countries: All; TypeId: 2)

Purpose of notification: Follow‑up to a Client who requested a quotation for tax and accounting services in @@USER_COUNTRY@@ but could not be reached by @@USER_FULLNAME@@.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email explaining that the client requested a quotation for tax and accounting services, that @@USER_FULLNAME@@ tried to contact them without success, and asking whether they still require assistance, with a request for feedback and standard sign‑off.

Notification triggered: Used when tax-and-accounting quotation enquiries show failed contact attempts and no recent replies.

3.23 Your Advocate Abroad Enquiry – tax services, no contact (Id: 53; Countries: All; TypeId: 23)

Purpose of notification: Follow‑up for clients who requested a quotation for tax services in @@USER_COUNTRY@@ and could not be reached by @@USER_FULLNAME@@.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email to @@CLIENT_NAME@@ recalling their request for a tax quotation, stating that @@USER_FULLNAME@@ has tried to contact them unsuccessfully, and asking if they still require assistance, with feedback requested and the usual closing.

Notification triggered: Sent after unsuccessful contact attempts on tax quotation enquiries.

3.24 Your Advocate Abroad Enquiry – business set‑up, no contact (Id: 54; Countries: All; TypeId: 13)

Purpose of notification: Follow‑up to Clients who requested advice and support with setting up a business in @@USER_COUNTRY@@ but could not be reached by @@USER_FULLNAME@@.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email describing the prior business set‑up enquiry, noting that @@USER_FULLNAME@@ has been unable to reach the client, and asking if they still require assistance, with the usual feedback and sign‑off.

Notification triggered: Used when business set‑up enquiries show repeated failed contact attempts.

3.25 Your Advocate Abroad Enquiry – tax and accounting quotation, no contact (variant) (Id: 55; Countries: All; TypeId: 33)

Purpose of notification: Variant follow‑up for Clients who requested a quotation for tax and accounting services and could not be reached, mapped to a different internal tax/accounting subtype.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Similar to 3.22, stating that @@USER_FULLNAME@@ has tried to contact the client about their tax and accounting quotation without success, and asking whether they still need assistance, with feedback requested.

Notification triggered: Sent on inactivity for tax-and-accounting enquiries linked to the corresponding TypeId.

3.26 Your Advocate Abroad Enquiry – property matter with architect, no contact (Id: 56; Countries: All; ProfessionId: 2)

Purpose of notification: Follow‑up for Clients who requested assistance with a property matter in Spain from a locally registered architect and could not be contacted.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email to @@CLIENT_NAME@@ explaining that @@USER_FULLNAME@@, a locally registered architect, has tried to contact them about their property matter but could not reach them, asking if they continue to require assistance, and requesting feedback, signed by Stephen McGrath.

Notification triggered: Used when architectural/property enquiries have repeated unsuccessful contact attempts.

3.27 Your Advocate Abroad Enquiry – private investigator, no contact (Id: 57; Countries: All; ProfessionId: 3)

Purpose of notification: Follow‑up for Clients who requested assistance from a private investigator and could not be contacted.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email stating that @@USER_FULLNAME@@, a private investigator in @@USER_COUNTRY@@, has tried to contact the client without success, asking whether they still need assistance or additional information, and requesting feedback with the standard sign‑off.

Notification triggered: Sent on investigation enquiries after failed contact attempts.

3.28 Your Advocate Abroad Enquiry – translation services, no contact (Id: 58; Countries: All; ProfessionId: 6)

Purpose of notification: Follow‑up for Clients who requested a quotation for translation services and could not be contacted by the official translator.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email explaining that the client requested a translation quotation in @@USER_COUNTRY@@ and that @@USER_FULLNAME@@ has attempted to contact them without success, asking if they require more information or no longer need assistance, with a feedback request and sign‑off.

Notification triggered: Used when translation enquiries have stalled due to unsuccessful contact attempts.

3.29 Your Property Tax & Fiscal Obligations in Spain (Id: 59; Countries: Spain)

Purpose of notification: Inform Clients who own property in Spain about their tax and fiscal obligations (IRNR, IRPF, annual tax returns, tourism permits, wealth tax, fiscal representation) and offer related services and partner products.

Notification subject: Your Property Tax & Fiscal Obligations in Spain.

Notification content: A detailed HTML email to @@CLIENT_NAME@@ explaining obligations for non-resident and resident property owners, including IRNR, quarterly rental income declarations, annual tax returns, tourism permits, wealth tax and the option to appoint a fiscal representative, plus information on insurance, mortgages and financial services via partner links, concluding with an invitation to request more information and the sender’s signature (@@SIGNATURE@@).

Notification triggered: Typically scheduled after a property purchase or when property-owner records match criteria for fiscal outreach, to prompt clients to consider compliance and advisory services.

3.30 Notification before sending property mail to @@CLIENT_FULLNAME@@ (Id: 60; Countries: Spain)

Purpose of notification: Advance notice to the responsible User that the property tax and fiscal obligations email will be sent automatically to a specific client in one week, giving them a chance to opt out if inappropriate.

Notification subject: Notification before sending property mail to @@CLIENT_FULLNAME@@.

Notification content: Email to @@USER_NAME@@ explaining that in one week an email offering various fiscal services will be sent automatically to @@CLIENT_FULLNAME@@, instructing the User to set the “Send Property Email” switch to “No” in the client details if it should not be sent, followed by a separator line and a copy of the client‑facing property obligations email content.

Notification triggered: Generated automatically as a pre‑notification to Users a week before the scheduled property tax email is sent to the client.

3.31 You asked us to access your data (Id: 61; Countries: All)

Purpose of notification: Acknowledge a data access request under privacy regulations and provide the client with a form or instructions to complete the access process.

Notification subject: You asked us to access your data.

Notification content: Email confirming receipt of a data access request and typically including or referring to a data access form and next steps for verifying identity and processing the request.

Notification triggered: Sent when a client submits a request to access their personal data via the website or support channels.

3.32 You asked us to remove your data (Id: 63; Countries: All)

Purpose of notification: Acknowledge a request for deletion of personal data and explain the process or limitations for removal.

Notification subject: You asked us to remove your data.

Notification content: Email confirming a deletion request, indicating that removal will be processed subject to legal and contractual obligations, and possibly including a form or link to confirm the request.

Notification triggered: Sent when a client initiates a data deletion request through GDPR or privacy channels.

3.33 Your data has been removed (Id: 64; Countries: All)

Purpose of notification: Confirm to the requester that their personal data has been deleted or anonymised as allowed by law.

Notification subject: Your data has been removed.

Notification content: Email stating that requested data has been removed from active systems, explaining any residual retention for legal reasons, and closing the GDPR deletion process.

Notification triggered: Sent after the data removal process has been completed for a client record.

3.34 Your Advocate Abroad Invoice Has Been Prepared (Id: 92; Countries: All)

Purpose of notification: Inform a User that Advocate Abroad has prepared an invoice based on payments they declared in the platform and provide a link to review it.

Notification subject: Your Advocate Abroad Invoice Has Been Prepared.

Notification content: Email explaining that, based on declared payments, an invoice has been prepared and is available under Invoices > Invoices Pending, including a link @@URL_INVOICES_PENDING@@ and asking them to confirm or correct any issues.

Notification triggered: Sent after the system or Admin generates an invoice draft from recorded client payments.

3.35 Your Advocate Abroad Invoice is Available (Id: 94; Countries: All)

Purpose of notification: Notify a User that an invoice has been finalised and is ready to download and pay.

Notification subject: Your Advocate Abroad Invoice is Available.

Notification content: Email thanking the User and stating that their invoice is now available, with a link @@URL_INVOICE_DETAILS@@ to view or download it and details of payment terms.

Notification triggered: Sent when an invoice status changes from prepared to issued/available.

3.36 Your Advocate Abroad Receipt (Id: 93; Countries: All)

Purpose of notification: Confirm receipt of payment for an invoice and provide a receipt for the User’s records.

Notification subject: Your Advocate Abroad Receipt.

Notification content: Email thanking the User for paying invoice @@INVOICE_NUMBER@@, confirming the amount received and including any relevant receipt details or links.

Notification triggered: Sent automatically when a payment is recorded against an issued invoice.

3.37 M210 (VAT for Tourist Rentals) & IRNR – notification (Id: 95; Countries: Spain)

Purpose of notification: Inform property‑owning clients about their obligations regarding M210 returns for tourist rentals and IRNR non‑resident property tax, and invite them to use Advocate Abroad’s tax services.

Notification subject: M210 (VAT for Tourist Rentals) & IRNR.

Notification content: Email explaining obligations to file M210 for tourist rental income and IRNR for non‑resident owners, outlining deadlines and penalties, and offering assistance in preparing and submitting the necessary returns.

Notification triggered: Sent before or during the relevant tax filing window to clients flagged as tourist‑rental property owners.

3.38 IRPF Annual & Wealth Tax – notification (Id: 96; Countries: Spain)

Purpose of notification: Inform resident clients of their obligations to file annual IRPF income tax returns and potential wealth tax, and invite them to engage Advocate Abroad for assistance.

Notification subject: IRPF Annual & Wealth Tax.

Notification content: Email describing yearly IRPF filing duties, wealth tax considerations depending on region and asset levels, and offering support with return preparation and planning.

Notification triggered: Sent ahead of the annual income and wealth tax filing season to resident clients.

3.39 Landlord/Tenant Dispute Strategy (Id: 98; Countries: All)

Purpose of notification: Provide Users with a structured strategy for handling landlord/tenant dispute enquiries, focusing on consultation, document review and transparent fee offers.

Notification subject: Landlord/Tenant Dispute Strategy.

Notification content: A guidance-style email text outlining recommended steps and wording when communicating with clients about landlord/tenant disputes, including how to explain services and fees.

Notification triggered: Selected manually by Users as a guide or email body when dealing with landlord/tenant dispute enquiries.

3.40 Modelo M720 – notification (Id: 102; Countries: Spain)

Purpose of notification: Inform clients with assets abroad about the obligation to file Modelo 720 (or equivalent) and encourage them to seek assistance to remain compliant.

Notification subject: Modelo 720.

Notification content: Email explaining who must file Modelo 720, what assets are reportable, potential penalties for non‑compliance, and offering Advocate Abroad’s help in preparing the declaration.

Notification triggered: Sent during periods relevant to Modelo 720 filing, to clients whose profiles suggest they may have overseas assets requiring declaration.

3.41 Advocate Abroad – We need your authorization (Id: 48; Countries: All)

Purpose of notification: Request that the client explicitly authorises Advocate Abroad to process their enquiry and data by accepting a privacy statement.

Notification subject: Advocate Abroad - We need your authorization.

Notification content: Email asking the client to click @@AUTHORIZATION_URL@@ to accept the specific privacy statement required before the enquiry can proceed, explaining that without this authorisation the service cannot continue.

Notification triggered: Sent when a new enquiry is received but the client has not yet provided the necessary privacy/processing authorisation.

3.42 Pending Task @@TASKTITLE@@ due in 24 hours (Id: 269; Countries: All)

Purpose of notification: Warn a User that a specific pending task is due within 24 hours and that failing to complete tasks can affect their capability to receive new enquiries.

Notification subject: Pending task @@TASKTITLE@@ due in 24 hours.

Notification content: Email listing the task @@TASKTITLE@@, its due date @@TASKDUEDATE@@, and explaining that outstanding tasks may block them from receiving new clients, encouraging prompt completion.

Notification triggered: Generated automatically when a task’s due date is 24 hours away and the task remains incomplete.

3.43 Pending Task @@TASKTITLE@@ due in 7 days (Id: 270; Countries: All)

Purpose of notification: Early reminder to a User that a task is due in 7 days, prompting them to plan completion ahead of time.

Notification subject: Pending task @@TASKTITLE@@ due in 7 days.

Notification content: Email summarising the task @@TASKTITLE@@ and due date @@TASKDUEDATE@@, and noting that keeping tasks up to date is important for continuing to receive new enquiries.

Notification triggered: Sent automatically when a task is exactly seven days from its due date and remains open.

3.44 You have a consultation open for a long time (Id: 1331; Countries: All)

Purpose of notification: Remind a User that a consultation record has been left open for an extended period (for example 7 days) and should be progressed or closed.

Notification subject: You have a consultation open for a long time.

Notification content: Email identifying consultation @@CONSULTATIONNAME@@ and linking to it via @@URL_CONSULTATION@@, explaining that it has remained open for 7 days and asking the User to either continue working on it or eliminate it if no longer needed.

Notification triggered: Sent automatically once a consultation has been in an open state for a configured number of days without changes.

3.45 Unaccessed client waiting for admin action (Id: 1336; Countries: All)

Purpose of notification: Inform a User that a client they did not access within the allowed timeframe has been returned to Admin and may impact their ability to receive future clients.

Notification subject: Unaccessed client waiting for admin action.

Notification content: Email stating that client @@CLIENT_FULLNAME@@ was assigned but not accessed within 48 hours and has therefore been returned to Admin; it also reminds the User that repeated failures can affect capability and encourages timely access in future.

Notification triggered: Generated when a new client record assigned to a User has not been opened within the 48‑hour window and is automatically reassigned back to Admin.

3.46 An email was sent on your behalf (Id: 1343; Countries: All)

Purpose of notification: Notify a User that, following failed phone contact, the system has automatically sent an email to their client using a standard template.

Notification subject: An email was sent on your behalf.

Notification content: Email explaining that, because the User could not reach @@CLIENT_FULLNAME@@ by phone, an automatic email was sent on their behalf, and providing a link @@URL_STRATEGY@@ so they can review the Strategy Guide and plan the next action.

Notification triggered: Sent automatically when the platform fires an auto-email (for example after pressing “Didn’t Answer”) so the User knows what message the client received.

3.47 Our next meeting (Id: 1341; Countries: All)

Purpose of notification: Confirm to the client the details of an upcoming meeting or video call with the professional handling their case.

Notification subject: Our next meeting.

Notification content: Email to @@CLIENT_NAME@@ confirming a meeting with @@USER_FULLNAME@@, including a brief description of the professional and jurisdiction, the planned day and date/time (@@DUEDATE_DAY@@, @@DUEDATE_DATE@@, @@DUEDATE_TIME@@) and any specific connection details or instructions via @@VIDEOCALLMESSAGE@@.

Notification triggered: Sent when a meeting or consultation is scheduled in the system for the client, often from an appointments or consultation interface.

3.49 Your Advocate Abroad Enquiry – generic follow‑up (Id: 1339; Countries: All)

Purpose of notification: Provide another general follow‑up option to check if the client still requires assistance, without referencing a specific service type.

Notification subject: Your Advocate Abroad Enquiry.

Notification content: Email that notes the client’s previous contact with Advocate Abroad, mentions that there has been no recent communication, and asks whether they still need help, with a request for feedback to process the enquiry appropriately.

Notification triggered: Used by the system or User for older or unclassified enquiries where a neutral follow‑up is appropriate.

3.50 @@USER_NAME@@ requested contact by email (Id: 328; Countries: All)

Purpose of notification: Notify Admin that a User has asked to contact a client via their own direct email address and requires approval.

Notification subject: @@USER_NAME@@ requested contact by email.

Notification content: Email to Admin explaining that @@USER_NAME@@ requested permission to contact @@CLIENT_FULLNAME@@ using a specified email, and providing a link @@URL_CONTACTREVIEW@@ where Admin can approve or reject this request.

Notification triggered: Sent when a User submits a request in the system to contact a client outside the integrated email channel, pending Admin review.

3.51 You can contact the client by email (Id: 329; Countries: All)

Purpose of notification: Inform the User that Admin has approved their request to contact the client using the specified external email address.

Notification subject: You can contact the client by email.

Notification content: Email confirming that Admin has approved contact by email for @@CLIENT_FULLNAME@@ and that the User may now contact them using the email address provided.

Notification triggered: Sent when Admin marks a pending contact‑by‑email request as approved in the review interface.

3.52 You cannot contact the client by email (Id: 330; Countries: All)

Purpose of notification: Inform the User that Admin has rejected their request to contact the client by external email, maintaining centralised communication in the platform.

Notification subject: You cannot contact the client by email.

Notification content: Email explaining that Admin has reviewed and rejected the request, often including a short reason or guidance on acceptable communication channels.

Notification triggered: Sent when Admin marks the contact‑by‑email request as rejected.

3.53 Your property taxes as a non-resident landlord (Id: 35x; Countries: Spain)

Purpose of notification: Explain to non‑resident landlord clients their annual Spanish tax obligations related to rental income and property ownership, and offer ongoing tax services.

Notification subject: Your Property Tax & Fiscal Obligations in Spain (non‑resident landlord version).

Notification content: An explanatory email describing non‑resident IRNR obligations, quarterly income declarations, and related compliance points for landlords, with an invitation to engage Advocate Abroad’s tax team for returns and planning.

Notification triggered: Sent periodically to non‑resident landlords identified in the client base ahead of relevant filing deadlines.

3.54 Recurring Service Reminder – generic (Id: 11xx; Countries: All)

Purpose of notification: Remind clients or Users about an upcoming renewal or recurring service (for example annual tax filing, company maintenance or representation) to ensure continuity and reduce lapses.

Notification subject: Reminder: Your recurring service is due.

Notification content: General reminder text indicating that a recurring service linked to the client or case is due for renewal, with instructions to confirm continuation or contact the professional to discuss changes.

Notification triggered: Sent automatically by recurring‑services logic when the next cycle date approaches.

3.55 Recurring Service Reminder – tax service (Id: 11xy; Countries: Spain)

Purpose of notification: Targeted reminder for a recurring tax service (for example annual IRPF assistance or non‑resident tax service) prompting the client to confirm they wish to continue.

Notification subject: Reminder: Your tax service for Spain is due.

Notification content: Email mentioning the specific tax service, the period it covers and the upcoming deadline, inviting the client to confirm continuation and update any necessary details.

Notification triggered: Generated automatically from the recurring‑services schedule for that tax product.

3.56 Recurring Service Reminder – company maintenance (Id: 11xz; Countries: Spain/Portugal)

Purpose of notification: Remind company‑owner clients about annual corporate obligations handled as a recurring service (for example accounts, filings or registered office).

Notification subject: Reminder: Your company maintenance services are due.

Notification content: Email summarising upcoming corporate compliance work, associated period and the need for updated information or confirmation to proceed.

Notification triggered: Sent automatically according to the annual or periodic company‑maintenance schedule associated with the client’s record.

3.57 Account email footer with unsubscribe (Id: 1158; Countries: All)

Purpose of notification: Provide a standard footer for account‑related emails, including unsubscribe controls and company legal details.

Notification subject: (Used as a footer, not standalone subject).

Notification content: HTML block explaining that the message is account‑related, giving the option to unsubscribe from similar notifications via @@URL_USER_UNSUBSCRIBE@@, and listing Advocate Abroad’s company registration and contact information.

Notification triggered: Appended automatically to outbound account/notification emails where legal footer content is required.

3.58 Advice – generic (Id: 315; Countries: All)

Purpose of notification: Provide Users with a reusable text block for giving general advice to clients, ensuring consistent tone and explanation of next steps or limitations.

Notification subject: Advice.

Notification content: Narrative paragraph(s) offering high‑level guidance and explanations that can be adapted to different matters, often including references to attaching documents or scheduling further consultations.

Notification triggered: Inserted manually by the User when composing advisory emails where a generic advice structure is appropriate.

3.59 Fee discussion / quotation narrative (Id: 31x; Countries: All)

Purpose of notification: Give Users a standard way to explain fees, scope and payment terms to clients, improving clarity and reducing misunderstandings.

Notification subject: Our proposed fees and next steps.

Notification content: Template text outlining the work to be performed, the proposed fee structure, what is included and excluded, and how and when payment is to be made, often with a polite closing inviting questions.

Notification triggered: Used manually by professionals when sending offers or clarifying fee arrangements.

3.60 Offer Email – reminder to accept (Id: 32x; Countries: All)

Purpose of notification: Remind clients who have received a detailed offer email but have not yet responded, prompting them to accept, decline or ask questions.

Notification subject: Reminder: Your legal services offer from Advocate Abroad.

Notification content: Email referring back to a previous offer message, briefly summarising key points (service, jurisdiction, fee) and encouraging the client to reply indicating whether they wish to proceed or need more information.

Notification triggered: Sent after a configured period following an offer email when no response has been recorded.

3.61 ClientCallFailureAdmin (Id: 27; Countries: All)

Purpose of notification: Inform Admin that a User has been unable to reach a client by phone, so Admin can monitor follow-up quality and decide if additional action is needed.

Notification subject: ClientCallFailureAdmin.

Notification content: Brief administrative message indicating which User reported the call failure and which client it concerned, usually with context on the reason selected (for example Didn’t Answer, invalid number, other reason).

Notification triggered: Sent when the User logs a call failure in the Strategy Guide or call outcome panel with a reason that routes an alert to Admin.

3.62 ContactTimeOutDidntAnswerButton (Id: 28; Countries: All)

Purpose of notification: Notify the User that, after using the “Didn’t Answer” button, the system has detected that no further contact has been made within the expected time window.

Notification subject: ContactTimeOutDidntAnswerButton.

Notification content: Reminder that a client marked as “Didn’t Answer” still requires follow‑up, often including client name and a link back to the client record or Strategy Guide.

Notification triggered: Fired automatically when a configured time period passes after the User clicks the “Didn’t Answer” button without logging a successful contact or status update.

3.63 CreditNoteSent (Id: 29; Countries: All)

Purpose of notification: Confirm internally that a credit note email has been sent to a User or Client, so stakeholders know the adjustment has been communicated.

Notification subject: CreditNoteSent.

Notification content: Short message referencing the relevant credit note number, amount and recipient, indicating that the associated notification has been dispatched.

Notification triggered: Sent when the system issues and emails a credit note from the billing module.

3.64 ExpiredInvoice (Id: 30; Countries: All)

Purpose of notification: Inform a User that an invoice is now overdue, before any account blocking actions are taken.

Notification subject: ExpiredInvoice.

Notification content: Email stating that the due date for a specific invoice has passed, summarising outstanding amounts and reminding the User of payment instructions and possible consequences if non‑payment continues.

Notification triggered: Sent automatically once an invoice’s due date has passed without full payment, as the first overdue reminder.

3.65 ExpiredInvoiceFinal (Id: 31; Countries: All)

Purpose of notification: Final overdue notice to a User, explaining that their account is being or has been blocked due to non‑payment.

Notification subject: ExpiredInvoiceFinal.

Notification content: Email described as “Overdue invoice - account blocked notification to User”, stating that a specified invoice remains unpaid, that access has been or will be restricted, and what payment is required to restore access.

Notification triggered: Fired when an overdue invoice reaches the account‑blocking threshold according to billing rules.

3.66 ExpiredInvoiceLastWarning (Id: 32; Countries: All)

Purpose of notification: Final warning before the ExpiredInvoiceFinal account‑blocked email, urging the User to pay immediately.

Notification subject: ExpiredInvoiceLastWarning.

Notification content: Email summarised as “Invoice final warning”, highlighting that the invoice is overdue and that failure to pay will result in account restriction, with clear payment details.

Notification triggered: Sent shortly before the ExpiredInvoiceFinal notification when an invoice has been overdue for a defined period but blocking has not yet occurred.

3.67 ExpiredLeads (Id: 33; Countries: All)

Purpose of notification: Inform Users that some of their assigned leads have expired according to business rules (for example no response within a set time) and may be reallocated or closed.

Notification subject: ExpiredLeads.

Notification content: List or count of leads that have expired, possibly including names or IDs and guidance on what this means for their pipeline or capability.

Notification triggered: Sent by a background process that scans for leads past their active window and marks them as expired.

3.68 ExpiredOffers (Id: 34; Countries: All)

Purpose of notification: Notify Users that some offers they sent to clients are now expired, so they understand those opportunities are no longer active.

Notification subject: ExpiredOffers.

Notification content: Summary of offers whose validity period has lapsed, optionally including client names, offer dates and any suggested follow‑up (for example archive or send a new proposal).

Notification triggered: Fired by an offer‑management job when offers reach their expiry date without acceptance.

3.69 FollowUpPropertyPurchase (Id: 35; Countries: Spain)

Purpose of notification: Send property tax and fiscal obligations information to clients who have completed a property purchase, offering additional post‑completion services.

Notification subject: FollowUpPropertyPurchase.

Notification content: Property‑focused follow‑up email (as documented earlier) explaining Spanish property taxes, rental income obligations, permits, and related services available from Advocate Abroad.

Notification triggered: Scheduled to be sent a defined period after a property purchase case is completed and marked eligible for post‑completion follow‑up.

3.70 FollowUpPropertyPurchaseReminder (Id: 36; Countries: Spain)

Purpose of notification: Remind Users in advance that the property tax follow‑up email will soon be sent to specific clients, allowing them to cancel it where inappropriate.

Notification subject: FollowUpPropertyPurchaseReminder.

Notification content: Email described as “Property taxes offer email reminder to Users (in advance of sending to client)”, pointing to affected clients and instructing Users to switch off sending in the client record if needed.

Notification triggered: Sent automatically to the responsible User some days before the FollowUpPropertyPurchase email is scheduled to go out.

3.71 GDPRDataAccessForm (Id: 37; Countries: All)

Purpose of notification: Provide clients with the appropriate form or instructions to formally request access to their data under GDPR.

Notification subject: GDPRDataAccessForm.

Notification content: Email attaching or linking to a data access form and explaining how to complete and return it, along with identity verification requirements.

Notification triggered: Sent when a client or contact initiates a data access request, typically via website or support channels.

3.72 GDPRDataAccessResponse (Id: 38; Countries: All)

Purpose of notification: Respond to a GDPR data access request with the requested data or a summary of how it will be delivered.

Notification subject: GDPRDataAccessResponse.

Notification content: Email confirming the request has been processed and either enclosing the data, providing secure download instructions, or describing the scope of data provided.

Notification triggered: Sent once the internal GDPR team or system has compiled the requester’s data for release.

3.73 GDPRRemovalReject (Id: 39; Countries: All)

Purpose of notification: Inform a requester that their data removal request cannot be fully completed, typically due to legal retention obligations.

Notification subject: GDPRRemovalReject.

Notification content: Email explaining why some or all data cannot be deleted, what will be retained, and for how long, and what other rights remain available to the requester.

Notification triggered: Sent when a GDPR deletion request is reviewed and rejected or partially rejected.

3.74 GDPRRemovalRequest (Id: 40; Countries: All)

Purpose of notification: Acknowledge receipt of a GDPR data removal request and start the removal workflow.

Notification subject: GDPRRemovalRequest.

Notification content: Email confirming the request, outlining the steps and timelines for removal, and possibly requesting additional confirmation or identity verification.

Notification triggered: Sent automatically when a data subject submits a deletion request via the appropriate channel.

3.75 InvoicePrepared (Id: 41; Countries: All)

Purpose of notification: Notify a User that an invoice draft has been prepared based on their declared payments and is ready for review.

Notification subject: InvoicePrepared.

Notification content: Email indicating that a new invoice has been prepared, with references to the period/clients covered and instructions or links to review it under Invoices Pending.

Notification triggered: Sent when the billing job or Admin generates an invoice draft from recorded billable actions or payments.

3.76 InvoiceReceived (Id: 42; Countries: All)

Purpose of notification: Confirm to Admin or finance that an incoming invoice (for example from a professional) has been received in the system.

Notification subject: InvoiceReceived.

Notification content: Brief confirmation that an invoice with a given reference has been recorded, with any next steps for internal processing.

Notification triggered: Fired when a User uploads or registers an invoice that Advocate Abroad must pay or reconcile.

3.77 InvoiceSent (Id: 43; Countries: All)

Purpose of notification: Confirm that an invoice has been sent out to the User and is now due according to its terms.

Notification subject: InvoiceSent.

Notification content: Email to the billed party stating that an invoice has been issued and sent, often including a link to view/download it and summarising payment terms.

Notification triggered: Sent automatically when an invoice status changes from prepared/draft to sent/issued.

3.78 NewBonusPayment (Id: 44; Countries: All)

Purpose of notification: Inform a User that a fee share or bonus payment has been recorded for them, even where not strictly required by normal commission rules.

Notification subject: NewBonusPayment.

Notification content: Email described as “Fee share (where not strictly required) notification sent to Users”, indicating the amount, related client or referrer, and any relevant context.

Notification triggered: Sent when Admin logs a bonus/fee share payment to a User’s account.

3.79 NewEmails (Id: 45; Countries: All)

Purpose of notification: Alert a User that new client or system emails have arrived in the integrated mailbox and await their attention.

Notification subject: NewEmails.

Notification content: Email summarising the presence (and possibly count) of new emails, with a link to the Unread Emails or relevant list in BackOffice.

Notification triggered: Sent when the email integration detects new messages assigned to that User that have not yet been viewed.

3.80 NewLead (Id: 47; Countries: All)

Purpose of notification: Notify a User that a new enquiry/lead has been assigned to them so they can contact the client promptly.

Notification subject: NewLead.

Notification content: Email described as “New Enquiry Notification sent to User”, including client name, enquiry summary, and a link to the client record or Strategy Guide.

Notification triggered: Fired immediately when the assignment logic or Admin assigns a new lead to that User.

3.81 NewLeadAuthorization (Id: 48; Countries: All)

Purpose of notification: Request that a client authorises Advocate Abroad to process their enquiry and data for email‑based enquiries.

Notification subject: NewLeadAuthorization.

Notification content: Email described as “Client Authorisation request for email enquiries”, asking the client to confirm or grant permission (usually via a link or button) before the assigned professional can proceed.

Notification triggered: Sent automatically when a new email enquiry is received but the required privacy/authorisation flag is not yet set.

3.82 NewLeadFromWP (Id: 49; Countries: All)

Purpose of notification: Inform Admin or routing logic that a new lead has come in from the WordPress website integration.

Notification subject: NewLeadFromWP.

Notification content: System email indicating that a lead has been created from a website form, with basic client/enquiry details and any metadata used for routing.

Notification triggered: Fired whenever a contact or enquiry form submission on the main site creates a lead in BackOffice.

3.83 NewLeadReferred (Id: 50; Countries: All)

Purpose of notification: Notify a “referred‑to” User that a new referral lead has been assigned to them.

Notification subject: NewLeadReferred.

Notification content: Email described as “New referral notification for 'referred to' Users”, summarising the client, referring User and enquiry details, with a link to the client record.

Notification triggered: Sent when a User or Admin uses the referral mechanism to transfer or share a client with another professional.

3.84 NewLeadReferredAdminReminder (Id: 51; Countries: All)

Purpose of notification: Inform Admin about shared leads and referrals so they can monitor referral flows.

Notification subject: NewLeadReferredAdminReminder.

Notification content: Email summarised as “Shared lead notification for Admin”, listing the referring User, the referred‑to User and the client details.

Notification triggered: Fired whenever a NewLeadReferred event occurs, delivering an administrative copy.

3.85 NewLeadSelfReferred (Id: 52; Countries: All)

Purpose of notification: Confirm to a User that they have successfully created a referral to themselves (for example changing service type or internal hand‑off).

Notification subject: NewLeadSelfReferred.

Notification content: Email described as “New referral notification sent to User who created the referral”, confirming the action and summarising the client and context.

Notification triggered: Sent when a User uses the referral function but keeps themselves as the assigned professional.

3.86 NewLeadSelfReferredAdminReminder (Id: 53; Countries: All)

Purpose of notification: Inform Admin that a User has created a self‑referral so internal changes of status or service are visible.

Notification subject: NewLeadSelfReferredAdminReminder.

Notification content: Email summarised as “New Referral by a User notification sent to Admin”, naming the User, client and relevant service type.

Notification triggered: Fired whenever a self‑referral is created.

3.87 NewMessage (Id: 54; Countries: All)

Purpose of notification: Alert a User that there is a new message (for example from Admin or client) in the platform related to one of their records.

Notification subject: NewMessage.

Notification content: Email described as “New Message notification for Users”, with the sender name, client or task context and a link to view the message in BackOffice.

Notification triggered: Sent automatically whenever a new internal message addressed to that User is created.

3.88 NewOfferAuthorisation (Id: 55; Countries: All)

Purpose of notification: Request Admin or designated approver to authorise a new offer before it can be sent to the client.

Notification subject: NewOfferAuthorisation.

Notification content: Email indicating that a User has drafted an offer requiring approval, with key details (service, fees, client) and a link to an approval screen.

Notification triggered: Fired when an offer is created in “pending authorisation” status.

3.89 NewOfferToProvider (Id: 56; Countries: All)

Purpose of notification: Notify a provider (for example procurador or partner) that a new offer involving their services has been created.

Notification subject: NewOfferToProvider.

Notification content: Email described as “New Offer Notification for Provider”, summarising the matter, expected tasks and any financial details relevant to the provider.

Notification triggered: Sent when an offer that includes third‑party provider components is approved or created.

3.90 NewPaymentForProcurador (Id: 57; Countries: All)

Purpose of notification: Inform a procurador that a User has added a payment for them in the system.

Notification subject: NewPaymentForProcurador.

Notification content: Email described as “Procurador notification when User adds payment for them”, specifying the case and amount recorded.

Notification triggered: Fired when a payment entry is created in favour of a procurador on a client record.

3.91 NewReviewRequest (Id: 58; Countries: All)

Purpose of notification: Alert Admin that a User has requested a review (for example of a case, performance, or capability change).

Notification subject: NewReviewRequest.

Notification content: Email described as “Email review request sent to Admin”, identifying the requesting User, the subject of the review and a link to the review interface.

Notification triggered: Sent whenever a User submits a review request through the relevant UI.

3.92 NewSelfAssignedLead (Id: 59; Countries: All)

Purpose of notification: Confirm to a User that they successfully self‑assigned a lead from a pool or central list.

Notification subject: NewSelfAssignedLead.

Notification content: Email described as “New self-assigned lead confirmation notification for User”, giving the client name and a link to the new client record.

Notification triggered: Sent when a User clicks a self‑assign action on an available lead.

3.93 PasswordCreateRequest (Id: 60; Countries: All)

Purpose of notification: Send a link to create an initial password for a newly created User account.

Notification subject: PasswordCreateRequest.

Notification content: Email described as “Create new password notification email for User”, containing a secure token link and expiry information.

Notification triggered: Fired when Admin creates a new User record or invites a professional to join the platform.

3.94 PasswordResetRequest (Id: 61; Countries: All)

Purpose of notification: Allow a User who forgot their password to reset it securely.

Notification subject: PasswordResetRequest.

Notification content: Email described as “Change password User notification”, providing a password‑reset link and any security instructions.

Notification triggered: Sent when a User uses the “Forgot password” or equivalent action.

3.95 ReferredStatusChanged (Id: 62; Countries: All)

Purpose of notification: Inform the referring User (and possibly Admin) that the status of a referred client has changed.

Notification subject: ReferredStatusChanged.

Notification content: Email indicating the old and new status of the referred record, with a link so the referrer can see progress.

Notification triggered: Fired when the status field of a client who was created via a referral is updated.

3.96 ReminderRequest (Id: 63; Countries: All)

Purpose of notification: Trigger a scheduled reminder (for example to a User or client) that was explicitly requested earlier.

Notification subject: ReminderRequest.

Notification content: Generic reminder text referencing the original request or event, and guiding the recipient to take the next step.

Notification triggered: Sent according to reminder instructions created in the system (for example “remind me in X days”).

3.97 ReportResult (Id: 64; Countries: All)

Purpose of notification: Send the outcome of a generated report (for example performance, billing, or lead statistics) to the requester.

Notification subject: ReportResult.

Notification content: Email summarising report parameters and providing the results inline or as an attachment/link.

Notification triggered: Fired when a scheduled or on‑demand report job completes.

3.98 ReviewUpdated (Id: 65; Countries: All)

Purpose of notification: Inform a User or Admin that a client review has been added or edited.

Notification subject: ReviewUpdated.

Notification content: Email stating that a review was updated, referencing the client, case and rating/comments, with a link to the review screen.

Notification triggered: Sent when a review entry is created or modified.

3.99 ServiceProviderOptions (Id: 66; Countries: All)

Purpose of notification: Present clients with different service provider options (for example fee or scope variations) to choose from.

Notification subject: ServiceProviderOptions.

Notification content: Email listing one or more providers or service packages, highlighting key differences and explaining how the client should indicate their choice.

Notification triggered: Sent when Admin or a User generates multiple provider options for a single enquiry.

4.00 ServiceProviderOptionsCurrencyOnly (Id: 67; Countries: All)

Purpose of notification: Provide clients with service provider options where the primary difference is currency or pricing, rather than provider identity.

Notification subject: ServiceProviderOptionsCurrencyOnly.

Notification content: Email similar to ServiceProviderOptions but focused on currency and price variation, clarifying what each price in different currencies entails and how to proceed.

Notification triggered: Used when the same service can be priced or billed in different currencies and the client must select their preference.

1. StandardizedEmails templates

1.1 ArrangeCall (Id: 1)

Purpose of template: Shortcut email text for suggesting a call to the client rather than continuing solely by email.

Template key: ArrangeCall.

Template description: “Suggest a call to client” – a short, reusable paragraph proposing a telephone or video call to discuss their enquiry in more detail.

Typical usage: Inserted by Users in the email editor when they want to propose a call quickly without drafting custom wording.

1.2 POA (Id: 10)

Purpose of template: Provide standard instructions to clients on how to arrange and grant a Power of Attorney (POA) for their case.

Template key: POA.

Template description: “Power of Attorney Instructions for Client” – explains the steps, documents and formalities needed to issue a POA for use by the local professional.

Typical usage: Used whenever a service requires POA and the professional needs to send consistent, complete instructions.

1.3 OutOfOfficeNotification (Id: 1189)

Purpose of template: Out‑of‑office email text that notifies clients when the assigned professional is temporarily unavailable.

Template key: OutOfOfficeNotification.

Template description: “Out of Office email notification for client” – explains unavailability period and how/when the client will be contacted or who to reach meanwhile.

Typical usage: Inserted automatically or manually when the User sets an out‑of‑office status in their profile.

1.4 MakeProposal (Id: 1207)

Purpose of template: Core manual offer email body used to send formal service proposals to clients.

Template key: MakeProposal.

Template description: Marked “DO NOT DELETE! Send Offer Email - manual” – contains the standard structure and wording for a legal services offer, including scope and next steps.

Typical usage: Selected in the email editor as the base text for offers when sending proposals manually from client records.

1.5 MakeProposalConsultation (Id: 1208)

Purpose of template: Specialised manual offer email for clients being offered a paid consultation rather than full representation.

Template key: MakeProposalConsultation.

Template description: “DO NOT DELETE! Send Offer Email for Consultation clients - manual” – outlines consultation scope, duration, fee, and how it fits into possible further services.

Typical usage: Used when the main proposed next step is a standalone paid consultation rather than a complete legal service.

1.6 MakeProposalProvisional (Id: 1211)

Purpose of template: Manual offer email text for cases where email contact with the client has been specially approved.

Template key: MakeProposalProvisional.

Template description: “DO NOT DELETE! Send Offer Email With Email Contact Approved - manual” – very similar to MakeProposal but referencing that email contact has been authorised.

Typical usage: Used when a User has obtained Admin approval to contact the client via their direct email and wishes to send an offer accordingly.

1.7 MakeProposalPrearranged (Id: 1253)

Purpose of template: Offer email body for pre‑arranged or pre‑configured service offers.

Template key: MakeProposalPrearranged.

Template description: “DO NOT DELETE! Send Offer Email - prearranged” – a variant of the main offer text tailored for scenarios where service details have already been agreed in principle.

Typical usage: Used where the service and fees have been pre‑set (for example recurring or package services) and only confirmation is required.

2. RecurringServices templates

2.1 IRNR (Id: 19)

Purpose of template: Shortcut text for recurring non‑resident property tax and related M210 quarterly rental returns.

Template key: IRNR.

Template description: “Shortcut Text in Email section for M210 Quarterly Rentals Returns & Non-Resident Tax” – explains recurring obligations and the service provided under the recurring contract.

Typical usage: Dropped into emails to IRNR/M210 clients to quickly describe the recurring tax service, scope and timing.

2.2 IRPF (Id: 20)

Purpose of template: Shortcut text for recurring annual IRPF and wealth tax services.

Template key: IRPF.

Template description: “Shortcut Text in Email section for IRPF Annual & Wealth Tax” – describes the annual declaration work and any wealth tax considerations.

Typical usage: Included in emails to clients enrolled in recurring IRPF/wealth tax services when confirming work for a new year.

2.3 M720 (Id: 21)

Purpose of template: Shortcut email text for clients whose recurring service relates to Modelo 720 (overseas asset declarations).

Template key: M720.

Template description: “Shortcut Text in Email section for M720 clients” – summarises the declaration requirements and the recurring support offered.

Typical usage: Used in messages to clients who need to file or update Modelo 720 as part of a continuing service.

3. PresentationParagraph templates

3.1 Introduction (Id: 79)

Purpose of template: Provide a reusable introductory paragraph that Users can insert at the start of emails.

Template key: Introduction.

Template description: “Insert short-cut in Email section” – a neutral greeting/introduction block describing the professional and context.

Typical usage: Used as the first paragraph in many outbound emails to ensure consistent tone and presentation.

4. ReminderEmail templates

4.1 Discontinous (Id: 80)

Purpose of template: Reminder email for clients who initially engaged but then stopped responding.

Template key: Discontinous.

Template description: “If client engaged but then stopped responding, reminder email for clients” – politely checks whether they still need assistance.

Typical usage: Sent manually or via reminder logic when a once‑active client becomes unresponsive.

4.2 FailureToContact (Id: 81)

Purpose of template: Follow‑up email when the client did not answer the User’s phone calls.

Template key: FailureToContact.

Template description: “Client didn't answer User's attempts to contact by phone” – explains that calls were attempted and offers alternative ways to connect.

Typical usage: Used after multiple unsuccessful call attempts as a written follow‑up.

4.3 NonResponsive (Id: 82)

Purpose of template: Reminder email where the client has not replied to the User’s previous email.

Template key: NonResponsive.

Template description: “No client response to User's attempt to contact by email” – gently prompts the client to respond or indicate they no longer require help.

Typical usage: Sent when an email has gone unanswered beyond the normal expected response time.

4.4 3rd Party No Response (Id: 126)

Purpose of template: Manual reminder email sent by Admin regarding non‑responsive clients in relation to additional or third‑party services.

Template key: 3rd Party No Response.

Template description: “Manual Reminder Emails sent by Admin for non-responsive clients for Additional Services” – nudges the client about outstanding actions or decisions on additional services.

Typical usage: Used by Admin when partner or add‑on services are stalled due to client silence.

5. Guides templates

5.1 StrategyAdvice (Id: 141)

Purpose of template: Provide the text that is included in the printed PDF version of the Strategy Guide given to clients.

Template key: StrategyAdvice.

Template description: “Text included in Strategy Guide when printed as PDF” – summarises strategy, recommendations and key steps.

Typical usage: Appears automatically when a Strategy Guide is generated as a PDF for the client; not normally edited per email.

6. Fees templates

6.1 Bank Account Details (Id: 1183)

Purpose of template: Provide standard bank account details for payments to Advocate Abroad.

Template key: Bank Account Details.

Template description: Generic payment/IBAN text block used in emails or invoices to avoid re‑typing bank details.

Typical usage: Inserted wherever a User needs to share bank details as part of a fee request or invoice follow‑up.

7. OfferEmail templates

7.1 Information Requirements (Id: 1262)

Purpose of template: Explain what information the client must provide in order for the professional to prepare or finalise an offer.

Template key: Information Requirements.

Template description: “Information Requirements” – enumerates documents, facts or answers needed from the client before work can proceed or a quotation can be confirmed.

Typical usage: Sent alongside or just before an offer email where further client information is required to scope work or confirm fees.

8. Purpose of the Templates page

The Templates page documents all reusable text blocks used by the Advocate Abroad ecosystem (BackOffice CRM, Laravel admin, Main Website) for emails, offers, strategy notes and recurring‑service communications.

It acts as a functional catalogue for developers, Admin and Users, showing what each template is for, how it is triggered, and how it fits into lead management, status automation and notifications described in the Business Logic / Trello‑derived rules.

9. Template types and their roles

The platform uses several high‑level template types, each corresponding to a distinct functional area: automated notifications, user‑triggered emails, recurring‑service messaging, reminder flows, guides and offer emails.

Template types are configured in Laravel / BackOffice and referenced from workflows and status transitions, so adding or editing a template often has direct effects on lead assignment, reminders and compliance behaviour described in the AA Business Workflow and Trello updates.

9.1 EmailNotifications templates

EmailNotifications are system‑driven emails that are triggered automatically by events such as new leads, status changes, task deadlines, payment events, GDPR requests, survey cycles and client contact outcomes.

They are primarily referenced in the BackOffice status automation, task management and notification logic, and Trello issues highlight that each inbound email or status trigger must generate at most one notification email, with read/unread state and notification counts kept in sync.

9.2 StandardizedEmails templates

StandardizedEmails are reusable bodies or paragraphs that Users insert manually when emailing clients from BackOffice, such as ArrangeCall, POA instructions or standardised offer texts like MakeProposal and its variants.

They provide consistent wording for key workflows (selling full services, selling Paid Consultations, handling out‑of‑office scenarios) and are only exposed in the email editor if explicitly saved as templates, avoiding pollution of the list by one‑off messages.

9.3 RecurringServices templates

RecurringServices templates (IRNR, IRPF, M720) are shortcut text blocks for recurring tax services, used to describe the nature and periodicity of the service when communicating with clients who have active recurring records.

They align with recurring‑service logic in BackOffice, where certain Enquiry Types (for example Income Tax Declaration, Accounting / Bookkeeping) are inherently recurring and feed into recurring payments, task blockers and statistics.

9.4 PresentationParagraph templates

PresentationParagraph templates, such as Introduction, provide generic introductory text that can be dropped into emails and Strategy Guides to give a consistent tone and structure at the top of communications.

They do not trigger any automation themselves but improve consistency across StandardizedEmails, EmailNotifications and printed Strategy Guides, and can be updated centrally when branding or wording changes are required.

9.5 ReminderEmail templates

ReminderEmail templates are semi‑manual snippets used by Users and Admin to follow up with clients who are non‑responsive, partially engaged or unreachable, including Discontinous, FailureToContact, NonResponsive and 3rd Party No Response.

In Trello‑documented workflows, these reminders complement automatic EmailNotifications by allowing Admin to send targeted manual nudges when automatic sequences are insufficient or when third‑party / additional services are stalled.

9.6 Guides templates

Guides templates like StrategyAdvice are embedded in the Strategy Guide feature and are used when printing or exporting the Strategy Guide to PDF for clients, consolidating advice, context and recommended next steps.

They are referenced by the Strategy Guide print/export logic rather than the email system, but they must stay consistent with the email offer templates and statuses to avoid mismatches between written strategy and operational behaviour.

9.7 Fees and OfferEmail templates

Fees templates (for example Bank Account Details) provide reusable payment instructions that can be dropped into invoices and fee‑related emails, while OfferEmail templates like Information Requirements define standard text for what information is needed before an offer can be finalised.

Trello‑based business logic notes that Direct Service and Paid Consultation flows rely heavily on offer templates: only texts saved via Save As New Template appear in Direct Service lists, and DO NOT DELETE markers indicate templates that are hard‑wired into these flows and must remain present.

9.8 AdminMessageTemplates (note)

AdminMessageTemplates are internal guidance or helper texts used by Admin (for example LandlordDisputeStrategy, SellPaidConsultation, PaymentMissing), not client‑facing emails, and are therefore excluded from the main Template detail sections here.

They are still important in Trello workflows because they define how Admin should interpret situations like missing payments, delayed agreement to Paid Consultations, or unexpected Eliminated statuses that appear due to automation.

10. Placeholders and structure

Most templates include placeholders such as @@CLIENT_NAME@@, @@USER_NAME@@, @@INVOICE_NUMBER@@, @@TASKTITLE@@ that the BackOffice email engine replaces at send time using values from the client record, Strategy Guide and billing modules.

Developers must ensure that any new placeholder added to a template is backed by a corresponding field in the code and that removal of fields or renaming in the database is reflected in templates to avoid broken or blank insertions.

11. Triggers and status links

Many EmailNotifications are tied directly to status changes (New Enquiry, Waiting for Response, Eliminated, Freeze, Hibernated, Closed) or task lifecycle events (TaskExpired, TaskExpireFirstWarning, TaskExpireSecondWarning), and are documented alongside those rules in the AA Business Workflow.

When developers or Admin change status names, add new statuses or modify task logic, they must review corresponding templates to ensure that descriptions, links and expectations still match actual behaviour and that no orphaned templates remain.

12. Trello‑derived notes about templates

The Trello export and JSON analysis highlight specific expectations about notifications and templates, such as the one notification per new email rule, the need for Delegatee Finished emails to contain a working hyperlink back to the client, and proper handling of third‑party emails so they do not produce duplicate notifications.

They also clarify that some templates (for example Direct Service offers, Paid Consultation offers, NewLeadFrozen, NotifyBeforeAnonymisation, GDPR templates) form part of compliance‑sensitive flows and must not be deleted or repurposed without updating the documented business logic and tests.

13. Template governance and versioning

Template content and availability should be governed centrally: changes to wording, placeholders or triggers should be tracked, tested in the Staging BackOffice environment and, where relevant, reflected in this Wiki so that developers and Users know what is expected.

Templates referenced in Trello issues or marked DO NOT DELETE should be treated as configuration assets with version control, regression tests and clear owners, not as ad‑hoc texts that Users can freely remove or overwrite.

14. Usage guidance for developers and users

Developers should consult the Templates page whenever they work on notification logic, Strategy Guide printing, recurring services, referral flows or new ET‑specific emails, to reuse existing templates and avoid duplicating keys or breaking placeholder contracts.

Users and Admin can use this page to understand which email or reminder is supposed to fire in each scenario, why they are receiving particular notifications, and how to choose the appropriate StandardizedEmail or ReminderEmail when communicating manually with clients.

Enquiry Types

Enquiry Types

Enquiry Types in the BackOffice

Concept: Enquiry Type (ET)

Enquiry Types (ETs) are a core structural element of the Advocate Abroad ecosystem that define what kind of legal or professional service a client is seeking, in which jurisdiction, and under which commercial rules. Unlike simple “categories” or cosmetic labels on a record, an ET carries business meaning that drives routing, pricing, recurring behaviour, statistics, and eligibility of professionals. ETs sit alongside Statuses as two of the most impactful levers in the BackOffice platform: Status describes where the case is in its lifecycle, ET describes what the case actually is. For a UI walkthrough of how ETs are configured and used, see the Enquiry Types UI page.

Nature of Enquiry Types

Each ET is a configuration object maintained in the BackOffice “Enquiry Types” area, with fields for name, category, service type, visibility, country rules, user restrictions, billable actions, additional services, and recurrence behaviour. In BackOffice, a client record always has exactly one primary ET, which determines how that record behaves in terms of assignment options, available strategies, and downstream automation. Some ETs also imply that linked records will be created (for example, Additional Services like Translation), or that a principal/delegatee recurring model must be used (for example, Income Tax Declaration, Accounting/Bookkeeping).

Purpose and Role in the Ecosystem

The primary purpose of ETs is to encode business logic about a service into a single, reusable unit that can be referenced consistently across Website and BackOffice. By standardising ETs, the system can reliably perform tasks such as selecting appropriate professionals, building the correct quotation structure, enforcing country/profession constraints, and calculating commissions, without bespoke logic per form or per user. ETs are also the backbone for reporting, because many dashboards and statistics group cases by ET category (for example, Immigration, Property, Tax) or by specific ET (for example, a named tax or visa service) to show performance and volume.

Difference from Statuses and “Regular Enquiries”

Statuses describe the lifecycle stage of a record (New Enquiry, Created Lead, In Progress, Waiting for Response, Eliminated, Hibernated, Closed), and many automations are status-driven; ETs, in contrast, describe the substantive nature of the work and the applicable business rules. A “Regular Enquiry” in business language is simply a case that follows the standard enquiry-to-lead workflow, but in implementation terms it is always one concrete ET such as Property Purchase, Digital Nomad Visa, or Income Tax Declaration. Changing Status moves a case forward or backward in time; changing ET potentially changes the entire process that should apply to that case, including who can handle it, how it should be priced, and whether it should recur.

Role of Categories within ETs

Categories act as the top‑level taxonomy for Enquiry Types and provide a bridge between business domains, website content, and BackOffice organisation. Each ET belongs to exactly one Category, which places it within a domain such as Accounting Services, Administrative Law & Processes, Architectural Services, Business Services, Criminal Law, Family Law, Property Law, Tax Returns & Fiscal Services, Visas & Immigration, Translation Services, Insurance Services, Financial Advisor Services, and many others. In the UI, Categories appear in dropdowns when configuring an ET and are used as filters on the Enquiry Types list and in reporting views.

Operationally, Categories help Admins and Users quickly locate related ETs, enforce consistent naming conventions within a domain, and understand at a glance which broad area a given ET belongs to. Categories also support strategic decisions: they define which areas have many ETs and therefore detailed offerings, and they make it easier to design Category‑level statistics or dashboards (for example, all ETs under “Visas & Immigration” versus all ETs under “Tax Returns & Fiscal Services”).

ETs and User Capabilities

User Capabilities represent the list of ETs that a professional is allowed to handle, filtered by their profession (lawyer, accountant, translator, ASP) and countries. In practice, ETs configured in BackOffice are made available to Users through their capabilities configuration (managed in the admin tools), and only ETs enabled in a User’s capabilities can be associated with that User’s work. ET configuration and User Capabilities therefore work together: the ET defines the required profession and country profile, and the User record declares “I can take this ET”, so allocation and workload management can be managed confidently.

ETs in Website Form Intake

Every website form is mapped, via configuration, to one primary ET, and this mapping is one of the most sensitive parts of the system. When a client submits a form, the submission URL, form ID and endpoint are matched to a routing table so that BackOffice receives a new client record with the correct ET, country, and initial Status. Additional Services checkboxes on forms (for example, translation, mortgage, accounting) can create extra client records with other ETs that are linked to the main record, ensuring that all required services are represented as distinct ET-based cases.

ETs in BackOffice Client Records

In BackOffice, ET is visible and editable (with constraints) on the Overview and Enquiry Details tabs, usually via an “Optional Change Enquiry Type” function for certain statuses. The current ET determines the available Strategy Guides, Direct Service templates, and some status transitions, because different ETs may support different flows (for example, Translation or a country‑specific tax service may have distinct edge cases). ET changes are heavily audited: any change creates an Updates Record entry, can alter which Users are suitable for the case, and may reset Strategy Guides and other ET‑dependent artefacts. To see where the ET appears in the client header, view the ETs in Client Records section of the UI page.

Strategies and Templates Grouped by ET

Strategy Guides (quotation frameworks) and Direct Service templates are always defined against specific ETs and countries. When a user selects a Strategy Guide in BackOffice, the selector is filtered to show only guides whose ET and country match the client record’s ET and jurisdiction, ensuring that the questions, proposals and quotation ranges are appropriate. Direct Service Offers likewise use strategy‑ and ET‑specific templates; changing the ET can remove or add available templates, and some logic (for example, Direct Service vs Paid Consultation) depends on combinations of Status and ET. For example screens of the Strategy Guide and quotation behaviour, see the ETs and Strategy Guide – Quotation Stage section on the UI page.

Recurring and Special ET Behaviours

Certain ETs are flagged as recurring, which triggers the principal/delegatee recurring service model and recurring payment tracking flows in BackOffice. When a recurring ET is present, BackOffice can place the client into Hibernated status between cycles and then reactivate it to Ongoing on the appropriate date, allowing recurring services such as annual tax declarations or ongoing accounting to be managed without recreating records each year. Other ETs carry special rules, such as Translation‑type services (which must route to translator‑capable professionals) and specific country‑restricted ETs which only appear for particular jurisdictions.

Recurring and Special ET Behaviours

Certain ETs are flagged as recurring, which triggers the principal/delegatee recurring service model and recurring payment tracking flows in BackOffice. When a recurring ET is present, BackOffice can place the client into Hibernated status between cycles and then reactivate it to Ongoing on the appropriate date, allowing recurring services such as annual tax declarations or ongoing accounting to be managed without recreating records each year. Other ETs carry special rules, such as Translation‑type services (which must route to translator‑capable professionals) and specific country‑restricted ETs which only appear for particular jurisdictions.

Agency Referrals (Referring Client) is a special ET used as a container for organisations or individuals who regularly refer multiple end clients, rather than as a specific billable service in itself. Its purpose is to hold and maintain the contact details and relationship context for the referring party, so that linked client records (created for the mutual clients they send) can be tracked against that referrer over time. This ET therefore behaves more like a persistent account or umbrella record than a standard case: it supports ongoing collaboration and visibility of referred work, but does not itself generate commission obligations to the referring client, and it is not treated as a normal service ET for quotation or payment flows.

Country, User and Category Constraints

ET configuration includes a “Restrict To Countries” setting, which limits the ET to specific jurisdictions where that service exists, preventing it from being attached to clients in incompatible countries. A “Restrict To User” dropdown can bind the ET to a specific User when needed, which is useful for pilot services, specialist offerings, or transitional configurations. Combined with Categories, these constraints ensure that ETs are only available in relevant country contexts and that internal lists and filters remain meaningful and manageable.

Changing ET Mid-Lifecycle

Changing the ET on an existing client record is a high‑impact action and is therefore limited to certain statuses for Users, while Admins have broader override powers. A confirmed ET change can require re‑evaluation of which professional should handle the case, as the new ET may demand a different profession or capability set. The system also resets or archives ET‑dependent artefacts (such as Strategy Guides and ET‑specific statistics) and logs the change in the Updates Record for audit and reporting quality.

ETs in Reporting and Analytics

Reporting layers (dashboards, statistics, provider statements) rely heavily on ET to group and filter data, because ETs define both service type and, indirectly, revenue model. Some ETs can be explicitly excluded from certain reports (for example, rare or experimental ETs, or internal ones), and recurring ETs are sometimes treated differently in success‑rate calculations to avoid distorting metrics with long‑lived cases. Country‑specific ETs must be clearly tagged so that analytics by jurisdiction remain accurate and cross‑country comparisons are meaningful.

ET Setup Location (BackOffice)

ETs are typically created and maintained via the Enquiry Types screen in the BackOffice Admin Dashboard. From the Admin Dashboard, the “Enquiry Types” button under Lookups opens the Enquiry Type list, where Admins can review existing ETs and add new ones using the “Add Type” button. This BackOffice UI is the normal entry point for day‑to‑day ET maintenance; once an ET is defined here, it is consumed throughout the system for client records, strategies, emails and reporting.

ET Setup Screen and Core Attributes

The “Add Enquiry Type” screen exposes the main ET configuration fields required for business behaviour across Website and BackOffice, with the goal of defining the ET once so that routing, visibility, strategies, and recurring logic all follow the same rules wherever the ET is used. For screenshots and field‑by‑field UI details, refer to the Enquiry Type Creation Form – Layout section.

Primary Identification Fields

The ET Name is the human‑readable label for the service (for example, “Artist Visa Spain”, “Professional Tax Registration Service”) and appears in BackOffice dropdowns and sometimes on the website. The Category field assigns the ET to one of the global service categories (for example, Accounting Services, Property Law, Visas & Immigration, Tax Returns & Fiscal Services), which are used for grouping in UI filters and reporting. The Service Type attribute indicates whether the ET is a Primary service, an Additional service, or Both, and controls where the ET can appear (as a main enquiry versus as a linked/secondary service).

Strategy and Visibility Controls

The Saved Strategy Limit sets how many private strategy variations an individual User can store for this ET, preventing the Strategy list from becoming cluttered for very common ETs. Two toggles control visibility and operational use: Public determines whether the ET is exposed on the public website (and therefore treated as something people actively search for in search engines), while Enabled determines whether the ET can be used at all in BackOffice and related flows. ETs that represent important internal routing distinctions but low search demand may be Enabled but not Public, so they exist only for BackOffice assignment and reporting.

Billable Actions and Additional Services

ETs can be linked to a set of Billable Actions, which are discrete service items that Users select in the Completed Wizard when closing or completing work. Billable Actions allow a more granular description of exactly what was delivered under the ET (for example, “Drafting contract”, “Court appearance”, “Tax return filing”), which improves reporting and supports consistent billing and commission logic. ETs can also reference one or more Additional Services: any Additional Services linked here appear as buttons in the confirmation email sent to new clients for this ET, allowing clients to request associated services (for example, Translation, Mortgage, Insurance) directly from that email.

Recurring Settings and Hibernation Behaviour

The Recurrence section of the ET screen controls whether and how the ET participates in recurring service flows. The Has Recurring Payments toggle marks the ET as recurring (for example, annual tax filings, ongoing accounting), enabling additional recurrence fields and connecting the ET to Hibernated/Ongoing status transitions. For accounting‑style services, an additional toggle such as Accounting Service (has Monthly Payments) can be used to model frequent payment cycles within the same ET.

Recurrence parameters include labels and timing rules. The Fixed Fee Label and Recurring Fee Label define how one‑off and recurring amounts are presented to Users and in templates. The Recur period and Recur from fields set the recurrence interval and the reference date from which the cycle is calculated. A Notify Before setting defines how long before the recurrence date the assigned User receives an email notification, and it also drives the automatic change from Hibernated back to an active status (for example, Ongoing), moving the client record from the All Clients list back into the Current Clients list at the appropriate time.

Agency Referrals (Referring Client) is a special ET used to model organisations or individuals who regularly refer multiple end clients, rather than a specific billable service for the referrer themselves. Its primary role is to act as a persistent container for the referrer’s contact and relationship details while each actual end‑client enquiry is created under a separate, service‑specific ET. Once a referrer record is set to this ET, Users no longer treat it as a normal case to advance through statuses; instead, they leave it in place and, whenever the referrer sends someone new, they create or share a new client record for the end client and link it back to this referrer. No Advocate Abroad commission is payable to the referring client under this ET, and it is not used for quotation, payment or survey flows in the same way as standard service ETs.

BackOffice ET Creation Flow

In practice, the ET setup process runs as follows. An Admin opens BackOffice, navigates to the Admin Dashboard, and clicks the Enquiry Types button under Lookups to access the ET list. From there, clicking Add Type opens the ET creation screen, where the Admin completes Name, Category, Service Type, Saved Strategy Limit, Public/Enabled toggles, country restrictions, any user restriction, Billable Actions, Additional Services, and Recurrence options.

After saving the ET, Admins ensure that relevant Users have the corresponding ET in their capabilities and that any website forms, confirmation emails, and Strategies are aligned with this ET. For ETs that are Public and tied to web forms, test enquiries should be submitted on Staging or a test environment to confirm that the correct ET is assigned, that country restrictions behave as expected, and that recurring and Billable Action logic works as intended in the subsequent lifecycle.

Enquiry Types

Enquiry Types, Website Service Pages & Professional Structure in Laravel

Professional Structure – Overview

The Professional Structure module in the Laravel platform defines the catalogue of website Service pages and maps each one to an Enquiry Type (ET) and country or countries. It acts as the bridge between BackOffice ET configuration and the public website, ensuring that every visible Service page has a clear ET, jurisdiction, and routing path into BackOffice.

Where the BackOffice ET screens focus on operational configuration and Strategy Guides, Professional Structure focuses on how those ETs are exposed to clients: page titles, descriptions, URL structure, and which countries and categories the service appears under.

Service Record Structure

Each Service in Professional Structure is a configuration record that represents one website Service page. The record holds both business identifiers (linked ET, category, countries) and presentation‑layer details (titles, descriptions, SEO fields, ordering). This allows the system to reuse the same ET across multiple countries or contexts while keeping content and URLs appropriate for each case.

Typical fields on a Service record include: Service Name, URL slug and full path, Category, linked Enquiry Type, list of Countries or Sections where the service is available, short and long descriptions, SEO meta title and description, and visibility flags such as Published and Featured.

Mapping Enquiry Types to Service Pages

When defining or editing a Service in Professional Structure, admins select the linked Enquiry Type from a dropdown populated from the central ET catalogue. This association ensures that any enquiry generated from that Service page will create a client record with the correct ET, country and initial Status in BackOffice.

A single ET can underpin multiple Service records when the same type of work is offered in several jurisdictions or when distinct marketing landing pages are required. Conversely, a Service cannot exist without an ET: the Professional Structure page uses the ET as the authoritative reference for routing, pricing defaults, and reporting.

Professional Structure UI – Categories and Services

In the Professional Structure UI, Services are typically presented grouped by Category, matching the ET categories used in BackOffice (for example, Criminal Law, Property Law, Visas & Immigration, Tax Returns & Fiscal Services). Within each Category, a column or list shows individual Services such as “Assault Cases”, “Drink Driving Offences” or “Property Purchase”, each corresponding to a specific ET and country configuration.

Each Service card usually displays its name, internal ID and a list of active countries, giving admins a quick view of how widely that ET is exposed on the website. Clicking into a card opens the detailed configuration form where the ET link, countries, descriptions, and ordering can be adjusted.

Service Descriptions and SEO Content

Service descriptions are stored and managed in Professional Structure as content fields on each Service record, rather than directly inside the ET. These descriptions explain what the service covers in a particular country, outline key steps, and may reflect price patterns indicated by Strategy Guides and Intelliquote data.

For each Service, admins can configure a main page title, an introductory paragraph, optional subsections, and SEO‑specific fields such as meta title and meta description. Because these texts are effectively the public representation of “this ET in this jurisdiction”, changes in business logic or scope for an ET should be reflected in the corresponding Service descriptions to avoid inconsistencies.

Form Endpoints and Routing into BackOffice

Every Service page that can generate leads has an associated website form endpoint configured in Laravel. The endpoint links the Service URL to a specific ET and country so that when a client submits the form, Laravel creates a BackOffice client record with the correct Enquiry Type, jurisdiction and initial Status.

Form submission configuration typically includes the Service URL path, the target ET, the country, and any Additional Services that should create linked records. Whenever a Service’s ET or country list is changed in Professional Structure, the corresponding form endpoint configuration must be reviewed and updated to ensure that submissions continue to route correctly.

Synchronisation with the ET Catalogue

The list of ETs available in Professional Structure is synchronised from the central ET catalogue maintained in BackOffice and Laravel. New ETs created or updated in BackOffice become selectable in the Professional Structure ET dropdown once they are enabled and, if configured, marked as Public.

Professional Structure itself does not create ETs; instead, it consumes ET definitions, enforcing their country and category rules while attaching website‑specific content. This separation ensures that changes to business logic are made in a single place and then reflected downstream in Service page configuration.

Consistency Rules and Special ETs

Several consistency rules govern the relationship between ETs and Services. A Service’s country list must not contradict the ET’s available countries, the Service’s category should match the ET category, and disabling an ET for a country should lead to unpublishing or remapping any dependent Services.

Special ETs, such as strongly country‑specific or profession‑specific services, may have additional constraints: for example, an ET like “NIF Application Portugal” should only be used for Portuguese Services and must not appear as a generic multi‑country Service. Professional Structure should make these constraints visible so that admins cannot accidentally misconfigure the website.

Alignment with Strategies and Intelliquote

Although Strategy Guides and Intelliquote live primarily in BackOffice, their content has a direct impact on how Service pages should be written. Strategy questions and proposals outline the typical steps and options for an ET, while Intelliquote aggregates past quotations to show median and typical fees.

Marketing and operations teams should periodically review Service pages for key ETs against the corresponding Strategies and Intelliquote data, updating descriptions that reference timelines, complexity, or typical fee levels so that public information remains consistent with current practice.

Professional Structure Workflow

The standard workflow for introducing a new Service begins with creating or updating an ET in BackOffice, including its category, country rules, recurring settings and any Additional Services. Once the ET is defined, an admin creates a new Service record in Professional Structure, links it to the ET, sets the countries and category, and completes the website content fields.

After the Service is configured, the corresponding website form endpoint is created or updated so that submissions from the new page create the correct ET in BackOffice. Final checks include verifying that the Service appears under the right Category on the website, that country availability matches the intended jurisdictions, and that a test enquiry from the page reaches BackOffice with the expected ET and routing behaviour.

Invoicing & Financial Management

Invoicing & Financial Management

Standard Payments & Commission Lifecycle

1. Purpose & Audience

This page defines how standard (non-recurring, non-shared) client payments are recorded in the BackOffice CRM, how commission is calculated, aggregated, and invoiced to Users, and which control mechanisms ensure that all relevant payments are declared and settled correctly.

It is intended for Developers implementing or modifying payment and commission logic, Users (lawyers and other professionals) who must record payments and understand their commission statements, and Admin staff who oversee invoicing, collections, and financial reporting.

2. Scope & Non‑Scope

This section covers:

It does not cover:

3. Core Concepts & Definitions

3.1 Payment

A payment is any monetary amount that a client pays to a User (or to AA where applicable) in respect of a specific client record and its associated Enquiry Type (ET). In BackOffice, payments are stored in the Payments tab of the client record and form the basis for commission calculation.

3.2 Commission

Commission is the fee that AA charges a User or provider, calculated as a percentage of the ex‑VAT amount of the payments declared for a client. Commission rates are driven primarily by ET configuration in Laravel, with possible overrides per User and per provider.

3.3 Commission Base (Ex‑VAT)

The commission base is the taxable amount on which AA’s commission percentage is applied. The system assumes that VAT charged by the User to the client is excluded from the commission base. Where a User declares an amount that includes VAT, Admin may need to correct the amount so that only the ex‑VAT portion contributes to commission.

3.4 User vs Admin

A User is a lawyer or other professional who handles client work and records payments in BackOffice. Admin refers to Advocate Abroad internal staff who configure ETs and commission rules in Laravel, create blocking tasks, monitor unpaid commission, and issue or manage invoices.

3.5 Provider / Agency

A provider or agency is an organisation configured in Laravel that can send multiple clients and has its own commission structure and payment/invoicing settings. For standard payments, the logic for calculating AA’s commission per payment is the same, but aggregation and statements can be at provider level as well as per individual User.

4. Data Model Overview

4.1 BackOffice Client & Payments

4.2 Laravel Commission Configuration

4.3 Aggregation & Invoicing Data

5. Declaring Standard Payments in BackOffice

5.1 Accessing the Payments Tab

Within a BackOffice client record, the Payments tab is one of the standard tabs in the top tab bar. Only Users and Admin with appropriate permissions can add, edit, or delete payment entries.

5.2 Payment Entry Fields

A typical payment row includes at least the following fields:

5.3 Validation Rules

5.4 Status Impact of Payments

When the User has finalised the service being provided to the client and the total commissionable payments declared for a client reaches the agreed fee, Users are expected to move the client status from Ongoing to Completed. Some flows enforce this by presenting a completion popup summarising recorded payments and asking the User to confirm that the amounts match what was actually paid.

In some configurations, adding the first commissionable payment automatically changes the status from Created Lead to Ongoing or similar, to reflect that work has commenced and fees have been received.

6. Commission Calculation Logic

6.1 Determining the Commission Rate

When AA refers a client directly to a User (no prior referral from another User), the standard commission rate is 20% of the net (ex‑VAT) amount paid by the client to that User.

When a client is referred by one User to another User, the standard commission rate for the referred enquiry is 30% of the net amount paid by the client to the “referred to” User. Of that 30%, the “referring” User receives 50% as a referral share (i.e. 15% of the client’s net payment), and AA retains the remaining 15%.

6.2 Commission Base and Amount

For each commissionable payment, the commission base is the ex‑VAT amount declared. The system multiplies the base by the applicable commission rate to compute the commission amount for that payment. Commission amounts are rounded according to local accounting rules (typically to two decimal places).

6.3 Partial and Staged Payments

When clients pay in stages (e.g. provision of funds followed by final payment), Users create a separate payment entry for each amount received. The system calculates commission per payment and accumulates these amounts for the period. If a User mistakenly declares the same payment twice, Admin must remove or correct the extra line; otherwise, commission would be overstated.

6.4 Non‑Commissionable Payments

Some payments, such as pure disbursements or third‑party expenses, are recorded for completeness but should not attract commission. These entries are created with the commissionable flag set to false. They appear in the Payments tab for the client but are excluded from commission summaries and invoices.

7. Control System for Payment Declaration

7.1 Blocking Tasks

Admin can create blocking tasks in BackOffice that prevent a User from accessing other client records until a specific action is completed. One of the main blocking task types is “Add Payment”, which is used when AA knows or strongly suspects that the User has received fundsfrom a client but has not yet declared them in the Payments tab.

When a blocking Add Payment task exists, the User is presented with a popup on login or when opening another client and is redirected to the relevant client record to declare the payment. After they add the payment and mark the task as complete, normal navigation is restored.

7.2 Status Change Checks

When Users attempt to change status to Completed or Closed, the system can display a confirmation popup summarising the total payments recorded for the client. If the User enters a “total paid” that does not match the sum of payments, a warning is shown and the User is encouraged to review the Payments tab before continuing.

In some flows, status change is blocked entirely until at least one payment has been declared, to avoid Completed cases with zero payments.

7.3 Dashboards & Lists Highlighting Missing Payments

Admin dashboards can display lists of clients where:

These lists help Admin identify potential under‑reporting of payments and trigger manual follow‑up with Users.

7.4 Notification Emails to Users

When Admin creates or updates blocking tasks or when commission invoices remain unpaid, the system can send notification emails to Users. Typical notifications include:

8. Commission Aggregation & Cut‑Off

8.1 Aggregation Period

Commission is typically aggregated on a monthly basis, although quarterly or other periods are possible if configured. All commissionable payments with a payment date within the aggregation period and declared before the cut‑off date are included in the statement for that period.

8.2 Cut‑Off Rules

The cut‑off date is the point at which the system stops adding payments to the current period’s commission batch. For example, if invoices are issued on the first Friday of the month, all payments in the previous calendar month that have been declared up to that Friday are included. Late declarations may be carried to the next period or, in special cases, handled by manual adjustment.

8.3 Grouping by User and Provider

The aggregation process groups payments by:

Each group forms the basis for one invoice or statement issued to that party.

9. Invoicing Commission to Users

9.1 Invoice Generation

Certain Enquiry Types have a fixed commission rate of 20% regardless of whether the client came via a referral. For those Enquiry Types, if another User has referred the client, the referrer still receives 50% of the commission, but the split is applied to the fixed 20% rate (i.e. 10% of the client’s net payment to the “referred to” User for the referrer, and 10% for AA).

9.2 Invoice Contents

A standard commission invoice includes at least:

In many cases, a detailed statement is attached or accessible in the User’s dashboard, listing each client, ET, payment amount, commission rate, and commission amount.

9.3 Delivery & User Access

Invoices are delivered via email to the User’s registered address and may be accessible in a “Commission Statements” or similar section of the User dashboard. Users are expected to pay the invoice by the due date using the provided bank details.

9.4 Overdue Invoices

When an invoice is not paid by the due date, the system can:

10. User & Admin UI Behaviour

10.1 User View

Users interact primarily with:

10.2 Admin View

Admin users have additional views and actions, including:

11. Edge Cases & Known Pitfalls

11.1 Incorrect VAT Handling

A common issue is Users entering the total amount received from the client, including VAT, as the commissionable amount. This leads to over‑charging of commission. Admin should correct such entries by reducing the commissionable base to the ex‑VAT amount and, if necessary, adjusting any already issued invoices via credit notes (documented under 7.4).

11.2 Duplicate Payments

Duplicate payment rows can occur if a User creates a new payment entry instead of editing an existing one. The system cannot reliably detect all duplicates, so Admin should periodically review payment lists for anomalies (e.g. same amount and date appearing twice) and instruct Users to correct errors.

11.3 Zero or Missing Payments on Completed Cases

If a case reaches Completed or Closed status with no payments recorded, dashboards or reports may highlight it as a potential issue. Admin should follow up with the User to confirm whether the client never paid or whether the payment has not yet been declared.

12. Configuration Points (Laravel)

12.1 Commission Settings per User

In Laravel, each User profile has a Commission Settings section, where Admin can define:

12.2 Commission Settings per ET

Each ET configuration in Laravel includes:

12.3 Provider Settings

Provider records in Laravel define:

13. Process Flow: Lead to Commission

13.1 High‑Level Steps

  1. Lead captured and assigned: Website form submission creates a client record in BackOffice with an ET and assigned User; status is New Enquiry or Awaiting Assignment.
  2. Service delivered: User communicates with the client, sends quotations, and carries out agreed work. Status moves through Created Lead, In Progress, and Waiting for Response as appropriate.
  3. Client payment received: User receives payment from the client (advance, lump sum, or staged) and records each payment in the Payments tab as a commissionable entry.
  4. Commission computed: For each commissionable payment, the system determines the applicable commission rate and calculates commission. These values are stored and visible in relevant reports.
  5. Status completion: When work is complete and fees have been fully received, the User changes status to Completed and, if applicable, confirms payment totals in a popup.
  6. Aggregation & invoicing: At period end, commission amounts per User are aggregated, invoices are generated, and Users receive commission invoices and statements.
  7. Payment of commission: Users pay AA’s invoice. Overdue invoices trigger reminders and potential operational restrictions until resolved.

14. Testing & QA Considerations

When implementing or modifying payment and commission logic, testers should verify at minimum:

15. Open Questions & Future Enhancements

Invoicing & Financial Management

Accountant Convert Monthly Set-up to Monthly Client

1. General description

The Set-up to Monthly Client process describes how a one-off Set-up Only enquiry (for example Autonomo (Set-up Only) ID 241 or Limited Company Set-up Service ID 206) is converted into an ongoing monthly accounting client using the corresponding recurring service types (Self-Employed Set-Up Service ID 247 and Tax & Accounting Services (Limited Companies) ID 1360).

This process sits primarily in the BackOffice client lifecycle for General / Regular Enquiries, but it has implications for Business Logics (commission, reporting, statuses) and Technical Info (recurring services, payments). It is used by professionals/accountants and, where relevant, Admin, once the initial set-up engagement has been agreed and paid, and the client wishes Advocate Abroad partners to manage ongoing tax and accounting obligations.

The description here reflects the intended behaviour in Business Logic v2.0: the Set-up Only record is the entry point, a dedicated conversion action creates a linked monthly client record with the correct service type and recurring fee, and the original set-up record is automatically closed so that all future lifecycle actions occur only in the monthly record.

2. Business goals & objectives

The Set-up to Monthly Client process supports several core business objectives within the General / Regular Enquiry lifecycle.

  • Ensure that every client who moves from a one-off Set-up Only engagement to ongoing tax and accounting support has a clearly defined, separate monthly client record with the appropriate ET and pricing.
  • Guarantee that the Set-up Only engagement is financially complete (set-up fee recorded as Payment Received) before ongoing work is treated as a monthly service.
  • Align recurring invoices, Advocate Abroad commission calculations, and reporting with the correct monthly service types (IDs 247 and 1360) instead of reusing the Set-up Only ETs.
  • Prevent double handling and confusion by automatically closing the original Set-up Only record once a monthly client record is created, eliminating the need for further Next Progress Date (NPD) updates on the one-off enquiry.
  • Provide a consistent, predictable route for accountants to turn successful Set-up Only engagements into longer-term client relationships, thereby increasing lifetime value and stabilising revenue.

3. Detailed behaviour & step by step flow

This section describes the end-to-end behaviour, from the moment a Set-up Only enquiry is ready for conversion, through to the creation and use of the monthly client record.

3.1 Entry conditions

  • The client must already have an active Set-up Only enquiry in BackOffice, such as Autonomo (Set-up Only) ID 241 or Limited Company Set-up Service ID 206.
  • The professional has agreed with the client that, after registration/incorporation, the professional will continue to manage ongoing tax and accounting obligations for a fixed monthly fee.
  • The intended first month of the monthly service (year and month) is known and agreed with the client.

3.2 Financial validation on the Set-up Only record

  1. The accountant opens the Set-up Only enquiry in BackOffice.
  2. They record the set-up fee by clicking the Payment / Services button for that enquiry.
  3. In the payment popup, they enter the agreed service fee amount for the set-up engagement and submit it so that the Set-up Only record reflects the Payment Received amount for the one-off work.

This payment entry ensures that the set-up engagement can be treated as financially complete before the monthly client record is created.

3.3 Triggering the conversion from set-up to monthly

  1. Still on the Set-up Only enquiry screen, the accountant initiates the conversion by clicking the Create Monthly Client Record button.
  2. A confirmation popup appears asking whether to create a new client record to handle monthly payments from this client.
  3. The accountant confirms by selecting Yes, which instructs the system to start the monthly service creation flow based on this Set-up Only enquiry.

3.4 Defining monthly service terms

  1. After confirmation, a dialog titled Create Accounting Service for [Client Name] is displayed.
  2. The accountant enters the agreed recurring amount into the field “What monthly fee this client will pay?”.
  3. The accountant selects the year and month for “What will be the 1st month of the service?”, corresponding to the first month during which ongoing accounting/tax work will be delivered.
  4. The first month selected is included in the first monthly invoice raised under this accounting service; there is no separate pro-rata invoice in this logic.
  5. The toggle “Close set-up client record(s)” remains switched on by default so that, if the monthly record is created successfully, the originating Set-up Only record is automatically marked as closed.
  6. The accountant clicks Create Accounting Client Record to complete the configuration.

3.5 System actions on creation of monthly record

When the accountant confirms the creation:

  • The system validates that a monthly fee and a first month of service have been provided.
  • A new monthly accounting client record is created and linked to the same person/contact as the original Set-up Only enquiry.
  • The monthly record uses the appropriate recurring service type:
    • If the originating ET is Autonomo (Set-up Only) 241, the monthly record is created under Self-Employed Set-Up Service ID 247.
    • If the originating ET is Limited Company Set-up Service 206, the monthly record is created under Tax & Accounting Services (Limited Companies) ID 1360.
  • Core client and configuration data (name, contact details, location, tax jurisdiction context) are copied from the Set-up Only record into the new monthly record.
  • Advocate Abroad’s commission configuration for recurring services is automatically applied to the new monthly record so that subsequent monthly payments will automatically allocate the correct commission.
  • With “Close set-up client record(s)” enabled, the originating Set-up Only record has its status updated to the appropriate closed state, and no further Next Progress Date is required on that record.

3.6 Behaviour of the new monthly client record

  • The monthly client record becomes the primary record for all future interactions with that client regarding ongoing tax and accounting services.
  • All recurring billing (for example monthly invoices), monthly or quarterly tax filings, bookkeeping work, and ongoing communications should be managed from this monthly record.
  • The record is configured to support recurring services for the chosen ET (247 or 1360), including correct reporting and commission capture.
  • The system does not require or expect NPD updates on the closed Set-up Only record; scheduling and follow-up for the monthly work are handled by whatever NPD and task logic applies to monthly services in the broader Business Logic.

3.7 Exit points

  • The process ends when the new monthly accounting client record has been successfully created and the originating Set-up Only record has been closed.
  • From that point, the only further lifecycle change is to set to Completed and then Closed (by Admin)

3.8 Alternative entry: “Set-up Monthly Client” button

As an alternative to converting from a specific Set-up Only enquiry, the User can create a monthly client at any time by using the dedicated Set-up Monthly Client button, which opens the same “Create Accounting Service for [Client]” dialog shown in the set-up conversion flow.

  1. From the client’s BackOffice record, the User clicks the Set-up Monthly Client button (labelled “Create Monthly Client Record” in the Payment & Services area).
  2. The system displays the Create Accounting Service for [Client] popup.
  3. The User optionally selects “Who should deal with the service?” to assign a specific professional to the monthly engagement.
  4. The User enters the agreed amount in “What monthly fee this client will pay?”.
  5. The User chooses the year and month in “What will be the 1st month of the service?”, which defines the first month covered by the initial monthly invoice.
  6. Because this path is not necessarily tied to a specific Set-up Only enquiry, the “Close set-up client record(s)” toggle only has effect if there are open Set-up Only records linked to this client; otherwise it has no practical impact.
  7. The User clicks Create Accounting Client Record, and the system creates a new Monthly Client record of the appropriate type for ongoing services, without requiring a preceding set-up payment flow in the same screen.

This alternative path is intended for situations where a monthly accounting relationship is established independently of a Set-up Only ET, or where the User wishes to regularise a long‑standing client into the standard Monthly Client structure without re‑opening historic set-up workflows.

4. Confusions, edge cases & known issues

The following issues and potential confusions are known or anticipated for this process based on the documented behaviour and UI flow.

  • Professionals may continue to work inside the original Set-up Only record after conversion, instead of using the new monthly client record. The intended behaviour is to treat the Set-up Only record as historical only once the monthly client record exists.
  • If the accountant forgets to record the Set-up Only payment before creating the monthly record, reporting on set-up revenue vs monthly revenue may be inconsistent, even though the system allows the monthly record to be created after payment entry. The business intent is that the one-off payment is correctly captured before ongoing work begins.
  • There is potential confusion between “Self-Employed Set-Up Service ID 247” as a label and the original Set-up Only ET 241. In this process, 247 is the recurring monthly service type, not another one-off registration service, and should only be created from or in place of a completed 241 engagement.
  • Closing the Set-up Only record automatically via the “Close set-up client record(s)” toggle means users must understand that no further NPD updates are required on that record; forgetting this may lead to attempts to manage follow-up dates on a closed enquiry.
  • Edge cases where a client delays the start of monthly services (for example set-up completed in one month, but monthly service starts several months later) are handled by selecting a future “first month of the service” value, but the documentation does not specify additional constraints; any further rules (for example maximum gap allowed) would need explicit definition.

5. Permissions & access rules

The source documents do not define detailed role-based permissions for who may initiate the Set-up to Monthly Client conversion.

The working assumption for this page is that the conversion action is available to the professional or accountant responsible for the Set-up Only enquiry and, where configured, Admin users. If more granular rules exist (for example only Admin can configure monthly fees, or some users cannot close Set-up Only records), these need to be specified in separate permission documentation and linked here.

6. Timing, automation & background jobs

The Set-up to Monthly Client process itself is a user-triggered conversion and does not define additional SLAs or time-based automation beyond what already applies to NPD and status management in General / Regular Enquiries.

  • The only explicit timing-related rule in this process is that the “first month of the service” chosen during creation defines which calendar month is included in the first monthly invoice for the new accounting service.
  • Automatic closure of the Set-up Only record happens immediately when the monthly record is successfully created and the “Close set-up client record(s)” option is enabled; there is no delayed closure.
  • Any additional automation affecting the monthly record (for example NPD expiry, hibernation, or anonymisation behaviour) is governed by the general Business Logic for recurring services and is not redefined here.
  • No specific cronjob or background task is documented as operating solely on this conversion process; instead, the monthly record participates in the same background jobs that apply to all recurring client records.

7. Dependencies & interactions with other processes

The Set-up to Monthly Client process depends on and interacts with several other parts of the Advocate Abroad ecosystem.

  • It depends on correct configuration of Enquiry Types (ETs) for Set-up Only services (for example 241 and 206) and recurring services (247 and 1360) so that the system can map from the original ET to the correct monthly service type.
  • It requires that the General / Regular Enquiry lifecycle be functioning correctly, including statuses and Next Progress Date logic, so that the Set-up Only record reaches the point where conversion is appropriate.
  • The process interacts with the Payments and Commissions business rules, ensuring that one-off set-up payments are recorded against the Set-up Only record and recurring monthly payments are recorded against the monthly record with appropriate commission.
  • The new monthly record will participate in any Recurring Services logic (for example recurring invoicing, long-term client metrics) defined elsewhere in the Business Logics book, but those rules are not duplicated here.
  • Closing the Set-up Only record ensures that background processes and queues that rely on statuses and NPD (such as daily updates or OOO summaries) treat the client as handled under a monthly service rather than as an open one-off enquiry.

8. Error handling, recovery & idempotency

The documentation does not describe detailed error-handling or idempotency rules specific to this conversion process; however, some practical considerations follow from the intended behaviour.

  • If the creation of the monthly client record fails (for example due to validation errors on the monthly fee or first month of service), the system should keep the Set-up Only record unchanged and present validation feedback to the user so they can correct the input and retry.
  • If the monthly record has already been created and the user accidentally attempts the conversion again, the behaviour for a second “Create Monthly Client Record” action is not defined in the available sources; this should be treated as an open question and resolved at implementation time (for example by blocking repeat conversions or linking to the existing monthly record).
  • Corrections to wrongly entered monthly fee or first month of service are expected to be made directly on the monthly client record, not by re-running the conversion.
  • If payment for the Set-up Only service was entered incorrectly, standard payment correction tools should be used on the Set-up Only record; this does not inherently affect the existence of the monthly record but may impact reporting and commission totals.

9. Performance & scalability considerations

The available documentation does not mention specific performance constraints or optimisation requirements for the Set-up to Monthly Client process.

The implicit expectation is that creation of the monthly client record, copying of client data, and closure of the Set-up Only record occur quickly enough that the user sees the new record and updated status without noticeable delay. Any list views or dashboards that include monthly records should reflect the new record according to the standard refresh and pagination behaviour defined elsewhere.

10. Configuration & customisation

This process depends on configuration of service types and some aspects of recurring service behaviour.

  • The mapping from Set-up Only ETs (for example Autonomo 241, Limited Company 206) to monthly service ETs (247 and 1360) is treated as a configuration or code-level rule; it must be maintained consistently so that the correct monthly ET is always chosen.
  • Default behaviour for closing Set-up Only records (“Close set-up client record(s)” being on by default) is a configuration choice that could potentially be changed if business rules evolve, but the documentation assumes closure is the norm.
  • Monthly fee amounts and first month of service are not hard-coded; they are entered case-by-case by the professional at the time of conversion, reflecting negotiated terms with each client.
  • Any additional reporting flags or inclusion/exclusion rules (for example whether certain ETs are eligible for conversion, or how converted clients appear in statistics) must be configured in line with the broader Business Logic v2.0 but are not further detailed here.

11. Notifications & communication rules

The sources do not define specific email or notification templates tied uniquely to the Set-up to Monthly Client conversion event.

It is understood that professionals may inform clients manually (for example by email) about the start of ongoing services, the agreed monthly fee, and the first month included in the first invoice, but these communications are governed by general messaging rules and not by a dedicated automated notification in this process. If, in future, automatic client or Admin notifications are added when a monthly record is created from a Set-up Only enquiry, they should be documented here with triggers and recipients.

12. Historical changes & Trello driven updates

The Set-up to Monthly Client process is part of the broader evolution from ad hoc handling of recurring clients to a structured recurring services model in Business Logic v2.0.

  • Historically, professionals may have continued to manage ongoing work within the original Set-up Only enquiry or created separate records manually, leading to inconsistent reporting and commission tracking. The current process formalises a single, guided conversion path.
  • The explicit mapping from Set-up Only ETs to recurring ETs (241 → 247, 206 → 1360) and the automatic closure of the Set-up Only record are intended to eliminate legacy confusion about where recurring work should be stored.
  • Any older data where monthly work is attached directly to Set-up Only records should be treated as legacy and, where feasible, migrated to the new structure when practical.

13. Compliance & legal constraints

The Set-up to Monthly Client process touches compliance primarily through financial and audit requirements rather than direct legal rules.

  • Recording the Set-up Only payment and then the recurring monthly payments on the appropriate records supports transparent financial reporting and, where applicable, tax or accounting obligations of the professionals.
  • Maintaining a clear separation between the one-off set-up engagement and the ongoing monthly engagement helps ensure that invoices, commissions and revenue recognition are traceable and auditable.
  • Any GDPR-related handling of client records (for example anonymisation after retention windows) is governed by global GDPR and data protection processes and applies equally to Set-up Only and monthly records; this process does not override those rules.

14. Known backend services & integration points

The documentation does not enumerate specific Laravel modules, APIs or background jobs dedicated solely to this process, but several backend components are implicitly involved.

  • The BackOffice models for Enquiry Types, client records, payments, and recurring services must support creation of a new monthly record linked to an existing client and ET mapping.
  • Payment handling services are invoked when the set-up fee is recorded and when recurring payments are later taken under the monthly record; commission logic depends on the chosen ET.
  • Any APIs or jobs responsible for reporting or dashboards that distinguish between one-off and recurring revenue must use the ET and record type (Set-up Only vs monthly) to group figures correctly.
  • NPD and status-handling services will treat the closed Set-up Only record differently from the active monthly record, in line with the general Business Logic for statuses and NPD.

15. Behavioural guardrails & Project Manager guidance

The following guardrails express the intended way professionals and the system should use this process, and the mechanisms that support that behaviour.

  • Always convert successful Set-up Only clients to a dedicated monthly record. Ongoing tax and accounting work should not continue indefinitely inside a Set-up Only enquiry. The dedicated “Create Monthly Client Record” button is the mechanism that enforces a clean separation between one-off and recurring work.
  • Record the Set-up Only payment before or alongside conversion. Professionals should ensure that the set-up fee is properly recorded via the Payment / Services flow so that financial reporting and commission on the one-off work are complete before relying on the monthly record. The payment popup and Payment Received indicators are the tools for this guardrail.
  • Use the monthly record as the single source of truth for ongoing work. Once a monthly record exists and the Set-up Only record is closed, all future NPD updates, messages, tasks, and payments must be added to the monthly record. Automatic closure of the Set-up Only record, plus the absence of further NPD requirements on it, are intended to nudge users to the correct place.
  • Do not bypass the mapped ETs. Professionals should not manually create adhoc recurring ETs unrelated to the documented mapping (241 → 247, 206 → 1360) for this workflow, as that would undermine standard reporting and commission rules. The predefined ET mapping and the dedicated conversion flow are designed to encourage consistent use.
  • Clarify monthly terms with the client. The monthly fee and first month of service must reflect what was actually agreed with the client; the fields in the “Create Accounting Service” dialog capture these parameters explicitly to reduce ambiguity later.
Invoicing & Financial Management

Admin Payments Management

1. General description

The BackOffice Invoice Management area is where Admin manage monthly commission invoicing to Users, track client payments collected directly by AA, record AA’s own expenses, and generate summary reports for the accounts department. It consolidates all amounts that originate from payments declared in client records and from manually entered expense transactions, and exposes them through several tabs: Summary, Upcoming, Past, Client Payments, Payments, Expenses, and Reports.

From this screen Admin decide which User invoices should be emitted, approve or skip low‑value invoices, mark invoices as paid (emitting receipts), correct over‑ or under‑payments, issue credit notes when necessary, and export period‑level financial summaries needed for tax filings.

2. Business goals & objectives

  • Aggregate all commission due from User‑declared client payments into a clear monthly view, so AA can raise accurate invoices.
  • Allow Admin to apply business rules such as minimum invoice thresholds (e.g. not issuing invoices below a certain amount) before committing to send invoices.
  • Track the full lifecycle of each invoice (created, processed, paid, corrected, credited) with minimal manual work and proper supporting documents.
  • Record and categorise AA’s own expenses and supplier transactions so that net results and tax amounts can be reported correctly.
  • Provide downloadable reports suitable for hand‑off to external accountants for periodic tax filings.

3. Detailed behaviour & step by step flow


3.1 Monthly totals and Summary tab

The Summary tab in Invoice Management shows a month‑by‑month overview of AA’s position for the selected financial year. Each row represents a month (plus a special Pending row for the current month that is not yet closed) and includes columns such as:

  • Current Month Net (Last Year Same Month) – net revenue for that month, with an up/down arrow indicating whether it is higher or lower than the same month in the previous year.
  • Total Tax – total VAT or equivalent tax summed across all invoices for that month.
  • Total Outstanding – total amount of invoices issued but not yet marked as paid for that month.

Admin typically use this view to monitor trends, quickly see which months still have unpaid invoices, and confirm that the “Pending” month is ready to be closed once all relevant client payments have been declared and invoices processed.

3.2 Upcoming tab – deciding which invoices to emit

The Upcoming tab lists all future or not‑yet‑emitted commission invoices that could be generated for Users based on payments they have declared in client records. For each User, the system aggregates commission amounts for the current billing period (usually monthly) and shows an entry representing the draft invoice.

  1. Admin open Invoice Management and click the Upcoming tab.
  2. The table lists Users (or providers) with their pending invoice amounts for the chosen period, usually with columns such as Invoicee (User), Net Total, Tax, Total, and possibly a flag indicating whether the invoice is currently marked to be emitted.
  3. For each row, Admin decide whether the invoice should be created in the next run. The unwritten but applied rule is that invoices with a Total below approximately €50 are typically not emitted, to avoid bank charges or disproportionate costs for the User; higher amounts proceed as normal.
  4. Admin mark low‑value invoices as “do not emit” (for example by unchecking a “Process” checkbox, using an action dropdown, or similar UI control) so they are skipped when invoices are generated.
  5. When ready, Admin trigger the monthly invoice generation process (typically via a separate command or scheduled procedure), which converts all “to be emitted” rows into actual invoices visible in the Past tab.

3.3 Past tab – managing existing invoices, receipts, corrections, and credit notes

The Past tab (often labelled Invoice History) lists all previously created invoices with key columns: Invoice number, Created date, Receiver (User), Net Total, Tax, Total, Processed flag, and Receipt Issue Date. Each row includes an Actions button which opens a menu for common admin operations.

Typical actions available per invoice are:

  • Set paid – marks the invoice as paid and automatically issues a receipt.
  • Regenerate invoice – rebuilds the invoice document using updated configuration (for example, if VAT must be removed because the User has later provided a valid EU VAT number).
  • Correction – creates an adjusted receipt when the User has paid too little or too much.
  • Credit Note – issues a credit note when AA needs formally to reverse part or all of an already paid invoice.
3.3.1 Set paid
  1. Admin locate the invoice row in Past and click Actions > Set paid.
  2. The system marks the invoice as processed/paid, fills the Receipt Issue Date with the current date (or allows Admin to pick a date), and generates a receipt document referencing the original invoice.
  3. The invoice’s outstanding balance is reduced to zero in the Summary and any relevant reports.
3.3.2 Regenerate invoice
  1. Admin select Regenerate invoice from the Actions menu of the target invoice.
  2. The system rebuilds the invoice document from the underlying data (client payments, commission rates, VAT rules) applying the current configuration.
  3. This is typically used when VAT must be added or removed (for example, when a User gains or loses a valid EU VAT number) or when commission settings have been corrected but the underlying payments remain the same.
3.3.3 Correction (under/over‑payment)
  1. If a User pays an amount that is different from the invoice total, Admin open the Actions menu and choose Correction.
  2. The correction tool allows Admin to enter:
    • How much the User actually paid.
    • Whether the difference should be treated as under‑payment or over‑payment.
  3. The system generates an adjusted receipt that matches the amount received and automatically carries the missing or extra amount into the next commission invoice:
    • If the User paid less, the shortfall is added to the next invoice as an additional line.
    • If the User paid more, the excess is deducted from the next invoice.
  4. This ensures that each receipt matches the bank transaction while cumulative commission over time remains correct.
3.3.4 Credit Note
  1. Where a User has already paid an invoice but AA decides to refund part or all of the amount, Admin use the Credit Note action from the invoice’s Actions menu.
  2. The Create Credit Note popup shows the original invoice totals and provides two main input areas:
    • Payment Rebate – entering an amount here applies a rebate proportionally to the commission portion (for example, entering €100 may generate a €20 credit if commission was 20%).
    • Fixed Amount – entering an amount here applies that exact value as a negative line in the credit note.
  3. Admin can add comments for each line to document the reason (for example, “overcharged commission on case X”).
  4. After clicking Add for the relevant lines and confirming, the system generates a credit note document linked to the original invoice. Admin may choose whether or not to send the credit note to the User; in some cases it is issued mainly for internal accounting if the User has already been reimbursed via bank transfer.

3.4 Client Payments tab – proformas and direct client receipts

The Client Payments tab lists invoices and proforma invoices issued to end clients in situations where AA collects funds directly (for example via card payments or other online methods) before passing on the User’s share. Each row shows information such as invoice or proforma number, creation date, receiving User, net total, tax, total, processed flag, and receipt issue date.

Important points for Admin:

  • The net total received from the client is not the same as AA’s commission amount. AA must pay the collaborating professional their share of the fee, and in referral cases also pay referral commission to the referring User.
  • From this screen Admin can download client invoices, monitor which client payments have been processed in the external accounting system, and ensure that transfers to Users and referrers are reconciled with the amounts shown.

3.5 Payments tab – AA’s own outbound payments

The Payments tab (if enabled) is used to record outbound payments made by AA that are not suppliers’ expenses (for example, settlements, refunds, or specific transfers to partners) and to reconcile them with corresponding invoices or credit notes. The structure is similar to Expenses but oriented around payments out rather than invoices in.

3.6 Expenses tab – suppliers, categories and recurring transactions

The Expenses tab is where Admin record and manage AA’s own supplier invoices and operational expenses. It is composed of several related views and popups.

3.6.1 Expenses list
  1. Admin open Invoice Management > Expenses.
  2. The main table lists expense transactions with columns: Date, Category, Total, VAT %, Issuer (supplier), and Comment/Attachments.
  3. A bar at the top shows the aggregated net total and VAT for the currently selected period (“In the selected time period”).
  4. Filters allow narrowing by Issue Date, Issuer, Category, and Transaction Type (e.g. Expense vs Income).
  5. Clicking Add Transaction opens the Add New Transaction form (see below).
3.6.2 Add New Transaction
  1. From the Expenses tab, Admin click Add Transaction.
  2. The Add New Transaction form appears, with required fields such as:
    • Transaction Type – for example Expense or Income.
    • Category – transaction category (e.g. Professional Services, Software, Webhosting, Telephony).
    • Issuer – supplier from the Suppliers list.
    • Issue Date, Billing Address, Tax Number, and Invoicing Company.
    • Amount (net), VAT %, VAT amount, Retention, and Grand Total.
    • Optional Reverse Charge toggle and Attachment(s) upload for invoice PDFs.
  3. After completing the fields, Admin click Save. The new expense appears in the main Expenses table and is included in period totals and reports.
3.6.3 Transaction Categories management
  1. From the Expenses tab, Admin click Categories to open the Transaction Categories screen.
  2. This shows a grid of existing categories (e.g. Financial Income, Financial Services, Office Rental, Salary, Telephony, Travel & Expenses, User Share Fee, etc.), each with an X button to delete.
  3. Admin can type a new category name into the input at the bottom and click Add to create a new category.
  4. These categories then become available in the Category dropdown when adding or editing transactions.
3.6.4 Suppliers and recurring transactions
  1. From the Expenses tab, Admin click Suppliers to open the suppliers list.
  2. The table lists suppliers with fields like Id, Company Name, Address, VAT Number, and a column for Recurring Transaction(s).
  3. Each supplier row shows existing recurring expenses (e.g. “€164.00 every 1 Years from 30/06/2025”) and a link Add Recurring Transaction.
  4. Clicking Add Supplier opens a popup with fields for Name, Address, and VAT Number; clicking Submit creates the supplier.
  5. Clicking Add Recurring Transaction (or editing an existing one) opens the Edit Recurring Transaction popup, with fields:
    • Type – usually Expense.
    • Category – such as Professional Services.
    • Amount, VAT %, Retention.
    • Is Reverse Charge? toggle.
    • Recurrence – e.g. every 1 Months or every 1 Years.
    • Start Date.
  6. When submitted, these recurring transactions automatically generate expense entries at the configured interval, reducing manual data entry.

3.7 Reports tab – generating files for tax filing

The Reports tab provides Admin with period‑based export tools to compile figures for the accounts department and external accountants.

  1. Admin open Invoice Management > Reports.
  2. The top of the screen shows a Reporting Period control with:
    • Preset buttons This Month, Last Month, Year To Date, Last Year.
    • A date range selector where Admin can choose custom start and end dates.
    • A Reset button to clear filters.
  3. After selecting the desired period, Admin click Get Financial Report.
  4. The system generates a financial report file (typically CSV, Excel or PDF) summarising:
    • Client invoice totals (net, tax, gross) for the period.
    • Commission invoiced to Users.
    • Expenses by category and total VAT on purchases.
  5. Admin send this file to the accounts department or upload it into external accounting software for VAT and corporate tax submissions.

4. Confusions, edge cases & known issues

  • There is an internal rule that invoices below approximately €50 are usually not emitted to avoid disproportionate bank and transfer costs for Users. This threshold is not currently enforced automatically in the UI; Admin must manually deselect small invoices in the Upcoming tab.
  • When correcting under‑ or over‑payments, Admin must be careful to use the Correction tool rather than issuing a credit note unless a formal refund is actually being made. Over‑use of credit notes can complicate external accounting and tax reporting.
  • In the Client Payments tab, Admin must remember that the net total shown is the full amount paid by the client, not AA’s commission. Separate systems or reports handle pay‑outs to professionals and referrers; this screen alone does not show those deductions.

5. Permissions & access rules

Access to Invoice Management and its actions is normally restricted to Admin and finance roles. Regular Users (lawyers and ASPs) do not see this area. Only Admin should be able to:

  • Decide which draft invoices proceed from Upcoming to issued state.
  • Mark invoices as paid, regenerate invoices, apply corrections, and issue credit notes.
  • Create and edit expense transactions, categories, suppliers, and recurring transactions.
  • Generate financial reports covering all Users and all clients.