MWMS MCR

MWMS Lead Intake Qualification And Follow-Up Automation Framework

System: MWMS
Document Type: Framework
Authority Level: MCR Source Of Truth
Status: Draft For MCR
Version: v1.2
Primary Location: MCR
Future Operational Destination: AIBS Brain, Sales Brain, Automation Brain, Customer Brain, Data Brain, Client AIOS Systems
Parent Page: AIBS Brain
Owner: Martyn
Developer Boundary: Do Not Touch M’s Active Build Areas Unless Specifically Assigned
Source Of Truth: MCR
Last Reviewed: 2026-06-27
Source / Origin: MWMS Lead Intake Qualification And Follow-Up Automation Framework v1.1 + AI Automations By Jack AI Agents Block Covering Email Classification, Specialist Enquiry Agents, Lead Research, Conversation History, Draft Responses, Calendar Booking And Appointment Conversion
MWMS Classification: Lead Intake Automation Framework / AI Qualification System / Follow-Up Automation Framework / Client Acquisition AIOS Layer / Shared Inbox Classification Standard / Email Lead Response Standard
Primary Brain: AIBS Brain
Supporting Brains: Sales Brain, Automation Brain, Customer Brain, Data Brain, Content Brain, Risk Brain, Compliance Brain, SIT Brain, HeadOffice Brain, Project Manager Brain

Related Pages: MWMS n8n Operating And Deployment Standard, MWMS Client Intelligence Report Automation Framework, MWMS Client AI Interface Selection Framework, MWMS AI Dashboard Capability Framework, MWMS Supabase RAG And Vector Memory Framework, MWMS AI Agent Operations Core, MWMS AI Agent Memory And Context Framework, MWMS AI Tool Permission And Access Framework, MWMS AI Automation Security And Risk Checklist, MWMS Automation Build Planning Framework, MWMS Automation Client Demo And Handover Framework, MWMS Client Communication Automation Framework, MWMS AI Assisted Outreach And Sales Follow Up Automation Framework, MWMS Outbound Lead Enrichment And Cold Outreach Governance Framework, MWMS Source Visibility And Evidence Display Standard, MWMS AI Output Validation Standard, MWMS AI Employee Evaluation Scorecard Standard, MWMS Agent Loop Control Framework, MWMS Next Action Picker Standard, Project Manager Brain Canon

Source Evidence

The existing v1.1 framework defines lead intake automation across forms, chatbots, voice, WhatsApp, calendar and email sources, with payload cleaning, qualification, scoring, storage, personalized outputs, CRM routing, follow-up, human review, consent, data quality, voice response, appointment setting, post-call intelligence and learning loops.

The newly absorbed AI Agents block adds a deeper email-led operating layer covering:

  • shared inbox classification before qualification
  • hierarchical message classification
  • specialist enquiry-agent routing
  • current-thread and prior-conversation retrieval
  • approved company and offer context
  • source-traceable public business research
  • rapid but governed lead response
  • email draft and send autonomy levels
  • email-led appointment interpretation
  • live calendar checking
  • timezone and date resolution
  • confirmation and audit requirements
  • the principle that one unrestricted inbox agent should not control every message type

Purpose

The purpose of the MWMS Lead Intake Qualification And Follow-Up Automation Framework is to define how MWMS should design, govern, automate and package lead-intake systems that capture enquiries, classify their business meaning, clean the data, qualify the lead, store the result, generate personalized responses or reports and trigger appropriate follow-up actions.

This framework exists because lead generation is not valuable by itself.

A business does not need more messy form submissions, unclassified inbox messages, unanswered calls or disconnected appointment requests.

A business needs:

  • cleaner lead data
  • faster message classification
  • faster qualification
  • clearer lead priority
  • better follow-up
  • stronger personalization
  • better reporting
  • fewer missed opportunities
  • less manual administration
  • better conversion from enquiry to conversation
  • better routing between sales, support, partnerships, finance and onboarding
  • better continuity across message threads
  • safer appointment handling
  • clearer human review points
  • reliable records of what happened and why

The standard lead-intake pattern is:

Lead Or Message Received
↓
Source And Sender Validated
↓
Message Type Classified
↓
Correct Specialist Route Selected
↓
Payload Cleaned
↓
Known Context Loaded
↓
Lead Qualified
↓
Approved Response Or Output Prepared
↓
Appointment Or Next Action Proposed
↓
Human Approval Or Bounded Execution
↓
Lead And Outcome Stored
↓
Follow-Up Triggered
↓
Learning Captured

Core Principle

The core principle is:

Classify first, qualify second, act only within approved boundaries.

The system must first determine what kind of enquiry has arrived.

It must then determine whether the sender is a lead, customer, partner, supplier, employee, spam source or another category.

Only after that should the correct specialist workflow perform qualification, response, routing or appointment action.

A shared inbox is not permission for one general agent to act on everything.

Scope

This framework applies to:

  • website forms
  • landing-page forms
  • lead-magnet forms
  • Typeform
  • Tally
  • Google Forms
  • chatbots
  • website chat
  • email enquiries
  • shared inboxes
  • direct sales inboxes
  • sponsorship inboxes
  • partnership inboxes
  • customer-support inboxes
  • WhatsApp
  • SMS
  • voice calls
  • AI receptionists
  • outbound rapid response
  • missed-call recovery
  • calendar booking
  • client portals
  • custom intake applications
  • referral submissions
  • campaign responses
  • personalized lead reports
  • qualification workflows
  • sales follow-up
  • appointment preparation
  • appointment booking within approved boundaries
  • post-call and post-message intelligence
  • CRM routing
  • dashboard reporting
  • Project Manager Brain task creation

This framework governs:

  • source validation
  • sender validation
  • classification
  • data cleaning
  • context loading
  • qualification
  • scoring
  • lead storage
  • response generation
  • report generation
  • follow-up routing
  • appointment logic
  • human approval
  • consent
  • privacy
  • audit trails
  • learning loops

This framework does not authorize:

  • unrestricted inbox control
  • unreviewed financial commitments
  • unreviewed legal commitments
  • unreviewed pricing changes
  • fabricated lead research
  • sensitive personal profiling
  • autonomous appointment booking without approved boundaries
  • autonomous sending without approved boundaries
  • hidden customer-state changes
  • task creation outside the approved Project Manager Brain source of truth
  • lead decisions based only on model confidence

