Skip to main content

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.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 limited'Benefits of a Consultation' instead of Strategy Guide optionsSelection 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 assigningrequesting 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 atwho has not yet provided this stage;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 showsresponds interestpositively into a PaidPreliminary Consultation,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 openswith link to the client record andin navigatesorder to move to the Strategynext Guidestage tab.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.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.progresses - is this correct?
  5. Phase 5: Scheduling on calendar
    1. The User and client agree the final date and time for the consultation,consultation usually- bythe emailUser exchange.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. TheWhen the User createsselects 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.
    3. TheThis will be updated if the User sendsor Client decide to change it - but only before the time of the scheduled appointment. After that, the User must select a confirmationnew emaildate includingand time in the final'My date/time,Meetings' section of the video link or phone details, and any preparation instructions (documents to bring, topics to discuss).BO.
    4. 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.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 auto-assignment fails for a Paid Consultation enquiry, the lead falls into an NPD or Awaiting Assignment state and must be manually assigned by Admin before the consultation process can proceed.
  • 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 or Teams)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.
Back to top