Project notify-customer-messaging-for-one-app-email-sms-slack · revised 11 October 2026
Project
Set up customer email, SMS and staff Slack notifications for up to five events in one app
Up to five events in your app each send the right email or text to the customer and an alert to staff, from one table, with every send logged once and its delivery status recorded.
This asks for a proposal by email. Nothing is charged, and nothing starts, until you have agreed the events, the price and the terms in writing.
The result you are buying
Separate email, text and chat connections added event by event drift apart: each has its own wording, failure handling and logging, an event can send twice or not at all, and no single record says what was sent to whom. A new event means touching code in several places. The fault is the missing layer that turns an event into the right messages once and records the outcome.
Who it’s for: A founder or product owner whose app tells customers and staff about important events by hand, by one-off scripts or not at all, and who wants a single dependable notification layer rather than three separate connections.
Usually starts when: Staff are chasing customers by phone and email, notifications are triggered from several places so some events double-send and others never send, and nobody can say what a given customer was told.
The result: You buy the finished notification layer for up to five named events. One table says which event sends which email, text and staff alert; each send happens once and is logged with its final delivery status; ineligible recipients and flagged addresses are skipped on the record; and a provider outage never fails the action that caused the event.
How the work fits together
The project is complete when each channel passes its tests for every agreed event, the send log shows one row per message with its final status, and you have accepted the final summary. You accept the finished notification layer, not each internal step.
Send your app's emails through SendGrid on your own domain, with bounces recorded Job Included
Up to three kinds of app email go out through your SendGrid account on your authenticated domain, and an address that bounces is recorded once and not mailed again.
Up to three email message types, shared across the up to five events
The email channel is this outcome, used inside the project; it can be bought on its own.
Send one kind of SMS notification from your app through Twilio and track its delivery Job Included
One agreed app event sends one SMS through your Twilio account, and the app stores each message's delivery status from signed callbacks, even when they arrive out of order.
The SMS channel for each of the up to five events that need a text
The SMS channel is this outcome's method, applied to each such event inside the project (the single outcome covers one event); it can be bought on its own for one event.
Post one app event to a Slack channel, without letting Slack slow or break your app Job Included
One agreed event in your app posts one message to one Slack channel; a repeat of the event adds nothing, and a Slack outage or rate limit never fails the customer's request.
The staff alert channel for each of the up to five events that need one, to one channel
The staff alert is this outcome's method, applied to each such event inside the project (the single outcome covers one event); it can be bought on its own for one event.
Keep your app's emails and texts reaching people, with failures found early, every month Standing service Optional
Each month we read your app's delivery records for email and SMS, flag addresses and numbers that keep failing, check sender records still match, and send a short delivery summary.
After launch, the monthly delivery review watches the log this project creates.
How an engagement works
The price covers the agreed events and the three channels only. A sixth event or another channel is quoted separately.
How it starts
You send the events you want to announce and tell us who should be told for each.
We read the app, agree the table, the providers and a fixed price, and confirm that sender approval and credentials are in place.
You agree the list, price and terms in writing. Nothing starts before then.
We build the event table and the send log, then add each channel in turn, sending a pull request for each for you to accept.
We send the final summary and hand over the guide and anything left open.
Who decides what
You decide the events, the wording and who may be texted, and accept each channel. Your team merges and deploys on its own gates.
Handover
Each channel arrives as a pull request with its tests. Anything unfinished is handed back with notes.
Sharing your product safely. Send a list of events, never recipient data. After you agree the project, invite us to a repository or fork you control and send staging credentials that you created.
What is included, and what is not
- Pull requests for the event table, the send log and each channel, each with its tests
- The agreed event-to-message table and the wording of each message
- Redacted evidence of each event and channel on staging with your test mailbox, phone and Slack channel
- A guide for adding a sixth event, and a final summary
Included
- Up to five named events in one existing app, each mapped to a customer email, an optional customer text and an optional staff Slack alert, in one event-to-message table; the emails across the five events use at most three email message types, which may be shared between events
- Email through SendGrid with your authenticated domain and bounce handling, one Twilio SMS sender with delivery tracking, and one Slack channel for staff alerts. These three providers are what the price covers; a different email, SMS or chat provider changes the scope and the quote
- A single send log with one row per message, its channel, the event identifier and its final delivery status. Each row is created, with a unique key on event identifier and channel, before the provider is called; a repeat or simultaneous duplicate of the event finds the row and sends nothing
- Handling of an unknown result: a row still waiting after the agreed timeout, because the worker stopped or the provider's reply was lost, is flagged for a person and not re-sent automatically, since the provider may already have sent it. Sends the provider clearly rejected are retried with its own wait and then flagged
- Eligibility rules in your own data: no text to a number not marked eligible, no email to a flagged address
- Tests for every event and channel, including repeated and simultaneous events, a worker stopped mid-send and a provider outage
Not included
- Marketing, newsletters or any bulk mailing
- Sender registration and approval for SMS in any country, and consent or privacy advice
- Inbound replies, opt-out keyword handling and two-way conversations
- More than five events, more than one provider per channel or channels beyond email, SMS and Slack
- Template design beyond plain, readable messages
- Production deployment or any promise about delivery rates
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Each of the agreed events, fired once on staging, sends exactly the messages the table specifies to the test mailbox, phone and Slack channel, and the send log has one row per message.
Evidence: Redacted copies of each received message and the send-log rows for each event.
Firing the same event identifier again sends nothing more on any channel and adds no log rows, and firing it twice at the same moment sends one message per channel and creates one row per channel.
Evidence: Test output (the concurrent run repeated many times, with the number stated) and the log row count before and after.
With a worker stopped after its log row is created and before the provider is called, the row is flagged for a person after the agreed timeout and nothing is sent a second time.
Evidence: Test output with the row's state before and after the timeout and the count of messages sent.
A recipient not marked eligible for texts and an email address flagged as bounced are skipped, and each skip is logged with its reason.
Evidence: Test output and the logged skip rows.
With each provider made unavailable in turn, the action that caused the event still succeeds, and the failed send is retried then flagged.
Evidence: Test output per provider and the flagged rows.
The delivery status for each message sent to the test mailbox and phone reaches a final state in the log.
Evidence: The log rows with their status history.
Sign-off. You accept each channel, or send it back with comments, and then you accept the finished notification layer.
If it fails. A channel we cannot finish safely is named with the reason and what it would take, and is taken off the list with a matching change to the price. Nothing is billed as delivered that you have not accepted.
When it fits, and when we stop
It fits when
- Your account holder has an active SendGrid account, a Twilio account with an SMS sender approved for your countries and a Slack workspace where an app or incoming webhook is permitted
- The events have stable identifiers in your data and you can name them and the recipients
- A staging copy of the app, a test mailbox, a test phone and a test Slack channel exist
- A person on your side can accept changes and decide the wording of each message
We stop and tell you if
- The SMS sender is not approved for the destination countries
- The events have no stable identifier and cannot get one, so repeats cannot be prevented
- You use an email, SMS or chat provider other than SendGrid, Twilio and Slack and do not want it requoted as a different scope
- The scope grows into marketing, inbound messaging or more than five events, so we propose a different scope
- Nobody on your side can hold the provider credentials
What could go wrong
Each channel is a separate pull request that your team merges, so any one can be reverted on its own. If the project stops, accepted channels stay accepted and the rest is handed back with notes. The send log can be kept or dropped under your retention rules.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A customer is messaged twice or not at all for an event. | One row per event identifier and channel in the send log, created with a unique key before the provider is called so a repeat or simultaneous duplicate finds it and sends nothing; a repeat-event and a simultaneous-event test for every event, and a staging run per event. |
| The process stops after the row is created, or the provider's reply is lost, so nobody knows whether the message went. | A row still waiting after the agreed timeout is flagged for a person with the details to check at the provider, and is not re-sent automatically. This favours a missed message that is visible over a duplicate that is not. A test stops a worker mid-send. |
| A real customer is messaged during testing. | Testing uses a mailbox, a phone and a channel you own on staging, and eligibility rules block any recipient your data does not mark as eligible. |
| A provider outage stops the action that triggered the event. | Sends run after the action is saved, failures are retried with the provider's own wait and then flagged, and a test makes each provider unavailable. |
Each change is reviewed separately from the work that produced it, and you accept every channel. No human supervisor is included unless your proposal names one. At launch the work is largely automated, and we say so.
Stays with a person
- You accept each channel
- You merge and deploy on your own gates
- You hold the production credentials
Access we would need
- Read access to a repository or fork you control; no production access
- Restricted staging credentials for each provider that you create
Questions
Why a project rather than three separate jobs?
The three channels share one event table and one send log. Built together, an event is turned into its messages once and you can see what was sent to whom in one place. The project also applies the SMS and Slack methods to each of up to five events, where each single job covers one.
Which providers does it use?
SendGrid for email, Twilio for text messages and Slack for staff alerts. A different email, SMS or chat provider changes the scope and the quote.
Do you handle SMS sender registration?
No. Registration and the rules for your countries stay with your account holder. The project assumes an approved sender and says plainly if one is missing.
Can customers reply or opt out through the app?
Not in this project. It sends one way. Inbound handling would be a separate scope.
What if we have only email and Slack?
Then ask for just those channels. The single email and Slack outcomes can be bought separately.
Send an enquiry
Send us
- The events you want to announce, in order of importance, and who should be told for each
- Whether you use SendGrid, Twilio and Slack for these channels (the project is priced for them; another provider is quoted separately)
- The language, framework and whether a staging copy exists
- Do not send keys, customer contact data or code in the first enquiry
Later, once you agree
- Read access to a repository or fork you control, with no production access
- Restricted staging credentials for SendGrid, Twilio and Slack, created and held by you
- A test mailbox, a test phone and a test Slack channel you own
- Your decisions on wording, eligibility rules and the five events
Your repository, provider accounts, credentials and recipient data stay yours. We work on branches or a fork you control and return pull requests. Production credentials never leave your secret store.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “notify-customer-messaging-for-one-app-email-sms-slack” as the subject.