Lead Intake Operating Layers

The framework contains fourteen operating layers:

  1. Intake Source Layer
  2. Sender And Source Validation Layer
  3. Message Classification Layer
  4. Specialist Enquiry Routing Layer
  5. Payload Cleaning Layer
  6. Lead Context Layer
  7. Qualification Layer
  8. Personalized Output Layer
  9. Response And Follow-Up Layer
  10. Appointment Layer
  11. Storage And CRM Layer
  12. Human Review And Escalation Layer
  13. Outcome And Reporting Layer
  14. Learning And Improvement Layer
  15. Intake Source Layer

Lead capture may occur through:

  • GoHighLevel form
  • website form
  • landing-page form
  • lead-magnet form
  • Typeform
  • Tally
  • Google Forms
  • chatbot
  • WhatsApp
  • voice agent
  • calendar booking
  • email enquiry
  • client portal form
  • custom app intake form
  • referral
  • social message
  • webinar registration
  • event submission
  • missed call

Every source should preserve:

Source Type:

Source System:

Campaign:

Landing Page:

Form Or Inbox:

Original Message Or Payload:

Received Date:

Received Time:

Sender Identity:

Consent State:

Tracking Data:

Client Or Business:

Rule

The original intake record must be preserved before AI transformation.

  1. Sender And Source Validation Layer

Before classification or action, validate:

  • sender address or phone number
  • message integrity
  • client or business destination
  • source system
  • duplicate status
  • spam status
  • consent status where relevant
  • attachment status
  • malicious-link or file risk where relevant
  • whether the sender is already known
  • whether the message belongs to an existing thread

Possible Sender Types

  • New Lead
  • Existing Lead
  • Existing Customer
  • Existing Client
  • Partner
  • Sponsor
  • Supplier
  • Employee
  • Applicant
  • Media
  • Unknown
  • Spam
  • Malicious

Rule

The system must not assume that every inbound message is a sales lead.

  1. Message Classification Layer

The first classification asks:

What kind of message is this?

This is different from lead qualification.

Recommended First-Level Categories

  • Sales Enquiry
  • Pricing Request
  • Appointment Request
  • Sponsorship
  • Partnership
  • Customer Support
  • Existing Client
  • Finance
  • Compliance
  • Media
  • Supplier
  • Internal
  • Recruitment
  • Low Priority
  • Spam
  • Unknown

Classification Record

Message ID:

Thread ID:

Sender:

Recipient Inbox:

First-Level Category:

Second-Level Category:

Confidence:

Reason:

Evidence:

Specialist Route:

Human Review Required:

Classification Date:

Classifier Version:

Rule

The classifier should produce a category, reason and confidence.

It should not silently route an uncertain message as though classification were certain.

Unknown And Low-Confidence Rule

Unknown or low-confidence messages should:

  • request clarification
  • enter a human-review queue
  • route to a general triage employee
  • remain unexecuted

They must not be forced into a sales or support route.

  1. Hierarchical Classification

Where too many similar categories exist, use hierarchical classification.

Example First Level

Sales

Example Second Level

  • Information Request
  • Pricing Request
  • Call Request
  • Objection
  • Follow-Up
  • Existing Opportunity
  • Proposal Request
  • Procurement Question
  • Unqualified Enquiry

Example First Level

Support

Example Second Level

  • Access Problem
  • Technical Problem
  • Billing Problem
  • How-To Question
  • Complaint
  • Cancellation
  • Urgent Incident

Example First Level

Partnership

Example Second Level

  • Referral Partnership
  • Content Collaboration
  • Technology Partnership
  • Agency Partnership
  • Affiliate Partnership
  • Event Partnership

Rule

A small first-level classifier followed by a narrow specialist classifier is preferred over one overloaded classifier with too many similar categories.

  1. Specialist Enquiry Routing Layer

After classification, invoke only the specialist workflow required for that message type.

Possible Specialist Routes

  • Sales Enquiry Agent
  • Pricing Enquiry Agent
  • Appointment Request Agent
  • Sponsorship Agent
  • Partnership Agent
  • Customer Support Agent
  • Existing Client Agent
  • Finance Agent
  • Compliance Agent
  • Media Agent
  • Human Triage Agent

Each specialist should receive only:

  • the relevant message
  • the relevant thread
  • the relevant customer or lead record
  • approved company knowledge
  • approved tools
  • the minimum required permissions

One Unrestricted Inbox Agent Rule

MWMS should not use one unrestricted agent to:

  • read every inbox
  • classify every message
  • access every customer record
  • research every sender
  • send every response
  • book every meeting
  • change every CRM stage

Classification, specialist action and approval should remain separable.

  1. Payload Cleaning Layer

Incoming lead data may be:

  • incomplete
  • malformed
  • duplicated
  • inconsistent
  • wrongly formatted
  • missing key fields
  • contaminated by spam
  • copied from previous fields
  • entered in the wrong timezone
  • entered with ambiguous dates
  • written in free text

Payload cleaning should include:

  • trim unnecessary whitespace
  • normalize names
  • normalize email
  • normalize phone
  • normalize country
  • normalize timezone
  • normalize date format
  • identify missing fields
  • identify duplicate records
  • identify contradictions
  • preserve original values
  • record corrected values
  • record correction source

Payload Cleaning Record

Field:

Original Value:

Cleaned Value:

Correction Method:

Confidence:

Human Confirmation Required:

Rule

Bad data should be flagged before automation acts on it.

  1. Lead Context Layer

The system should use known data before asking the lead to repeat information.

Known context may include:

  • lead name
  • email
  • phone
  • company
  • role
  • source
  • campaign
  • requested service
  • known budget
  • location
  • timezone
  • prior interaction
  • previous form answers
  • current pipeline stage
  • qualification status
  • prior objections
  • prior proposed times
  • prior commitments
  • consent state
  • current owner
  • relevant offer
  • client-specific rules

Lead Response Context Packet

A message-led enquiry should use a formal context packet.

Lead Identity:

Company:

Role:

Current Message:

Subject:

Thread ID:

Previous Conversation:

Original Source:

Campaign:

Known Need:

Known Budget:

Known Timing:

Pipeline Stage:

