Project: Rules-Driven SMS Scheduling & Dispatch System (Make.com) I am looking for a senior Make.com automation developer to build a rules-driven operational system, not a simple workflow. Goal Create a robust system that receives inbound SMS (Twilio), uses AI-powered parsing, creates or updates jobs, schedules the correct technician in Google Calendar, and prepares draft invoices in QuickBooks — all driven by configurable rules and data, not hardcoded logic. AI-powered SMS parsing (required) Use Claude API or GPT-4 to extract and normalize at minimum: service requested, vehicle (make/model/year or VIN/stock), datetime constraints, location/dealer, and advisor/client identity. Parsing must be French-first and resilient to unstructured messages. Core principles (non-negotiable) You are building a configurable engine, not fixed business logic All business rules must be editable via data tables (Google Sheets or Data Store) without modifying automation scenarios The system must be fully evolvable without re-coding after delivery The JOBS table is the single source of truth and must persist Job ID, Google Calendar Event ID, and QuickBooks Invoice ID to prevent duplicates and enable updates/reassignments Main components to deliver Twilio inbound SMS webhook → Make.com scenario Central JOBS data model with job lifecycle (new / pending / scheduled / in progress / delayed / completed) Rule-based dispatch engine (skills, priorities, availability, constraints) Google Calendar integration (multi-technician calendars, persistent event IDs) QuickBooks Online integration (clients + draft invoices, OAuth only) Simple technician interface (web link) with status buttons (In Progress / Delayed / Completed / Add Service) Admin SMS command interface (secured, limited command set) Error handling, retries, logs, and no-job-lost fail-safes Technical requirements Make.com only (no n8n, no external scripts or servers) OAuth connections (Twilio, Google, QuickBooks) Clean documentation + blueprint export Clear separation between engine logic and business rules Important If you plan to hardcode rules, conditions, or messages inside scenarios, this project is not a fit. Payment Payment will be milestone-based and conditional on validation of configurability and extensibility. Screening question (required) Please explain how you would design a rules-driven dispatch engine without hardcoding business logic, and how rules would be updated after delivery.