A working example
A text that still needs a person to finish the request
A customer calls a home-services business while the team is busy. An illustrative workflow prepares a short text asking what help is needed. The customer replies with a service request and preferred time. The reply gives the team a useful lead, but no visit is scheduled until the business accepts the work and confirms a time.
Choose one owner and one observable event for each status. Never turn a prepared text, provider acknowledgement, or customer reply into a claim that staff handled the job.
Name each state before the first message
Prepared means the workflow has drafted a message for an approved destination; it says nothing about sending. Submitted means the configured provider accepted the request for processing. Sent requires the provider's sending status when that status is available. Delivered needs a delivery event or another agreed check, and even that does not show the person read the text. Responded means an inbound reply was received and matched to the right conversation.
Staff accepted is a separate event: the responsible person or system has taken ownership of the request. Completed means the business can verify the promised action, such as a confirmed visit or a resolved question. A reply saying 'Thursday works' is a preference until the schedule owner confirms it.
- Prepared → submitted → sent → delivered: follow the outbound message using the actual provider events available.
- Responded: record the inbound request and keep it attached to the correct call.
- Staff accepted → completed: use a team or business record, not the message thread alone, as evidence.
Make the text useful without overstating its role
Keep the first message recognizable: identify the business, refer to the missed call, and ask for only the detail needed to route the request. Decide who receives replies that are off-topic, urgent, or outside the approved workflow. If the business cannot act after hours, the wording should set that expectation rather than imply immediate service.
Before launch, review the sending number, who may be contacted, permission and opt-out handling, hours, message content, and the provider settings for the actual account. These are setup decisions for the business to verify; a generic example cannot establish what messages are permitted in a particular place or account.
Give replies and failures a visible owner
A concise staff item should show the customer's request, contact path, timing, conversation status, and the decision still pending. Decide when staff acknowledge the item, where that acknowledgement is recorded, and who checks that no unanswered reply is stranded. The handoff should not say 'assigned' merely because a summary was generated.
Rehearse a missing delivery event, a failed text, an opt-out, a reply from an unmatched number, and a request the team declines. If the result is uncertain, check the provider and business records before retrying or telling the customer it was handled. The recorded SMS example on this site illustrates a conversation; opening that page does not send a message or create a customer request.
Before setup
Questions to bring to the conversation
- 01Define the missed-call events that may start a text and the calls that need a person instead.
- 02Review the sending number, contact permission, timing, content, and opt-out path for the actual setup.
- 03Identify the evidence used for prepared, submitted, sent, delivered, responded, staff accepted, and completed.
- 04Assign a team owner to replies and specify how they acknowledge and close a request.
- 05Test failed delivery, no reply, unmatched reply, and a request that cannot be accepted.
Common questions
Clear answers before a pilot
Does a prepared text mean the caller received it?
No. Preparation is only a draft state. Check the configured sender's submission and delivery events before describing a message as sent or delivered.
If a customer replies, is their appointment confirmed?
No. The reply supplies information or a preference. A visit needs the scheduling owner or authorized system to accept a specific time and communicate that confirmation.
Is provider acceptance the same as sending or delivery?
No. Acceptance shows the submission was taken for processing. Check later sent and delivery events where the provider exposes them, and treat missing or uncertain status as unresolved.
What should happen when staff cannot take the job?
Record that decision, give the customer the accurate next step through the approved channel, and close the item only after the business's follow-up action is verified.
See the next step
Watch the SMS follow-up example
The recorded page uses sample data and does not send a text or create a live request.
Continue