Qualification Status:

Previous Objections:

Previous Commitments:

Approved Offer Context:

Approved Company Context:

Relevant Public Business Research:

Research Sources:

Consent Status:

Available Next Actions:

Calendar Availability:

Response Objective:

Communication Voice:

Risk Flags:

Human Review Requirement:

Rule

The response should be based on the full relevant context packet, not only the newest message.

  1. Conversation Thread Continuity

The system must retrieve and interpret the relevant conversation thread where available.

Thread continuity should identify:

  • latest message
  • earlier questions
  • answered questions
  • unresolved questions
  • previous commitments
  • previous proposed times
  • agreed next steps
  • objections
  • changes in intent
  • latest authoritative instruction
  • attachments
  • quoted content
  • automated notices
  • stale or superseded information

Thread Continuity Rules

The agent must not:

  • ask for information already supplied
  • contradict an earlier commitment
  • offer a time already rejected
  • repeat a generic introduction
  • treat quoted text as the newest instruction
  • ignore a cancellation
  • ignore a do-not-contact request
  • use stale information over a newer correction

Thread Summary Record

Thread ID:

Current Intent:

Resolved Items:

Unresolved Items:

Previous Commitments:

Latest Proposed Action:

Latest Proposed Time:

Lead Sentiment:

Risk:

Next Valid Action:

  1. Public Business Research Boundary

Relevant public business research may support lead response.

Permitted Research

  • company website
  • public company description
  • public professional role
  • official business registration where appropriate
  • official product or service information
  • public business news
  • public company size or market information where relevant
  • public technology or platform use where lawfully available
  • source-traceable business context

Prohibited Or Restricted Research

  • unnecessary personal profiling
  • sensitive personal data
  • private family information
  • health information
  • political beliefs
  • religion
  • personal financial information
  • unverified social rumours
  • guessed income
  • guessed personal motives
  • hidden surveillance
  • data obtained through prohibited sources

Research Rules

  • research must serve the enquiry
  • sources must be preserved
  • weak sources must not be treated as fact
  • absence of evidence must not be converted into a claim
  • public research must not override lead-provided information without review
  • irrelevant personal information must not be retained
  1. Qualification Layer

After message classification and context loading, determine whether the lead is suitable for the intended offer or route.

Qualification may consider:

  • need
  • fit
  • timing
  • budget
  • authority
  • location
  • service area
  • urgency
  • problem severity
  • compliance fit
  • client capacity
  • offer fit
  • readiness
  • existing relationship
  • requested outcome

Qualification Outcomes

  • Qualified
  • Qualified With Conditions
  • Needs More Information
  • Needs Human Review
  • Nurture
  • Existing Customer Route
  • Partner Route
  • Support Route
  • Unqualified
  • Spam
  • Reject

Qualification Output

Qualification Status:

Reason:

Score If Used:

Missing Information:

Next Action:

Recommended Owner:

Follow-Up Priority:

Risk Flags:

Confidence:

Rule

A lead is not qualified unless the reason is known.

AI Qualification Boundary

AI may:

  • classify
  • compare rules
  • identify missing information
  • recommend status
  • recommend priority
  • recommend next action

AI must not silently control:

  • high-value sales decisions
  • final pricing
  • custom scope
  • legal commitments
  • credit decisions
  • regulated advice
  • rejection where discrimination risk exists
  1. Voice Lead Response And Appointment Setting Layer

Voice intake may support:

  • inbound reception
  • outbound rapid lead response
  • form-triggered callback
  • missed-call recovery
  • appointment request
  • qualification
  • resource routing
  • human escalation

Known-Data-First Voice Rule

Before a voice call, load approved lead context.

The agent should not ask the caller to repeat data that is already known unless confirmation is necessary.

Dynamic Voice Context Record

Variable Name:

Value:

Source:

Capture Date:

Confidence:

Sensitivity Level:

Confirmation Required:

Permitted Use:

Corrected Value:

Correction Date:

Correction Source:

Rule

Dynamic context must remain traceable, reviewable and limited to the purpose of the call.

Voice Qualification Branching

Possible outcomes:

  • Qualified For Meeting
  • Needs More Information
  • Route To Human
  • Route To Educational Resource
  • Route To Support
  • Route To Existing Client Team
  • Not Qualified
  • Do Not Contact

Voice Tool Permissions

A voice agent may receive only the tools required for its role.

Possible tools:

  • contact lookup
  • CRM record lookup
  • qualification record update
  • approved knowledge retrieval
  • calendar availability check
  • appointment preparation
  • appointment booking where authorized
  • SMS confirmation
  • email confirmation
  • human transfer
  • call termination

Tool Permission Record

Tool Name:

Purpose:

Read Or Write:

Allowed Action:

Prohibited Action:

Approval Requirement:

Client Boundary:

Audit Requirement:

Rule

Do not grant every available function simply because the platform supports it.

Call Duration And Failure Controls

Every voice workflow should define:

  • maximum call duration
  • silence timeout
  • ring duration
  • retry count
  • no-answer handling
  • voicemail policy
  • repeated-call suppression
  • maximum cost
  • termination conditions
  • failure escalation
  • human-transfer condition
  • unsupported-request handling

Rule

A voice agent must be able to end the call safely.

It must not remain connected, repeatedly call or continue after a clear refusal or do-not-contact request.

  1. Speed-To-Lead Principle

High-intent enquiries should receive prompt and relevant follow-up while the enquiry is fresh.

Speed should support:

  • better acknowledgement
  • faster qualification
  • reduced missed opportunities
  • clearer next steps
  • better customer experience

Speed must not override:

  • permission
  • local calling rules
  • quiet hours
  • suppression status
  • human-review requirements
  • data accuracy
  • thread continuity
  • correct classification
  • tool permissions
  • appointment safeguards

Response-Speed Standard

The system should define:

Target Acknowledgement Time:

Target Qualification Time:

Urgent Alert Threshold:

After-Hours Policy:

Draft Or Send Rule:

Human Escalation Threshold:

Stale Lead Threshold:

Rule

Respond as quickly as accuracy, context and approval allow.

  1. Personalized Output Layer

