The Status & Sub-Status Architecture

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

A. Main Statuses (Lifecycle & Visibility)

Controlled via the Status Dropdown in the Overview Tab. These determine which Dashboard List the client appears in.

B. Sub-Statuses (Action Audit Trail)

Automatically set by the "All Actions" workflow or System Events to track specific interactions.

• Here is a concise reference list using the sub‑status names visible in your screenshots, plus short descriptions inferred from the documented workflows.

  • Another Person Answered – Admin Reminder Sent
    Set by User in All Actions > No > Client Didn't Answer: A non‑client answered the client call scheduled by Admin; used to track that the admin‑level follow‑up step has been done.​

  • Another Person Answered – Email Sent
    Set by User in All Actions > No > Client Didn't Answer A follow‑up email has been sent to the client after someone else answered the phone; indicates phone contact failed but email contact is in progress.​

  • Change To Consultation Requested
    Set by User in All Actions > Yes > Change to Paid Consultation; The User has asked to switch from a full Direct Service/regular service to a paid consultation only (most likely because on reviewing the enquiry, the User feels that it is likely the client is seeking information, which the User is happy to oblige, but wants to get paid for it, so by switching to Paid Consultation, will be able to send an Offer Email of that type, inviting the client to a Paid Consultation on a specific date etc ​

  • Client Record Postponed
    Set by System when a lead is assigned, but the date scheduled for the client call is beyond 24 hours. This happens often when lead assigned late on Friday evening and the call is scheduled for Monday afternoon - the objective is to avoid the automated reminders/notifications that are sent when 24 hours has passed since assignment.​

  • Consultation Offer sent – Pending Client Response
    A Preliminary Email (service/fee/conditions) has been sent by Admin to the client and the next expected action is the client’s reply; system is effectively waiting for response.​

  • Meeting Confirmation Email Sent
    The User has sent the Offer Email to the client, specifying date and time of appointment; used to show that logistics are confirmed and the next step is the meeting itself.​

  • No Reply To Offer – Admin Reminder Sent
    Not sure - need to check this.​

  • No Reply To Offer – Professional Reminder Sent
    Client has not replied to any type of Offer Email and a reminder has been sent to the client to follow up; flags that the client has been nudged.​

  • Non‑Responsive – 24h Email Sent
    An initial “non‑responsive” follow‑up email has been sent roughly 24 hours after no reply; marks the first automated or semi‑automated chaser.​

  • Non‑Responsive – Admin Reminder Sent
    Client remains non‑responsive after earlier chasers and the admin has been reminded to review or decide whether to eliminate or change strategy.​

  • Offer Email Sent – Pending Reply
    A Direct Service or quotation email has been sent to the client and the system is now waiting for the client’s reply (feeds into the Direct Service follow‑up timings).​

  • On Recurring Payments
    The client is configured as a recurring service (e.g. monthly tax, accounting) and payments are expected/being tracked on a recurring basis.

  • Pending Anonymisation
    The record has met GDPR criteria for anonymisation (e.g. inactive for the configured period) and is queued to be anonymised but not yet processed.

  • Phone Out of Order – Admin Reminder Sent
    Phone contact has failed due to an invalid or unreachable number and admin has already been reminded to fix contact details or choose an alternative channel.​

  • Phone Out of Order – Email Sent
    After discovering the phone is out of order, an email has been sent to the client instead; indicates that email is now the active communication channel.​

  • Preparation – Pending User Review
    Preliminary email has been drafted and sent to User for review before being sent to the client - can be either a Paid Consultation or a Direct Service Offer Email. The client may edit the email/fees and then clicks 'Confirm' button at bottom of screen to indicate they are finished reviewing and appropriate notification sent to Admin to open and send email to the client.​

  • Requested Contact By Email
    Set by User: All Actions > Yes > Client Requested Email Contact - indicates that the Client has explicitly requested that contact be made by email (for preference or because phone is unreliable), and no telephone call may be scheduled. Requires Admin approval, and if agreed, status changed to 'Ongoing' so User can access email section. (This requires Admin authorisation since the lawyers would try to respond to almost all enquiries by email, and the outcome is poor)​

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, though in the case of Paid Consultations and some Direct Services it is possible the client record is never assigned to a User if a Preliminary Email can be sent without lawyer review and the client never responds.

When it is used

• Set when Admin converts an intake lead into a working file by:
  • Assigning to a specific User if a Regular Enquiry, or
  • Assigning as a Paid Consultation or Direct Service Enquiry (whether or not assigned to a Specific User)
• Used immediately after assignment (or NPD resolution) once Advocate Abroad considers the lead “taken in charge”, even if the client has not yet formally instructed.

How it differs from New Enquiry

• New Enquiry is a system‑level intake tag used only for freshly created, not‑yet‑worked leads and for the “New Enquiries” list; it mainly distinguishes brand‑new vs existing leads.
• Created marks the point where the lead becomes part of the lawyer’s real workload and enters the main lifecycle (Created → Ongoing / Waiting for Response / Direct Service / Hibernated / Eliminated).

Main behavioural effects

• Marks the transition from intake to live case: the record leaves the “Pending” list in Laravel and starts appearing in “Current Clients”.
• While status is Created, the assigned User can still correct the Enquiry Type (ET) via the Change Enquiry Type workflow; after moving to Ongoing, Hibernated, Completed or Closed, ET changes become more restricted and may require Admin.
• Created is the launch point for downstream flows: from here the User can start work and move to Ongoing, move to Waiting for Response, trigger a Direct Service offer, or move to Eliminated if the lead is clearly not proceeding.
• Until Status changes to Ongoing, the Emails section for direct email from BO remains restricted; incoming emails from the client’s registered address and/or a manually added payment can promote the case to Ongoing (exact promotion rules remain an open point).

Documented Sub‑status behaviour (Created)

Consultation Offer Sent – Pending Client Response

Context: Paid Consultation workflow.

Trigger: Admin treats the enquiry as suitable for Paid Consultation and sends a preliminary email explaining consultation terms and asking if the client wishes to proceed. If the client responds positively, Admin uses Convert to Lead. When the User then sends the Consultation Offer Email (date/time, format, benefits, fees) from the client record, the sub‑status becomes “Consultation Offer Sent – Pending Client Response”.

Effects: Main Status stays Created while the system waits on the client. If the client responds positively and/or payment is recorded, Status should move to Ongoing. If there is no response and no payment within the expected window, at least one reminder email is sent to the client; if the client still does not proceed, the case is moved to Eliminated so it is not chased indefinitely.

Open points: Exact reminder timing and whether the final move to Eliminated is automatic vs manual are not specified in the current docs.

Offer Email Sent – Pending Reply

Context: Regular (non‑consultation) enquiries in Created status.

Trigger: User sends an Offer Email (quotation/proposal) from the client record; the sub‑status becomes “Offer Email Sent – Pending Reply”.

Effects: Status remains Created; a positive reply and/or payment should lead to Ongoing. If the client does not respond and no payment is recorded, reminder email(s) are sent. If there is still no clear decision, the professional or Admin moves Status to Eliminated.

Open points: Reminder schedule and any automatic transitions are not detailed in the existing docs.

Change To Consultation Requested

Context: During a regular call, the lawyer realises the client mainly wants information or a second opinion.

Trigger: After explaining that they can only assist on a Paid Consultation basis, the User clicks Change To Consultation Requested (All Actions > Yes). This records that the User wishes to switch from a full case to a Paid Consultation only, usually because the engagement is more informational and the lawyer wants to ensure they are paid for their time.

Effects: Status stays Created while pending. A notification is sent to Admin to approve the switch. If Admin agrees, the enquiry format is changed to Paid Consultation, the User gains access to the consultation calendar and the Paid Consultation Offer Email, and the flow continues with “Consultation Offer Sent – Pending Client Response”.

Open points: No automatic timeout is documented if Admin does not respond to the request.

Preparation – Pending User Review

Context: Mainly Paid Consultation and Direct Service preliminary emails.

Trigger: Admin drafts a preliminary email (consultation or Direct Service) and sends it to the assigned User for review. Sub‑status becomes “Preparation – Pending User Review”.

Effects: Indicates that the draft exists and is awaiting the User’s confirmation or edits. Once the User reviews and clicks a confirmation button, a notification is sent back to Admin to send the final email to the client, and the sub‑status will typically change to one of the “Offer/Consultation Offer Sent – Pending …” sub‑statuses.

---

2. Contacted / Contacted family

This Status appears in some legacy descriptions as “User has sent the first email or made the first call”. However, it is not present in the v2.0 manual’s core status set and is rarely seen in current usage. The modern system uses Created, Ongoing and the Record Contact Results audit trail to capture first contact instead. It is therefore best treated as deprecated, with no new behaviour attached.

---

3. Ongoing

What it is / when used

• Main active‑work status; used once the client has instructed and the professional is carrying out work.
• Also used on delegatee records for recurring services, while the principal record is Hibernated.
• Appears in “Current Clients”; heavily used by lawyers, accountants and ASPs across all ETs.

Main behavioural effects

• Permits the User to access the client’s email address and to send emails from within BO; prior to Ongoing, email‑from‑BO is restricted.
• Included in workload/statistics for active clients; forms part of dashboards and reporting.
• Status transitions allowed: Waiting for Response, Completed, Closed (Admin only), Hibernated (for recurring), Eliminated/Rejected (Admin rules may apply).
• During Ongoing, Admin can create blocking Add Payment or similar tasks; these tasks must be completed (for example, payment entered) before the User can move on to completion/closure or freely work on other clients, effectively gating moves out of Ongoing until key actions are done.

Sub‑status behaviour: Call outcomes and non‑response

The Strategy Guide “Contact” step and Record Contact Results dialog drive a number of non‑responsive and phone‑problem Sub‑statuses.

Client Didn’t Answer / Phone number doesn’t work / Someone else answered

Trigger: In Record Contact Results, the User selects Did you speak with the client? = No and then chooses Call Difficulties. A second dialog offers:

• Client Didn’t Answer
• Phone number provided doesn’t work
• Someone else answered

Each choice:

• Sends an immediate email to the client, with text appropriate to the situation.
• Sets a Sub‑status:
  • Non‑Responsive – 24h/48h Email Sent (or similar) for “Client Didn’t Answer” – records that an initial non‑response chaser email has been sent.
  • Phone Out of Order – Email Sent for “Phone number provided doesn’t work”.
  • Another Person Answered – Email Sent for “Someone else answered”.
• Leaves main Status as Created or Ongoing depending on current state.

If the client still does not respond (by email, WhatsApp or other means) within roughly 48–72 hours after this first outcome email, a reminder email is sent (for example reflected in Sub‑statuses like Non‑Responsive – Admin Reminder Sent, Another Person Answered – Admin Reminder Sent, Phone Out of Order – Admin Reminder Sent). If there is still no response and no manual intervention by User or Admin in a further ~48 hours, the Status is automatically changed to Eliminated and a survey is sent. Sub‑statuses do not themselves block further contact; email capability remains governed by the main Status.

Requested Contact By Email

Trigger: During contact logging (typically All Actions > Yes), the User records that the client has explicitly requested communication by email only. Sub‑status becomes “Requested Contact By Email”.

Effects: Indicates that no phone call should be scheduled. Because handling all leads purely by email leads to poor outcomes, this change normally requires Admin approval. If Admin agrees, Status is set to Ongoing so the User can access the Emails section and respond via email only.

Overall non‑responsive behaviour

• There is no fully automatic “we tried to call you but could not reach you” email purely based on time. All non‑responsive emails described above are sent when the User actively records the outcome.
• Sub‑statuses such as “Non‑Responsive – 24h Email Sent”, “Non‑Responsive – Admin Reminder Sent”, “No Reply To Offer – Professional Reminder Sent”, etc., represent specific steps in this chaser sequence; the exact internal labels and precise timing are not fully specified in the documentation.

---

4. Waiting for Response

What it is / when used

• Intermediate status used when the professional is waiting on the client or a third party (documents, decisions, payments).
• Users move to this after sending a proposal or chasing the client and should set an appropriate Next Progress Date.

Main behavioural effects

• Appears in “Current Clients”.
• Next Progress Date + Waiting for Response determines inclusion in the “Expired Clients” list when the date passes.
• Typical transitions: back to Ongoing once the client responds, to Eliminated if the client does not respond after reminders, or to Hibernated for long gaps in recurring contexts.

Sub‑status behaviour

• Sub‑statuses such as “Offer Email Sent – Pending Reply” and “Consultation Offer Sent – Pending Client Response” effectively mean the system is waiting for a client decision or payment; depending on configuration they may sit under Created or Waiting for Response.
• “No Reply To Offer – Professional Reminder Sent” and “No Reply To Offer – Admin Reminder Sent” represent first and second reminder steps when there has been no response to an Offer/Direct Service email. Exact timers are not specified.

Open points

• Exact mapping of each “Offer / No Reply / Pending Client Response” Sub‑status to specific templates and timers is not fully documented.
• Whether these Sub‑statuses materially affect list visibility, beyond acting as audit markers and reminder triggers, is not clearly stated.

---

5. Direct Service

What it is / when used

• Logical sub‑status of Created Lead; applied when Admin sends a Direct Service Offer email using a Strategy Guide and template.
• Used for pre‑packaged services sent centrally by AA; follows a dedicated follow‑up automation.

Main behavioural effects

• Status set to Direct Service, isdirectservice flag true; Direct Service Offer email sent immediately.
• Automated follow‑ups:
  • Approximately 48h after send: first reminder email if no client response.
  • Approximately 7 days: final reminder email if still no response.
  • After approximately 14 days: no further automated emails; Admin notified that the Direct Service offer has expired.
• Changing Status from Direct Service to Eliminated immediately stops all Direct Service follow‑ups; isdirectservice flag remains true for reporting and for correctly interpreting the lead if the client returns later.

Sub‑status behaviour

• Follow‑up Sub‑statuses such as “No Reply To Offer – Professional Reminder Sent” and “No Reply To Offer – Admin Reminder Sent” mark the 48h and 7‑day reminder steps in the Direct Service sequence.
• They do not change core Status (which remains Direct Service) but record the follow‑up stage and prevent duplicate reminders.

Open points

• The exact label used at each follow‑up step and any additional constraints they impose are not explicitly documented.

---

6. Non‑Responsive / Non Responsive (Status)

Earlier documentation and your “lost” text describe Non Responsive as a Status where the system moves a file after repeated failed chasers, with chaser emails stopping at that point. The v2.0 manual, however, emphasises handling non‑response via Sub‑statuses and eventual movement to Eliminated, and does not list Non Responsive as a core Status.

Given this, the safest interpretation for the current system is:

• Non‑responsiveness is primarily tracked by Sub‑statuses and then a move to Eliminated.
• If a separate Non Responsive Status still exists in the database, it is likely legacy and should not be used for new records unless PM/dev explicitly confirm its modern role.

---

7. Hibernated

What it is / when used

• Status used mainly for recurring services as the “principal” record between cycles.
• Canonical example: annual IRNR or M210 – principal client record is Hibernated, delegatee record is Ongoing for each cycle.

Main behavioural effects

• Hibernated principals are excluded from “Current Clients” but remain visible in All Clients; they still drive recurring reminders when linked to delegatees.
• Users sometimes expect to move completed recurring clients to Hibernated; if Hibernated is unavailable in the dropdown, they may create duplicate records, which PM explicitly discourages.

Sub‑status behaviour

• Recurring ETs have a principal/delegatee model, monthly payment tracking and service‑termination rules. Sub‑status “On Recurring Payments” indicates that recurring payments are configured and expected.

Open points

• The exact logic for applying “On Recurring Payments” (for example, at setup vs after N payments) and its interaction with Hibernated vs Ongoing is not fully specified.

---

8. Completed

What it is / when used

• Status indicating the professional work is substantially finished and payment has been received.
• Set by the professional when the case is complete and all relevant payments have been recorded.

Main behavioural effects

• Changing to Completed triggers a payment confirmation popup which aggregates all payment records; if the system’s total does not match the User’s confirmation, the User receives a warning and should correct payments before confirming.
• Completed records:
  • Appear in Admin “Daily Updates” list for review.
  • Trigger a “Rate your lawyer” / client satisfaction survey.
  • Are candidates to be moved to Closed by Admin after verification.

Sub‑statuses & open points

• No Completed‑specific Sub‑statuses are named in the docs. Your earlier description that Completed implies both work finished and payment recorded is consistent with the popup behaviour.
• Any additional Sub‑statuses such as “Preparation – Pending User Review” between Ongoing and Completed are not documented and should be treated as open questions.

---

9. Closed

What it is / when used

• Administrative closure after Admin verifies that work and payments are complete, survey handling is done and intelliquote or other reporting has been updated.

Main behavioural effects

• Closed records are removed from “Current Clients” and other active worklists but remain in All Clients for historical reference.
• Closed marks the start of GDPR retention periods: anonymisation after roughly 6 months and deletion after roughly 12 months (configurable).

Sub‑status: Pending Anonymisation

• “Pending Anonymisation” indicates that a record has met GDPR criteria for anonymisation and is queued for anonymisation but not yet processed.

Open points

• Exact timing and implementation details of anonymisation jobs, and whether users can filter on “Pending Anonymisation”, are not described in detail.

---

10. Eliminated / Rejected / Unsuitable Enquiry

What it is / when used

• Eliminated: lead is dead – for example, price too high, client ghosted, user cannot assist or client explicitly chose another lawyer.
• Rejected: Admin‑level review state used to decide whether a survey should be sent or not after elimination.
• Unsuitable Enquiry: lead invalid (spam, wrong jurisdiction, clearly outside AA’s scope).

Main behavioural effects

• Moving to Eliminated always shows a “reason” popup; the reason is stored for reporting.
• Chaser emails and non‑responsive sequences stop.
• For Direct Service enquiries, Eliminated stops Direct Service follow‑ups but retains the isdirectservice flag.
• Eliminated/Rejected/Unsuitable are excluded from “Current Clients” and handled by GDPR anonymisation rules after the configured retention period.

Sub‑statuses & NPD linkage

• NPD – Client Not Proceeding is used when a client declines before proper assignment; Status becomes Eliminated but the NPD flag is kept for reporting.

Open points

• Whether “Rejected” and “Unsuitable Enquiry” are implemented as separate Status values or are represented by reasons within a single Eliminated status is not fully clear in the current docs.

---

11. NPD states

What they are / when used

• NPD – Awaiting Assignment: no user ever assigned, or current user removed; autoassign failed or manual unassignment.
• NPD – Unassigned: previously had a professional, who was removed (left network, ET change, manual override).
• NPD – Client Not Proceeding: client declined while in NPD; Status becomes Eliminated but the NPD flag is retained.

Main behavioural effects

• Orange NPD badge in all list views; red banner “No professional designated” in the client record.
• Admin can Assign User or Mark Not Proceeding from the NPD banner.
• NPD – Awaiting Assignment for 72h triggers an Expired badge and inclusion in “Expired Clients”; Status itself does not auto‑change.

---

12. Freeze client

What it is / when used

• Conceptual status/flag to pause reminders and status checks without marking the enquiry as eliminated, used when clients explicitly ask to “put things on hold”.

Open points

• Exact implementation (Status vs flag), permitted transitions and any Sub‑statuses are not detailed in the current sources.

---

13. “Meeting / Consultation / Preparation” Sub‑status group

• Preparation – Pending User Review – covered under Created.
• Meeting Confirmation Email Sent – indicates the User has sent an email confirming the date and time of a consultation/meeting; the next expected step is to hold the meeting.

These Sub‑statuses help distinguish between “offer sent”, “meeting scheduled” and “meeting held”, but the exact triggers for each (beyond sending specific templates) and any list‑level effects are not fully specified.

---

14. “Requested Contact By … / Client Record Postponed” Sub‑status group

• Requested Contact By Email – described above: the client explicitly requests email‑only contact; requires Admin approval to convert to email‑only Ongoing status.
• Client Record Postponed – used when a lead is assigned but the scheduled call is set beyond the standard 24‑hour response window (e.g. late Friday lead with Monday call). It suppresses “slow response” reminders so as not to penalise agreed call dates.

---

15. On Recurring Payments

• Indicates that the client is configured as a recurring service (monthly tax, accounting, etc.) and that recurring payments are expected and being tracked.
• Precise application rules (at setup vs after first cycles) and their interaction with Hibernated vs  Ongoing remain to be clarified in technical specs.