Build your first automated service in Telerivet
A walkthrough of the decisions involved in building an automated service, using an appointment reminder as the example scenario.
You've added a route, you understand the service types, and you've decided what you want to build. The next question is what the build process actually looks like before you start clicking through configuration. This article walks through the decisions involved in building an automated service, using an appointment reminder as the example scenario. It covers what you need in place before you start, the choices you will make during the build, and how to confirm it is working before you go live.
For setup steps and configuration details, see Introduction to Services in the User Guide.
What you need before you start
Building a service takes less than ten minutes once these four things are in place. Without them, you will hit a wall partway through.
A route. The service needs a channel to send through. If you have not added a route yet, start with Understanding Routes in Telerivet before building a service.
Your contacts loaded. The service sends to contacts in your Telerivet project. If your contacts are not imported yet, do that first. For the appointment reminder scenario, contacts also need an appointment date stored as a contact field, since that is what the service uses to know when to send.
Your message written. Draft the message content before you open the service builder. Appointment reminders work best when they are specific: the contact's name, the appointment date and time, and a clear action if they need to reschedule. Telerivet lets you personalize messages using contact field values, so "Hi [[first name]], your appointment is confirmed for [[appointment date]] at [[appointment time]]" becomes personal at scale.
Clarity on what happens when someone replies. A reminder that goes out but has no plan for replies is an incomplete workflow. Decide in advance: do you want contacts to be able to confirm, cancel, or ask a question? If yes, you will need to handle those inbound responses as part of the service design. If no, make sure your message sets that expectation clearly.
The decisions you will make during the build
This is the shape of what building the service involves. The User Guide covers the clicks; this covers the thinking.
What triggers it? For an appointment reminder, the trigger is time-based: send a message a certain number of hours or days before the appointment date stored in a contact field. You will define which contact field holds the date and how far in advance the message goes out. One day before is common for healthcare and hospitality; two hours before works well for high-confirmation-rate scenarios like events.
Who does it send to? You will specify a contact group or filter. For appointment reminders, this is typically a dynamic group that includes any contact with an upcoming appointment date. As contacts are added or their appointment dates change, the group updates automatically.
What channel does it send on? The service sends through whichever route you assign it to. If you want to send via WhatsApp with SMS fallback, configure that at the route level before building the service. The service itself just needs to know which route to use.
What happens when someone replies? If you want to capture responses (confirm, cancel, reschedule), you will need to define what the service does with each possible reply. A simple confirmation flow might look like: reply YES to confirm, reply NO to cancel. Each reply keyword triggers a different action. Custom Actions handles this without code; Cloud Script handles it if the logic is more complex.
What does the service do after it sends? Consider the end state. After a contact confirms, should the service update a contact field to record the confirmation? Should it add the contact to a "confirmed" group? Should it trigger a follow-up message closer to the appointment? These decisions are easier to make before you build than to retrofit afterwards.
Before you go live
Test with a real number first. Telerivet's test mode lets you trigger the service against a test contact and see exactly what goes out and when. Use it before enabling the service for your full contact list. See Testing and Debugging Your Services in the User Guide.
Check your service order. If you have more than one active service in your project, Telerivet evaluates them from top to bottom. A catch-all auto-reply sitting above your appointment reminder service will intercept replies before the reminder service can handle them. Review the order before activating. See Ordering Multiple Active Services in the User Guide.
Check your quiet hours settings. If your route has quiet hours configured, confirm that your reminder timing does not conflict with them. A reminder scheduled for 7am that gets blocked by a quiet hours rule until 9am is no longer an accurate reminder.
How to know it is working
Once the service is live, three things tell you it is behaving as expected.
The activity log in your project shows every service that ran, when it ran, and what actions it took. Check this after your first scheduled send to confirm the service triggered and the message went out.
Delivery reports on individual messages confirm whether the message reached the recipient's device. A service that triggers correctly but has delivery failures points to a route or number issue, not a service configuration issue.
Reply tracking shows whether contacts are responding and how the service is handling those replies. If you built a confirmation flow, check that confirmed contacts are being marked correctly and that no-reply contacts are not being incorrectly processed.
What to build next
Once your first service is working, the natural next step is adding complexity: a follow-up message for contacts who did not reply, a cancellation flow for contacts who reply NO, or a second reminder closer to the appointment date. Each of these is a separate service or an additional branch in your Custom Actions flow.
For examples of how organizations across healthcare, logistics, and financial services have structured reminder and follow-up workflows, see Three simple journeys every organization should automate, How Clinics Automate Appointment Reminders with SMS, WhatsApp, Viber, and How to Build Automated Customer Communication Workflows That Actually Scale.
For a broader look at what automated services can do across different workflow patterns, see Automated Services in Telerivet: What They Really Do.
Best practice tip
Build the simplest version first and confirm it works end to end before adding branches or conditions. A one-message reminder that sends reliably is more valuable than a five-step flow that has never been tested. Once the core send-and-confirm loop is working, you have a stable foundation to build on. Complexity added to a working service is much easier to debug than complexity added before anything has gone live.
Reach out to your customer success lead or get in touch if you want help designing a more complex reminder or follow-up workflow.