Personalized output may include:

  • audit report
  • lead-magnet report
  • consultation-preparation summary
  • personalized recommendation
  • qualification summary
  • service-fit report
  • PDF report
  • email summary
  • dashboard card
  • sales-preparation brief
  • onboarding brief

Personalization must be based on:

  • lead-provided data
  • approved service knowledge
  • approved offer context
  • validated business rules
  • verified public business research
  • approved templates

It must not be based on invented assumptions.

Personalized Report Components

  • lead summary
  • problem diagnosis
  • opportunity analysis
  • recommended next steps
  • readiness score
  • improvement areas
  • risk notes
  • CTA
  • booking link

Report Risk

Avoid:

  • guaranteed results
  • unsupported financial claims
  • medical advice
  • legal advice
  • financial advice
  • false diagnosis
  • fake personalization
  • invented facts
  • fabricated business research

PDF Generation Rule

Before generating or sending a PDF:

  • confirm lead identity
  • confirm data fields
  • confirm report template
  • confirm no sensitive wrong data
  • confirm claims are safe
  • confirm recipient
  • confirm status
  • log report creation
  1. Email Response And Follow-Up Layer

Email follow-up should match:

  • message classification
  • lead qualification
  • relationship stage
  • current thread
  • requested action
  • consent
  • urgency
  • approved response boundary

Qualified Lead Email

Should include:

  • acknowledgement
  • relevant personalized insight
  • direct answer where possible
  • report link or attachment where approved
  • booking link or meeting proposal
  • clear next step
  • human contact where relevant

Needs Review Email

Should include:

  • acknowledgement
  • expectation setting
  • request for missing information
  • timeline for response
  • no unsupported commitment

Unqualified Or Nurture Email

Should include:

  • polite response
  • educational resource
  • alternate next step
  • soft nurture path
  • no false promise

Existing Customer Email

Should:

  • identify the existing relationship
  • route to the correct customer or account owner
  • preserve thread continuity
  • avoid treating the customer as a new lead

Email Action Autonomy Levels

Level 1 — Recommend Reply

The system recommends what should be said.

Level 2 — Create Draft

The system creates a reviewable draft.

Level 3 — Prepare Reply For Approval

The system prepares the final response with recipients, subject, thread and attachments, but does not send.

Level 4 — Send After Approval

The system sends only after a valid approval event.

Level 5 — Bounded Autonomous Reply

The system may send without case-by-case approval only inside a narrow approved boundary.

Bounded Autonomous Reply Requirements

  • approved message category
  • approved sender type
  • approved response purpose
  • approved claims
  • approved offer
  • approved template boundary
  • no pricing change
  • no legal commitment
  • no custom commercial promise
  • no sensitive complaint
  • no disputed account status
  • no uncertain identity
  • complete logging
  • stop conditions
  • human escalation
  • periodic review
  • revocation

Default Email Rule

The default action is Draft or Prepare For Approval.

Automatic sending is not the default.

  1. Draft Review Checklist

Before an email is approved or sent, confirm:

  • correct recipient
  • correct sender identity
  • correct lead
  • correct company
  • correct thread
  • correct enquiry type
  • correct qualification state
  • correct offer
  • correct pricing status
  • accurate public research
  • accurate calendar information
  • no fabricated details
  • no unsupported claim
  • no accidental commitment
  • no duplicated question
  • no contradiction with prior messages
  • appropriate tone
  • approved voice
  • CTA fit
  • correct signature
  • correct attachments
  • correct source links
  • consent or communication basis
  • approval status
  1. Appointment Layer

Appointment handling may begin from:

  • form request
  • calendar request
  • email request
  • voice request
  • chatbot request
  • WhatsApp request
  • sales recommendation

Appointment Readiness Requirements

Before preparing or creating an appointment, resolve:

  • lead identity
  • attendee email
  • meeting purpose
  • date
  • year
  • time
  • timezone
  • duration
  • calendar
  • working hours
  • buffer
  • availability
  • conflict status
  • meeting type
  • location or meeting link
  • required attendees
  • approval status
  • confirmation method

Email-Led Appointment Workflow

Email Appointment Request
↓
Identify Proposed Date And Time
↓
Resolve Timezone
↓
Resolve Year And Date Ambiguity
↓
Verify Attendee Identity
↓
Read Relevant Thread
↓
Check Live Calendar
↓
Apply Working Hours And Buffers
↓
Prepare Approved Meeting Option
↓
Human Approval Or Bounded Execution
↓
Create Event
↓
Send Confirmation
↓
Store Message And Event ID
↓
Create Follow-Up Record

Ambiguous Date Rule

If the sender says:

  • Friday
  • next week
  • tomorrow
  • the 12th
  • 5 pm

the system must resolve the date, year and timezone before execution.

It must not guess when ambiguity could create a wrong appointment.

Duplicate Booking Prevention

Before creating an event, check:

  • existing event ID
  • thread history
  • matching attendee
  • matching time
  • matching purpose
  • previous booking result
  • cancellation or reschedule status

False Availability Rule

The system must not offer a time unless it has checked the live approved calendar or received verified availability.

Appointment Action Levels

  • Recommend Time
  • Draft Proposed Times
  • Prepare Calendar Event
  • Create After Approval
  • Bounded Autonomous Booking

Bounded Autonomous Booking Requirements

  • approved meeting type
  • approved calendar
  • approved duration
  • approved working hours
  • approved buffers
  • valid attendee identity
  • valid timezone
  • no conflict
  • duplicate protection
  • complete logging
  • cancellation and reschedule rules
  • human escalation
  • revocation
  1. Follow-Up Sequence Layer

Follow-up may include:

  • immediate confirmation email
  • personalized report email
  • sales notification
  • calendar booking prompt
  • nurture email sequence
  • SMS or WhatsApp follow-up
  • internal task
  • CRM pipeline move
  • reminder if no response
  • unqualified-lead nurture path
  • appointment reminder
  • no-show recovery
  • post-call follow-up
  • post-meeting follow-up

Follow-Up Rule

Follow-up should match:

  • qualification status
  • message type
  • lead stage
  • consent
  • previous response
  • appointment state
  • human owner
  • business priority

Do not send the same follow-up to every lead when better context exists.

Stale Lead Handling

A stale lead may require:

  • reminder
  • human review
  • lower-intensity follow-up
  • nurture route
  • requalification
  • closure
  • suppression

