AI-Powered SMS Scheduling & Dispatch Tool
Budget: $25 – $50 CAD
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.
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.