A cleaner missing a 9 a.m. turnover can create a chain of calls, refunds, and unhappy property managers. The problem usually starts earlier, when dispatch depends on memory, scattered messages, or an incomplete job record.
A dependable approach to cleaner dispatch automation gives every job a clear status, checks cleaner eligibility, requests confirmation, and routes exceptions to a person. Twin.so can act as the workflow layer when you connect the right triggers, records, and operating rules.
The goal isn’t to remove people from dispatch. The goal is to reserve human attention for exceptions instead of routine assignments.
Start with a dispatch contract, not a prompt
Reliable automation begins with a defined operating contract. The workflow needs to know what counts as a new job, who can receive it, how long they have to respond, and what happens when they don’t.
Do not dispatch from a free-form message alone. A text such as “clean the apartment tomorrow morning” lacks the information a workflow needs. It doesn’t identify the property, service duration, access method, customer priority, or assigned time window.
Create one structured job record for every service request. Twin.so can use that record as its trigger or pass it to the connected scheduling, CRM, or database system, depending on your setup.
| Job field | Why the workflow needs it |
|---|---|
| Job ID | Prevents duplicate assignments and supports audit records |
| Service date and time | Defines the dispatch window |
| Property address or zone | Filters cleaners by location |
| Service type and duration | Matches the job to cleaner skills and capacity |
| Access instructions | Reduces arrival problems |
| Priority or SLA | Determines the escalation deadline |
| Cleaner status | Shows whether the job is unassigned, offered, confirmed, or complete |
Use stable status values. A practical sequence is New, Ready, Offered, Confirmed, In Progress, Completed, and Exception.
Every automation step should read the current status before acting. This prevents an old trigger from assigning a job that a dispatcher already handled manually.
Map the workflow before you build it
Write the dispatch process on paper before configuring it in Twin.so. Keep the first version narrow. A simple process is easier to test than a large workflow with unclear decisions.
The basic path looks like this:
- A new booking enters the system.
- Required fields are checked.
- Eligible cleaners are identified.
- The first offer is sent.
- The cleaner confirms or declines.
- The job record is updated.
- A fallback rule runs if the offer expires.
- Operations receives an alert when no automatic assignment is possible.
The workflow needs separate paths for normal work and exceptions. If every outcome continues through the same branch, the system will eventually treat a failed dispatch as a successful one.
Start by listing your actual dispatch decisions:
- Is the job inside the cleaner’s service area?
- Does the cleaner have the required skills?
- Is the cleaner available during the full service window?
- Has the cleaner reached their daily capacity?
- Does the job require a special access method or supply?
- Is the booking urgent enough to bypass the normal queue?
Convert each decision into a condition that Twin.so can evaluate or pass to another system. Avoid asking an AI step to make a decision that should be a fixed rule. “Cleaner is within 10 miles” is a rule. “Choose the best cleaner” needs a defined scoring method.
Build cleaner dispatch automation in Twin.so
Use the triggers, actions, conditions, and connected services available in your Twin.so workspace. The exact setup depends on how your bookings, cleaner records, messaging tools, and calendars are connected.
Build the workflow in this order:
- Trigger the workflow when a job becomes dispatchable.
A booking-created event may be too early if payment, address, or access details are still missing. Use a “Ready” status when the required information has passed validation. - Validate the job before searching for a cleaner.
Check the service date, time window, address, duration, job type, and access instructions. If one required field is missing, stop the workflow and create an operations task. Don’t send an incomplete job to a cleaner. - Filter the cleaner pool.
Remove cleaners who are unavailable, outside the service zone, over capacity, or missing required qualifications. If availability comes from a calendar or scheduling tool, confirm that the data includes the full service duration, not only the start time. - Rank the remaining candidates.
Use a transparent order. For example, rank by zone, availability, skill match, workload balance, and preferred cleaner status. Store the selected candidate and the reason for selection when the connected system supports it. - Send an offer and wait for a recorded response.
The message should include the property, date, arrival window, service type, expected duration, access notes, and response deadline. A link, reply command, or workflow action can record acceptance if your connected tools support it.
Before sending an offer, check that the job is still in the Ready state. After a response arrives, check the status again before confirming the assignment. These two checks reduce duplicate dispatches when webhooks, staff actions, or multiple workflows run at nearly the same time.
Use a unique job ID in every message and update. If the platform or connected database supports idempotency keys, use the job ID plus dispatch attempt number. If it doesn’t, store a processed-event record outside the workflow so a repeated trigger doesn’t send another offer.
A message should confirm the actual result, not only the action taken. “Offer sent to Maria” is not the same as “Maria accepted job 1842.” Keep those states separate.
Add confirmation, fallback, and manual controls
Automation becomes dependable when failure is expected and handled. A cleaner may miss a message, lose availability, decline the job, or accept another booking before responding.
Never treat a sent offer as a confirmed assignment. Confirmation requires a recorded acceptance or a documented manual override.
Send confirmation messages
Send a confirmation to the cleaner after acceptance. Include the job ID, property, arrival window, access method, and any special instructions. Use the same job details stored in the system. Don’t ask the workflow to rewrite important instructions from memory.
Notify operations when the assignment is confirmed. If customer notifications are part of your process, send them only after the assignment status changes to Confirmed.
Set an expiration time for each offer. The exact period should match your service window. A same-day turnover may need a short response window, while a job scheduled next week can allow more time.
Define fallback assignment rules
Fallback rules should be ordered and finite. A useful sequence is:
- Offer the job to the next eligible cleaner in the same zone.
- Expand the search to an adjacent zone if travel time remains acceptable.
- Contact the approved backup roster.
- Create an urgent operations alert.
- Mark the job as an exception if no one confirms.
Don’t allow the workflow to keep messaging candidates without a stop condition. Set a maximum number of attempts and an escalation deadline.
Record every failed attempt. The record should show who received the offer, when it was sent, whether it was opened or answered if that data is available, and why the attempt ended.
Keep a manual override
Dispatchers need a clear way to pause automation, assign a specific cleaner, skip the normal ranking, and cancel an outstanding offer. If Twin.so supports workflow controls for these actions, expose them to the operations team. If not, connect the workflow to a system where staff can change the job status.
Use a required override reason. Good options include customer preference, access complexity, cleaner relationship, emergency coverage, or data correction.
A manual change should prevent the previous automated branch from continuing. For example, if a dispatcher assigns Cleaner B while an offer to Cleaner A remains open, the workflow must cancel or invalidate the old offer.
Test the workflow with real failure cases
Do not test only the successful path. Create test jobs that match the problems your team sees every week.
Check what happens when:
- The address is missing or invalid.
- The service duration conflicts with cleaner availability.
- No cleaner matches the required skill.
- Two workflow runs start for the same job.
- A cleaner accepts after the offer expires.
- Two cleaners accept within the same response window.
- A dispatcher changes the assignment during automation.
- A booking is cancelled after an offer is sent.
- A message provider or scheduling connection fails.
Use test records that cannot reach real customers or cleaners. Inspect each status change and message. Confirm that an exception creates a visible task instead of disappearing inside a failed workflow run.
Run the same test again after changing a condition or message template. Small edits can affect later branches, especially when several actions depend on the same status field.
Measure dispatch performance after launch
Track the workflow with operational metrics. Avoid measuring only how many automations ran. A high run count can hide poor assignment quality.
Review these numbers each week:
- Percentage of jobs confirmed automatically
- Median time from Ready to Confirmed
- Offer acceptance and decline rates
- Percentage requiring fallback
- Percentage requiring manual override
- Duplicate assignment incidents
- Jobs reaching the escalation deadline unassigned
- Cancellation rate after assignment
Split the results by service type, zone, day, and time window. A workflow may perform well for recurring apartment cleans but fail for large move-out jobs.
Audit the exceptions before changing the ranking logic. Many failures come from inaccurate availability, missing access details, or stale cleaner records. Fix the input before adding more automation.
Use a small change log for workflow updates. Record the date, change, reason, test result, and owner. This gives your team a clear history when dispatch performance changes.
Conclusion
Reliable cleaner dispatch automation on Twin.so depends on more than connecting a booking trigger to a message. You need structured job records, explicit eligibility rules, recorded confirmations, finite fallback paths, and a manual override that staff can trust.
Build the normal path first. Test duplicate events and late responses next. Then monitor exceptions and update the rules based on actual dispatch data.
The strongest workflow is not the one that makes every decision automatically. It’s the one that confirms routine assignments quickly and makes every failure visible before it affects the customer.