The system should define how many attempts are permitted and when follow-up must stop.

  1. Sales Task Creation

Qualified leads should create an approved next action.

Possible tasks:

  • call lead
  • review report
  • send proposal
  • book consultation
  • check missing information
  • review high-risk lead
  • assign to sales representative
  • prepare custom pitch
  • route to human
  • confirm appointment
  • investigate qualification conflict
  • review public business research
  • resolve compliance issue

Project Manager Brain Rule

AI-created tasks must route into the approved Project Manager Brain or designated task source of truth.

Email, Notion, spreadsheets and chat tools must not become competing task systems unless explicitly approved.

Task Record

Task Title:

Lead ID:

Thread ID:

Project:

Workstream:

Task Type:

Owner:

Priority:

Due Date:

Next Valid Action:

Qualification Status:

Reason:

Source:

Appointment Status:

Risk:

Approval:

  1. Lead Storage And CRM Layer

If a lead is worth following up, it is worth storing properly.

Lead storage should include:

  • lead name
  • email
  • phone
  • company
  • role
  • source
  • campaign
  • original message
  • thread ID
  • form answers
  • first-level classification
  • second-level classification
  • qualification result
  • score
  • reason
  • follow-up status
  • owner
  • created date
  • last updated
  • consent state
  • notes
  • report link
  • appointment status
  • event ID
  • research references
  • risk flags
  • human-review status

Possible destinations:

  • Supabase
  • GoHighLevel
  • HubSpot
  • client CRM
  • AIBS client database
  • MWMS dashboard

Temporary tools such as Airtable or Google Sheets may be used for testing.

They must not silently replace the approved operational source of truth.

CRM Routing Rule

CRM records should show:

  • what the message was
  • how it was classified
  • why the lead was qualified
  • what response occurred
  • what appointment action occurred
  • what human approval occurred
  • what the next action is
  1. Post-Call And Post-Message Intelligence

A communication record may include:

Communication ID:

Direction:

Channel:

Lead ID:

Thread ID:

Source:

Start Time:

End Time:

Duration:

Cost:

Message Or Transcript:

Recording Reference:

Recording Consent Status:

Summary:

Classification Result:

Qualification Result:

Qualification Reason:

Appointment Result:

Calendar Event ID:

Objections:

Sentiment:

Primary Need:

Corrected Data:

Next Action:

Follow-Up Owner:

Follow-Up Due Date:

Compliance Flags:

Human Review Status:

Outcome:

Error Status:

Rule

Records should distinguish:

  • observed facts
  • lead statements
  • AI interpretation
  • inferred sentiment
  • public research
  • business-system state
  1. Recording And Transcript Governance

Voice workflows may create recordings and transcripts.

Before recording or retaining call content, confirm:

  • legal basis
  • notice requirements
  • consent requirements
  • retention period
  • access permissions
  • client boundary
  • deletion process
  • sensitive-data handling
  • recording ownership
  • transcript accuracy limits
  • storage destination
  • encryption or access controls
  • third-party processing

Recording and transcript storage are governed data operations.

They must not be treated as default permissions.

  1. Human Review And Escalation Layer

Human review is required when:

  • AI confidence is low
  • message classification is uncertain
  • lead is high value
  • pricing or scope is involved
  • compliance risk exists
  • lead is borderline
  • follow-up contains sensitive claims
  • report makes strong recommendations
  • workflow is new
  • client-facing output is untested
  • complaint requires authority
  • sender identity is uncertain
  • public research conflicts
  • thread commitments conflict
  • calendar date is ambiguous
  • timezone is uncertain
  • financial commitment is requested
  • legal commitment is requested
  • customer relationship is sensitive
  • sender requests a human
  • emergency or severe distress is present

Sensitive And Emergency Escalation

The system must stop or escalate when communication involves:

  • emergency
  • threat
  • severe distress
  • medical urgency
  • legal dispute
  • payment dispute requiring authority
  • vulnerable person
  • identity uncertainty
  • serious complaint
  • request outside approved scope
  • request for human assistance

Rule

The system must not trap a caller or sender inside automation when human judgement is required.

  1. Compliance And Consent Layer

Lead intake workflows may collect personal and business data.

MWMS should consider:

  • consent to contact
  • privacy notice
  • data storage
  • unsubscribe mechanism
  • marketing-email rules
  • SMS or WhatsApp permission
  • data retention
  • calling permission
  • calling hours
  • recording notice
  • recording consent
  • transcript retention
  • voice disclosure
  • human escalation
  • access and deletion requests
  • third-party tool data handling
  • client-specific privacy policy
  • cross-border data transfer
  • public research retention
  • sensitive information minimization

Rule

The communication channel, jurisdiction, client context and intended use determine the required controls.

  1. Tool Permission Requirements

Lead-intake systems may touch:

  • Supabase
  • GoHighLevel
  • HubSpot
  • Gmail
  • Outlook
  • Google Calendar
  • Microsoft Calendar
  • n8n
  • Make
  • CRM APIs
  • email platforms
  • SMS and WhatsApp tools
  • voice systems
  • AI models
  • research tools
  • document generators
  • dashboards
  • Project Manager Brain

Every tool must define:

Tool:

Purpose:

Read Or Write:

Permitted Data:

Prohibited Data:

Permitted Action:

Prohibited Action:

Approval Requirement:

Autonomy Level:

Client Boundary:

Logging:

Revocation:

Rule

Every tool in the lead workflow must have a permission purpose.

  1. Dashboard Integration

Lead dashboards may show:

  • new messages
  • classified messages
  • unknown messages
  • new leads
  • qualified leads
  • needs review
  • unqualified leads
  • lead source
  • message category
  • response time
  • response status
  • conversion rate
  • pending follow-ups
  • reports generated
  • appointments proposed
  • appointments booked
  • no-shows
  • sales owner
  • next action
  • errors
  • human-review queue

Dashboard Rule

Lead dashboards should help humans act faster, not merely count submissions.

  1. Outcome Logging

The workflow should log:

  • intake received
  • source validated
  • sender identified
  • classification result
  • classification confidence
  • specialist route
  • payload cleaned
  • context loaded
  • research performed
  • qualification result
  • report created
  • email drafted
  • email approved
  • email sent
  • appointment proposed
  • calendar checked
  • appointment created
  • task created
  • human review required
  • error
  • lead status
  • next action
  • final outcome

