Format A: Regular Enquiry

Ensure that every valid website form submission is converted into a BackOffice client record with the correct Enquiry Type (ET), country, and initial status (New Enquiry or NPD – Awaiting Assignment).

Route each enquiry to an appropriate professional via autoassign, taking into account ET, country, profession and availability; if this fails, mark as NPD and alert Admin.

Enforce a status-driven lifecycle (New Enquiry → Created Lead → In Progress / Waiting for Response → Completed → Closed or Eliminated), with popups for elimination reasons and completion/payment confirmation.​

Maintain accurate, auditable payment data, so that invoices and commission statements can be generated automatically and tied to recorded Payments entries.

Maintain a full audit trail of activity via the Updates Record, including status changes, ET changes, NPD events, assignment, payments, and Admin interventions.

Support GDPR-compliant retention, with anonymisation and deletion applied automatically to inactive enquiries according to configured timelines.

Not updating status after contact: Users sometimes forget to change from New Enquiry to Created Lead or In Progress after talking to the client; this can trigger duplicate automatic emails or give the impression that the client has not been contacted.

Skipping Offer Email: Some Users provide substantial advice on the first call without sending an Offer Email or consultation confirmation, leading to later disputes about what was promised; the business rule is that services and fees should be confirmed by email.

Recording payments late or not at all: Payments are sometimes taken but not added to the Payments tab, which blocks Completed status (or misaligns totals) and breaks invoicing; Admin then has to chase for manual corrections or add payments retroactively.

Using the wrong ET or country: Misconfigured form endpoints or ET changes without understanding restrictions (e.g., NIF Application Portugal) cause routing and reporting problems, requiring Admin overrides.

Leaving clients “in limbo”: Cases remain In Progress or Waiting for Response with no updated Next Progress Date and no Updates comments, making it difficult for Admin to assess whether clients are being neglected; several internal messages explicitly request short Updates Record summaries and proper Next Progress Date management.

Only Admin and system autoassign can set the Assigned User for new enquiries by default; Users do not self-assign regular leads unless Admin workflows explicitly allow this.​

Only Admin can override ET country/profession restrictions and force ET changes at any status; Users can change ET only while the client is New Enquiry or Created Lead, and only to compatible ETs.​

Certain flags – Direct Service and Consultation Only – can be set only by Admin; these flags alter available statuses, templates and follow-ups, but Regular Enquiries operate without requiring these flags.​

Tasks created by Admin (e.g., “Add Payment”, “Upload Document”, “Complete Billable Actions”) can be marked as blocking, preventing Users from accessing other client records until completed; this is particularly used when a payment is clearly received but not registered.

Out-of-Office settings are configured by Users (period and behaviour), but Admin can see an OOO dashboard and can reassign leads or override OOO if necessary.​

Website-to-BackOffice creation: record must appear immediately after form submission (within a few seconds), including ET, country and status.​

Client contact SLA: system texts and internal messages emphasise contacting clients within around 24 hours; if calls fail, standard “We tried to reach you” emails are sent automatically.

NPD expiry: NPD leads older than a configured duration (e.g., 72 hours) are flagged as Expired and appear in Admin lists and summary emails; they do not automatically eliminate, but require Admin action.​

Waiting for Response / Next Progress Date: Users are expected to set Next Progress Date whenever they extend the follow-up horizon beyond about two weeks, and Admin explicitly requests single-line updates if the next action is weeks away.

GDPR retention: inactive enquiries (Eliminated, Closed) are anonymised after about six months and deleted after about twelve months, with configuration per jurisdiction; these jobs run automatically and are tracked for audit.

Email notifications: system sends New Client Assigned, We tried to reach you, Payment Declared, Client Response, and survey invitations based on specific triggers (assignment, call result buttons, payment additions, status changes to Completed/Closed).

Website forms and Laravel endpoints must be configured and tested (Form-to-ET mapping, country detection, confirmation emails) for Regular Enquiries to flow in correctly.

ETs in Laravel must be configured with routing, commission, recurring flags and any special rules (e.g., NIF Portugal, Translation, Recurring ETs).

NPD recovery (Process 2): handles reactivation and manual assignment when Regular Enquiries fall into NPD (e.g., OOO issues, no eligible Users).​