Rule

Lead workflows must create an audit trail.

  1. Learning And Improvement Layer

Over time, MWMS should learn:

  • which lead sources produce quality
  • which message types convert
  • which form questions predict conversion
  • which classification categories create confusion
  • which specialist routes perform best
  • which public research is useful
  • which reports convert
  • which follow-ups work
  • which qualification rules are too strict
  • which leads become clients
  • which leads waste time
  • which answers signal intent
  • which subject lines receive replies
  • which response times matter
  • which appointment proposals convert
  • which no-show patterns occur
  • which autonomy levels create risk
  • which human corrections repeat

Improvement Loop

Communication Record
↓
Outcome Review
↓
Friction Or Failure Identified
↓
Improvement Recommendation
↓
Human Approval
↓
Controlled Prompt Or Process Update
↓
Retest
↓
Deployment
↓
Monitoring

Rule

The live system must not automatically rewrite its own instructions from one communication.

  1. Standard Lead Schema

Lead ID:

Client ID:

Source Type:

Source System:

Campaign:

Received Date:

Received Time:

Lead Name:

Email:

Phone:

Company:

Role:

Country:

Timezone:

Original Payload:

Original Message:

Thread ID:

First-Level Classification:

Second-Level Classification:

Classification Confidence:

Classification Reason:

Specialist Route:

Known Need:

Budget:

Timing:

Authority:

Location Fit:

Offer Fit:

Qualification Status:

Qualification Score:

Qualification Reason:

Missing Information:

Consent Status:

Do Not Contact Status:

Public Research References:

Previous Commitments:

Current Owner:

Follow-Up Priority:

Next Valid Action:

Appointment Status:

Calendar Event ID:

Report Link:

Human Review Status:

Risk Flags:

Created Date:

Updated Date:

Final Outcome:

  1. Lead Intake Workflow

The standard MWMS workflow is:

Lead Or Message Captured
↓
Original Payload Preserved
↓
Sender And Source Validated
↓
Duplicate And Spam Check
↓
Message Type Classified
↓
Unknown Or Low Confidence Routed To Review
↓
Specialist Workflow Selected
↓
Payload Cleaned
↓
Relevant Thread Retrieved
↓
Lead Response Context Packet Built
↓
Public Business Research Performed Where Justified
↓
Lead Qualified
↓
Approved Output Or Response Prepared
↓
Draft Review Completed
↓
Appointment Proposed Where Relevant
↓
Calendar And Timezone Validated
↓
Approval Or Bounded Execution
↓
Lead And Communication Stored
↓
Follow-Up Triggered
↓
Sales Task Created
↓
Outcome Logged
↓
Learning Captured

  1. Launch Readiness Checklist

Before deployment, confirm:

Strategy

  • lead-intake purpose is clear
  • supported channels are defined
  • supported message categories are defined
  • qualification goals are defined
  • business outcome is defined

Classification

  • first-level categories are tested
  • second-level categories are tested
  • unknown route exists
  • low-confidence route exists
  • specialist routes exist
  • classification reasons are logged

Context

  • relevant thread retrieval works
  • prior commitments are preserved
  • known-data-first behaviour works
  • context packet fields are defined
  • stale context is excluded
  • client isolation is confirmed

Research

  • public business research is bounded
  • sources are preserved
  • prohibited profiling is blocked
  • weak evidence triggers review
  • retention rules are defined

Qualification

  • qualification rules are defined
  • reasons are required
  • missing-information path exists
  • high-value review exists
  • compliance review exists

Email

  • autonomy level is defined
  • default draft behaviour is defined
  • approval flow works
  • bounded autonomous cases are explicit
  • draft-review checklist is active
  • thread continuity is tested
  • recipient and attachment validation works

Voice

  • consent and calling rules are defined
  • call duration limit exists
  • retry limit exists
  • do-not-contact handling works
  • human transfer works
  • emergency escalation works
  • call termination works

Calendar

  • live calendar read works
  • timezone handling is tested
  • year and date ambiguity is tested
  • working hours are configured
  • buffers are configured
  • duplicate prevention works
  • confirmation works
  • cancellation and rescheduling rules exist

Data

  • original payload is preserved
  • cleaned values are traceable
  • CRM fields are mapped
  • source of truth is defined
  • audit logging works
  • retention is defined

Tasks

  • Project Manager Brain routing works
  • task ownership is defined
  • next valid action is stored
  • duplicate task prevention works

Safety

  • permissions are recorded
  • sensitive actions require approval
  • client boundaries are tested
  • revocation exists
  • shutdown exists
  • failure alerts exist

Learning

  • outcomes are captured
  • human corrections are captured
  • improvement approval exists
  • retesting is required
  1. Failure Modes

Failure Mode 1: Message Misclassified

A sales enquiry is routed as support or spam.

Correction:

  • require reason and confidence
  • use hierarchical classification
  • route low confidence to review

Failure Mode 2: One Agent Controls The Entire Inbox

One agent reads and acts across unrelated business categories.

Correction:

  • classify first
  • route to specialists
  • restrict tools and context

Failure Mode 3: Lead Qualified Before Message Type Is Known

A support request is incorrectly treated as a sales opportunity.

Correction:

  • separate message classification from lead qualification

Failure Mode 4: Thread History Ignored

The response asks for information already supplied or contradicts an earlier commitment.

Correction:

  • retrieve relevant thread
  • summarize unresolved items
  • preserve previous commitments

Failure Mode 5: Quoted Text Treated As New Instruction

The system responds to an older quoted message.

Correction:

  • identify message boundaries
  • select the latest authoritative instruction

Failure Mode 6: Fabricated Lead Research

The response includes invented company or role information.

Correction:

  • preserve sources
  • distinguish fact from inference
  • remove unsupported details

Failure Mode 7: Excessive Personal Profiling

The system collects irrelevant private information.

Correction:

  • restrict research to relevant public business context
  • minimize retained data

Failure Mode 8: Fast But Wrong Response

The system responds immediately with incorrect context.

Correction:

  • speed must follow validation
  • require draft review where needed

Failure Mode 9: Unapproved Email Sent

The system sends a response outside its authority.