Out-of-Office lead reassignment (Process 3): ensures new Regular Enquiries are not stuck with OOO Users and that Admin can redistribute them.​

Recurring services (Process 4): some Regular Enquiries (e.g., Income Tax, Monthly Fiscal) evolve into principal/delegatee recurring records after initial work; that flow is handled by the recurring service process.​

Additional Services / ASP referrals: Regular Enquiries can spawn ancillary client records (translation, accounting, mortgage, insurance) via Add Service; these are linked but follow their own flows.

Paid Consultation and Direct Service flows reuse parts of the Regular Enquiry pipeline (Strategy Guide, Offer Emails), but enforce different constraints on templates, follow-ups and elimination; this page assumes the non-flagged Regular Enquiry case.

Recurring principal / delegatee records use Hibernated, In Progress and special completion flows; those should not be confused with one-off Regular Enquiries.​

Form submission errors: If a website submission fails validation or ET mapping, Admin receives alerts, and test enquiries in Staging are used to confirm mapping before live deployment.

Autoassign failure: When autoassign fails, the process is idempotent in the sense that re-running autoassign after configuration fixes either assigns a suitable User or leaves the record NPD with clear reasons; repeated attempts do not create duplicate clients.

Email send failures: When an email cannot be sent (e.g., Terms & Conditions email failures), the system shows an error (“Email could not be sent; please try again or contact support”) and logs the failure for Admin, while Users are advised to verify addresses manually.

Payment save errors: If payment insertion fails, a generic error is shown, and Admin receives technical details; the User can safely re-enter the payment once the issue is resolved without duplicating commissions, as totals can be cross-checked manually.​

Duplicate notifications / unread anomalies: Historic issues where third-party emails produced multiple notifications or persistent unread counts are treated as regressions; the rule is one notification per inbound email and consistent read/unread state across all views.

Manual recovery: Admin can correct ETs, reassign leads, adjust payments, reopen Closed/Eliminated records, or create new linked records when earlier steps are irrecoverably broken (e.g., wrong ET, wrong user, or an incomplete record).

Autoassign and record creation must complete fast enough that Users can see new Regular Enquiries in New Enquiries and Current Clients lists almost immediately; delays confuse Users about whether a lead exists.​

Email notifications (New Client Assigned, Client Response, etc.) are generated and sent within seconds to avoid Users missing time-sensitive contact windows (e.g., within 24 hours).

Background jobs for anonymisation, deletion, OOO summaries and NPD expiry run on schedules that balance performance with timely updates (e.g., daily or weekly summaries), but exact scheduling is implementation-level and outside the business logic page.

Lists (Current Clients, New Enquiries, Unread Emails, Daily Updates) use filters and pagination (e.g., 50 per page) to remain responsive even with large numbers of Regular Enquiries; redirect rules ensure Users are returned to the correct list after editing.​

ETs can be configured in Laravel with routing, pricing, commission defaults, recurring flags, reporting inclusion/exclusion, and country/profession constraints (e.g., NIF Application Portugal, Translation Service).

Website form endpoints are configurable (URL patterns, fields, confirmation texts) and must be explicitly mapped to ET and country; new or changed endpoints must be tested in Staging with sample enquiries.

OOO behaviour per User (reassign vs hold vs Admin list) is configurable via the Out-of-Office settings popup.​

Notification templates (New Client Assigned, Client Response, Payment Declared, We tried to reach you, survey emails) are centrally managed and updated as needed; only texts intentionally saved as templates appear in selection lists, avoiding clutter from one-off emails.

Recurring service behaviour (principal/delegatee flags, next payment dates, auto-accumulate) is configured at ET level and via the Recurring Service popup.​

Who gets notified:

• Assigned User: on new assignment, client email received, payment recorded, and sometimes on key status changes.

• Admin: on autoassign failure (NPD), system errors (assignment, email, payment), and for NPD/Expired leads and other special events.

• Client: on Terms & Conditions, We tried to reach you, Offer Emails, Direct Service or consultation offers where applicable, and survey invitations after completion.

When notifications are sent:

• Immediately on assignment, inbound emails, and recorded payments.

• On status changes to Completed/Closed (survey / feedback emails).

• On daily/weekly basis for OOO summaries and Expired/NPD summaries.