Correction:

  • assign autonomy level
  • default to draft
  • log approval

Failure Mode 10: Wrong Recipient

A personalized report or reply is sent to the wrong person.

Correction:

  • validate recipient
  • validate thread
  • validate attachment
  • validate lead ID

Failure Mode 11: Unsupported Commercial Commitment

The response promises pricing, scope, timing or results without authority.

Correction:

  • prohibit unapproved commitments
  • route to sales owner

Failure Mode 12: Appointment Booked In Wrong Timezone

The system interprets a proposed time incorrectly.

Correction:

  • resolve timezone
  • confirm ambiguity
  • preserve stated timezone

Failure Mode 13: Wrong Year Or Date

A relative or incomplete date is interpreted incorrectly.

Correction:

  • resolve absolute date
  • confirm when ambiguous

Failure Mode 14: Duplicate Appointment

The same request creates multiple calendar events.

Correction:

  • check thread
  • check event IDs
  • use idempotency

Failure Mode 15: False Availability

The system offers an unavailable time.

Correction:

  • read live calendar
  • apply buffers and working hours

Failure Mode 16: Existing Client Treated As New Lead

The system sends an acquisition response to a current client.

Correction:

  • validate relationship
  • route to existing-client specialist

Failure Mode 17: Spam Creates CRM Pollution

Low-quality or malicious messages create records and tasks.

Correction:

  • spam and sender validation before storage
  • quarantine suspicious content

Failure Mode 18: Generic Follow-Up Despite Rich Context

The system ignores known lead information.

Correction:

  • use Lead Response Context Packet
  • require personalization from approved fields

Failure Mode 19: AI Overqualifies

The system treats weak or incomplete interest as qualified.

Correction:

  • require reasons
  • use needs-review status
  • apply human review for high-value cases

Failure Mode 20: Missing Consent

The system contacts a lead through an unapproved channel.

Correction:

  • check consent and communication basis before action

Failure Mode 21: Voice Agent Repeatedly Calls

The system retries without limit.

Correction:

  • call-attempt limit
  • suppression
  • stop condition

Failure Mode 22: Call Does Not End Safely

The voice agent remains connected or ignores refusal.

Correction:

  • termination logic
  • do-not-contact handling
  • maximum duration

Failure Mode 23: Transcript Misclassification

AI interpretation is stored as caller fact.

Correction:

  • distinguish transcript, statement, observation and inference

Failure Mode 24: Recording Retained Too Long

Call recordings remain stored without purpose.

Correction:

  • retention and deletion rules

Failure Mode 25: Emergency Not Escalated

The agent continues normal qualification during an urgent or sensitive event.

Correction:

  • emergency and human-escalation conditions

Failure Mode 26: Human Request Refused

The system prevents transfer to a person.

Correction:

  • support human escalation
  • stop automated persuasion

Failure Mode 27: Task Created In The Wrong System

A follow-up task is stored in Notion, email or a spreadsheet rather than the approved task system.

Correction:

  • route to Project Manager Brain
  • preserve task ID and next valid action

Failure Mode 28: Tool Execution Mistaken For Success

An email sends or event is created, but the business result is wrong.

Correction:

  • verify response, recipient, time, status and next action

Failure Mode 29: Model Confidence Treated As Proof

The system acts because the model sounds certain.

Correction:

  • use evidence, rules and approval
  • treat confidence as one signal only

Failure Mode 30: Improvement Applied Without Retesting

A prompt or classifier is changed from one bad result.

Correction:

  • identify repeated pattern
  • approve change
  • regression test
  • monitor
  1. Governance Role

AIBS Brain owns this framework.

AIBS Brain defines:

  • client-facing lead-intake capability
  • packaging
  • service boundaries
  • client-specific configuration
  • operational handoff

Sales Brain governs:

  • qualification policy
  • lead priority
  • commercial follow-up
  • sales ownership
  • proposal and pricing authority

Automation Brain governs:

  • workflow architecture
  • triggers
  • retries
  • integrations
  • reliability
  • monitoring
  • shutdown

Customer Brain governs:

  • existing-customer recognition
  • customer continuity
  • relationship context
  • personalization boundaries

Data Brain governs:

  • schema
  • storage
  • source-of-truth records
  • data quality
  • retention
  • reporting

Compliance Brain and Risk Brain govern:

  • consent
  • privacy
  • sensitive claims
  • communication rules
  • research boundaries
  • regulated actions
  • escalation

SIT Brain governs:

  • testing
  • validation
  • failure simulation
  • deployment readiness
  • regression testing

Project Manager Brain governs:

  • projects
  • workstreams
  • tasks
  • priorities
  • dependencies
  • next valid actions
  • save points

HeadOffice governs:

  • cross-Brain alignment
  • architecture
  • major policy changes
  • unresolved conflicts
  1. Architectural Intent

The architectural intent is to create a governed client-acquisition operating layer that can:

  • accept leads from multiple channels
  • preserve original data
  • classify message meaning
  • route to specialist workflows
  • retrieve conversation history
  • build a controlled context packet
  • qualify leads
  • generate personalized value
  • respond quickly
  • protect consent
  • prepare or execute appointments safely
  • store durable records
  • create governed tasks
  • provide dashboards
  • learn from outcomes

The system should reduce missed opportunities without creating uncontrolled communication.

It should make lead response:

  • faster
  • more relevant
  • more consistent
  • more traceable
  • safer
  • easier to review
  • easier to improve
  • easier to package for AIBS clients
  1. Final Standard

A valid MWMS lead-intake system must:

  • preserve the original intake
  • validate the sender and source
  • classify the message before qualification
  • route the request to the correct specialist
  • clean the payload
  • retrieve the relevant thread
  • use known context before asking again
  • qualify with a reason
  • preserve public-research sources
  • restrict personal profiling
  • generate only supported personalization
  • assign an email or voice autonomy level
  • default to draft or preparation where risk exists
  • validate recipient, claims and thread continuity
  • resolve date, year and timezone before booking
  • check live availability
  • prevent duplicate appointments
  • store the lead and outcome
  • create tasks in Project Manager Brain
  • record human approval
  • preserve an audit trail
  • capture learning
  • stop or escalate when authority is insufficient

The operating principle is:

Classify first.

Use the correct specialist.

Use the full relevant context.

Respond quickly but not carelessly.

Draft before sending unless bounded autonomy is approved.

Check the live calendar before booking.

Store the reason behind every qualification and action.

That is the MWMS Lead Intake Qualification And Follow-Up Automation standard.

Change Log

Version: v1.2
Date: 2026-06-27
Author: MWMS HeadOffice

Change:

Updated the MWMS Lead Intake Qualification And Follow-Up Automation Framework using the AI Automations By Jack AI Agents block covering email classification, specialist inbox agents, prior-thread retrieval, public business research, lead-response generation and calendar booking.

Preserved the existing v1.1 framework covering:

  • multi-channel lead intake
  • payload cleaning
  • lead classification
  • qualification
  • personalized reporting
  • CRM routing
  • follow-up
  • voice lead response
  • dynamic voice context
  • qualification branching
  • calendar booking
  • call controls
  • post-call intelligence
  • transcript governance
  • human escalation
  • consent
  • data quality
  • outcome logging
  • learning loops

Added:

  • sender and source validation layer
  • shared-inbox message classification layer
  • first-level and second-level classification
  • hierarchical classification rule
  • unknown and low-confidence route
  • specialist enquiry-agent routing
  • one unrestricted inbox agent prohibition
  • Lead Response Context Packet
  • conversation-thread continuity
  • previous-commitment preservation
  • public business research boundary
  • source-traceable lead research
  • sensitive personal profiling prohibition
  • response-speed standard
  • email action autonomy levels
  • bounded autonomous reply requirements
  • default email draft rule
  • draft-review checklist
  • email-led appointment workflow
  • absolute date, year and timezone resolution
  • duplicate appointment prevention
  • false-availability rule
  • appointment action levels
  • Project Manager Brain task-routing rule
  • expanded lead schema
  • expanded dashboard fields
  • expanded outcome logging
  • expanded launch-readiness checklist
  • thirty failure modes
  • stronger cross-Brain governance
  • updated final standard

Purpose of update:

To expand the existing multi-channel and voice-enabled lead-intake framework into a governed email-led classification, specialist response, conversation continuity, public business research and appointment-conversion system without creating separate duplicate pages for inbox classification, email response, sales enquiry agents or email appointment booking.

Version: v1.1
Date: 2026-06-21
Author: MWMS HeadOffice

Change:

Updated the MWMS Lead Intake Qualification And Follow-Up Automation Framework using the AI Automations By Jack outbound AI voice agent, inbound appointment setter, voice qualification, calendar booking, post-call analysis and transcript-routing block.

Preserved the existing v1.0 framework and added a complete Voice Lead Response And Appointment Setting Layer.

Added the standard voice workflow:

Lead Submitted Or Call Received
↓
Validate Contact And Permission
↓
Trigger Voice Response
↓
Load Known Lead Context
↓
Confirm Identity And Availability
↓
Qualify Need, Fit, Timing And Budget
↓
Select Approved Route
↓
Check Calendar
↓
Book Appointment Or Provide Alternative Path
↓
End Call Safely
↓
Analyse Call
↓
Store Transcript, Summary And Outcome

Added voice-specific failure modes covering incorrect identity, stale data, wrong timezone, duplicate bookings, call-ending failure, repeated calls, wrong branching, false availability, transcript misclassification, excessive retention, missed emergency escalation, refused human transfer and failure to write corrected data back to CRM.

Purpose of update:

To expand the existing lead-intake framework into a governed voice-enabled intake, qualification, appointment-setting, post-call intelligence and follow-up system without creating separate duplicate pages for voice lead response, appointment setting, voice qualification, calendar booking or post-call intelligence.

Version: v1.0
Date: 2026-06-01
Author: MWMS HeadOffice

Change:

Created the MWMS Lead Intake Qualification And Follow-Up Automation Framework.

Added:

  • Lead Intake Source Types
  • Standard Lead Schema
  • Payload Cleaning Rules
  • Classification
  • Qualification Logic
  • Personalized Report Generation
  • PDF Generation Rules
  • Email Follow-Up Sequences
  • CRM Routing
  • Dashboard Integration
  • Human Review Rules
  • Compliance And Consent Rules
  • Tool Permission Requirements
  • Build Path
  • Launch Readiness Checklist
  • failure modes covering messy payloads, missing qualification reason, generic follow-up, AI overqualification, slow lead routing, overpromising reports, wrong-recipient PDFs, CRM pollution, missing consent and lack of feedback loop
  • responsibilities across AIBS Brain, Sales Brain, Automation Brain, Data Brain, Content Brain, Customer Brain, Risk Brain, Compliance Brain and SIT Brain
  • AI Employee capabilities including Lead Intake Architect, Payload Cleaning Agent, Lead Qualification Agent, Personalized Report Agent, Follow-Up Sequence Agent, CRM Routing Agent and Lead Quality Kaizen Agent

Purpose of creation:

To establish lead intake, qualification, personalized reporting, CRM routing and follow-up automation as a governed AIBS capability and future client-facing AIOS layer.

Change Impact Declaration

This v1.2 update strengthens the existing framework without changing its ownership, parent page, authority level or core lead-intake purpose.

Pages Created

None

Pages Updated

MWMS Lead Intake Qualification And Follow-Up Automation Framework v1.1 To v1.2

Pages Deprecated

None

Standalone Pages Not Created

MWMS Shared Inbox Classification Framework

MWMS Email Lead Response Framework

MWMS Sales Enquiry Agent Framework

MWMS Email Appointment Booking Framework

MWMS Lead Public Research Framework

MWMS Conversation Thread Continuity Framework

These concepts were absorbed into the existing framework to avoid duplication and page bloat.

Registries Requiring Update

AIBS Brain Page Registry If Version Tracking Is Maintained

AIBS Brain Copy Map If Version Tracking Is Maintained

Canon Version Update Required

No

Change Log Entry Required

Yes

Strategic Absorption Result

MWMS gains a governed multi-channel lead-intake system that combines form, voice, chatbot, WhatsApp, calendar and email intake with message classification, specialist routing, conversation continuity, source-traceable business research, lead qualification, controlled response generation, appointment safeguards, CRM storage, Project Manager Brain task routing, human escalation and continuous improvement.

END OF FULL FILE OUTPUT