Content & deduplication:

• Inbound third-party emails (e.g., other lawyers) linked to a client record generate at most one notification per new email; duplicates or persistent unread notifications are considered defects.

• Some automated notifications include partial previews (e.g., first 100 characters of a client email) but require the User to click through to the client record for full content.​

Channels & usage:

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

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

Trello-derived rules were added to strengthen:

• Out-of-Office autoassign behaviour (no leads blocked on OOO users).

• NPD handling and assignment failure logging (NPD / Awaiting Assignment, with logged reasons).

• ET country-specific configuration (e.g., NIF Application Portugal must be PT-only).

• Email notification deduplication and third-party email read/unread consistency.

• Form submission URL mapping and staging validation.

Earlier versions of the business logic were higher-level and did not specify detailed UI behaviour (popups, badges, list redirect rules, blocking tasks); v2.0 introduces a field-level, step-by-step spec for all main flows, including Regular Enquiry.​

Some historic behaviours (e.g., recurring popup skipping after two payments, auto-creation of templates from one-off Offer Emails) are treated as legacy quirks and are explicitly corrected in the updated rules.

Regular Enquiries must respect GDPR by:

• Storing client data securely and only as long as necessary for service and legal/accounting retention.

• Providing mechanisms to exercise rights of access, rectification, erasure, restriction, portability and objection through a defined BackOffice GDPR workflow (receive request, verify identity, export, deliver, anonymise/delete, confirm).

• Keeping an audit trail of who accessed or modified client data via Updates Record.

For financial and tax compliance:

• Payments recorded in the system are used as the basis for invoicing and commission calculations and therefore must reflect actual receipts; retroactive corrections are possible but administratively complex.

• Documents such as invoices, tax forms (e.g., M210, IRNR, Renta) and proof of payments are often stored in Documents tab for evidence and future audits.

Terms & Conditions and legal information emails explicitly explain the relationship between Advocate Abroad (as a platform/marketing entity) and independent professionals, clarifying responsibility for professional advice and data handling.

Form submission & routing service: Accepts website form posts, maps submission URLs to ETs and countries, creates BackOffice client records, and triggers autoassign.

Autoassign engine: Applies ET/profession/country/availability rules and scoring, sets Assigned User and logs failures with NPD status on error.

Notification service: Generates outbound emails for assignment, client responses, payments, surveys, OOO summaries and errors; enforces one-notification-per-email rule.

Status & task engine: Enforces valid status transitions, triggers popups and reminders, and handles blocking tasks that gate access to other clients.​

Recurring service engine: For ETs flagged as recurring, manages principal/delegatee records, next payment dates, and “Complete Service” operations; used by some Regular Enquiries that become ongoing engagements.​

GDPR automation: Handles scheduled anonymisation and deletion based on status and age, and supports manual GDPR requests.

Guardrail: don’t give free substantive advice without written confirmation.
Users are repeatedly advised to send an Offer Email or consultation confirmation before providing detailed advice, to avoid disputes about promises and to evidence the client’s agreement to services and fees.

Guardrail: always record payments before closing.
Admin messages emphasise that Users should not mark a client as Completed or Closed without first entering all received payments in Payments; invoices are generated automatically, and corrections after the fact are cumbersome.

Guardrail: keep Updates Record and Next Progress Date current.
Admin often requests brief 1–2 line summaries and proper Next Progress Dates to ensure that clients are not forgotten and that long-running cases are monitored; leaving these blank is considered poor practice.

Guardrail: use the platform email and messaging system, not private channels.
Users are encouraged to send client emails from within the client record so that AA can monitor service quality and ensure auditability; adding their own email addresses as client emails is explicitly discouraged because it confuses system logic.

Guardrail: avoid “zombie” clients.
When there is no realistic prospect of work (no response for a long period, or client clearly not proceeding), Admin pushes Users to eliminate the enquiry rather than leave it indefinitely in Ongoing, both to keep statistics accurate and to trigger surveys where appropriate.

Guardrail: respect Out-of-Office and workload limits.
Users are blocked from receiving unlimited new Regular Enquiries if OOO, overloaded, or unresponsive; Admin may reassign or pause leads for such Users to protect client experience and network reliability.