Capability template for business systems and integrations
Notification channel plan
When a business event needs to notify people, the integration owner gets one channel plan from the event definitions: trigger, urgency, who is told by which channel, what needs confirmation, fallbacks and reply handling. Consent and message rules stay as questions. Nothing is sent.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
Before anyone builds the notification, the integration owner holds one plan that says, for each business event, what sets it off, how urgent it is, who is told, by which channel and in what order, and what happens when nobody answers. The gaps that usually surface after launch are written down first: a text that nobody reads replies to, an email that reports no delivery, an alert held back by a quiet-hours rule, an escalation with nobody at the end of it.
The plan is careful about what a send proves. A service accepting a message is recorded as acceptance, not delivery, and a message sent is never counted as a person confirming. Where the plan needs a rule about consent, message content or timing that nobody has supplied, it asks the responsible owner and does not guess. The integration owner approves the design; the service owner approves the message rules and timing. The AI assistant prepares the plan. It writes no message, connects to no service and changes no setting.
Who starts the work, and when
The integration owner or business systems analyst starts it when a business event is about to get a notification, or when an existing one is being reworked. It can run again when an event is added, a channel changes or an owner answers one of the questions. The integration owner reads the plan, takes the design questions, and passes the rest to the service owner and to whoever owns consent and communication requirements.
What they supply
- The event definitions: each event, what triggers it, when it can fire, who is told, how urgent it is, whether someone must confirm, and who it escalates to.
- Recipient preferences: the channels each group has and the order they prefer, with the hours they can be reached.
- The channel list: which channels are set up, who reads replies on each, and whether the channel reports delivery.
- Approved messaging constraints, each with who approved it.
- The settings: the service, today's date, the integration owner and service owner, and who answers consent questions. Your own urgency scale and confirmation windows, if you have them.
What comes out
One plan in a fixed order. A header with the counts, then a block for each event: trigger, urgency, who is told by which channel, confirmation, timing, fallback, escalation, reply handling, repeat rule and the evidence the integration will see. Then the events that could not be planned and why, a note on each channel, the constraints applied, and numbered questions grouped by the person who must answer them.
An invented example
Illustrative example with invented data. An invented 30-person bike and kayak hire company, Company A, plans the notifications for five events. The people are invented too: Priya, the integration owner, and Marcus, the service owner. Company A's compliance lead answers consent questions.
What the person supplies
Settings. Service: Company A hire desk. Today: Thursday 12 November 2026. Integration owner: Priya. Service owner: Marcus. Consent and communication requirements: the compliance lead. Urgency scale, confirmation windows and channel suitability: the defaults.
Event definitions. Export with the headers Event, Trigger, Can fire between, Recipient group, Urgency, Needs confirmation, Confirmation sign, Escalation role:
- Booking confirmed, Payment marked paid in the booking system, any time, Customer, Same day, No, none, none.
- Equipment not returned, Return not scanned 30 minutes after the booked end time, up to 18:30, Duty manager, Immediate, Yes, Duty manager taps "Taken" in the staff app, Operations lead.
- Weather closure, Operations lead sets the site to closed, any time, Customer (bookings that day), Immediate, No, none, none.
- Low stock of helmets, Stock count below 5, weekdays 08:00 to 17:00, Stock clerk, Routine, No, none, none.
- Damage reported, Staff form submitted, any time, Duty manager, (blank), No, none, none.
Recipient preferences. Export with the headers Recipient group, Channels they have, Preference order, Reachable hours:
- Customer, text and email, text then email, any time.
- Duty manager, staff app and text and phone call, staff app then text then phone call, 07:00 to 19:00.
- Operations lead, text and phone call and email, phone call then text, 07:00 to 21:00.
- Stock clerk, staff app and email, email, weekdays 08:00 to 17:00.
Channel list. Export with the headers Channel, In place, Reply handled by, Delivery status reported:
- Text, yes, none (one-way), yes.
- Email, yes, Front desk (inbox read 09:00 to 17:00), no.
- Staff app, yes, none, yes.
- Phone call, no, none, no.
Approved constraints. Export with the headers Constraint, Applies to, Approved by:
- No customer text before 08:00 or after 20:00, Customer, Service owner.
- No payment amounts in a text, Customer, Service owner.
- Text only where the booking record shows text agreement, Customer, Compliance lead.
What comes out
NOTIFICATION CHANNEL PLAN: Company A hire desk
For: Priya, integration owner, who approves the design; Marcus, service owner, who approves message rules and timing. Prepared: Thursday 12 November 2026, from 5 event definitions, recipient preferences, a channel list of 4 channels, 3 constraints.
Urgency scale: Immediate = someone acts within minutes; Same day = within the working day; Routine = next working day or later. Confirmation windows: Immediate 15 minutes, Same day 2 hours, Routine next working day. Defaults used: urgency scale, confirmation windows, channel suitability by urgency.
Events: 5 (4 planned, 1 not planned). Channels used: text, email, staff app. Questions: 12.
E1 Booking confirmed
Trigger: Payment marked paid in the booking system. Can fire: any time.
Urgency: Same day.
Told: Customer, by text; by email where the booking record shows no text agreement (K3).
Confirmation: not needed.
Timing: Text at once between 08:00 and 20:00; a payment made outside those hours is held until the next 08:00 (K1). Customers with no text agreement are emailed at once.
Fallback: text not delivered, as the text service reports: email. Customers reached by email only: none possible, because email reports no delivery.
Escalation: not needed.
Reply handling: text, replies unread. Email, Front desk, inbox read 09:00 to 17:00.
Repeat rule: not stated.
Delivery evidence: text, delivery report. Email, sending accepted only, which is not proof of delivery.
Constraints applied: K1, the text is held outside 08:00 to 20:00; K2, the text carries no payment amount; K3, email only where the booking record shows no text agreement.
Open points: Q6, Q7, Q9, Q11, Q12.
E2 Equipment not returned
Trigger: Return not scanned 30 minutes after the booked end time. Can fire: up to 18:30.
Urgency: Immediate.
Told: Duty manager, by staff app.
Confirmation: needed. Sign: Duty manager taps "Taken" in the staff app. Window: 15 minutes.
Timing: minutes after the trigger. 0: staff app to the Duty manager. 15: text to the Duty manager if not confirmed. 30: text to the Operations lead if not confirmed. 45: stop. Latest case: trigger at 18:30, steps at 18:30, 18:45 and 19:00, stop at 19:15. The Duty manager is reachable until 19:00 and the Operations lead until 21:00, so every step falls in reachable hours.
Fallback: text to the Duty manager at 15 minutes.
Escalation: Operations lead, by text at 30 minutes. Phone call, their first preference, is not in place. Email, which the Operations lead has and which is in place, is not in their preference order and is not used (Q5).
Reply handling: staff app, the tap on "Taken" is the confirmation and is read; any other reply there is unread. Text, replies unread, so a reply to the text confirms nothing.
Repeat rule: not stated.
Delivery evidence: staff app and text, delivery report. Confirmation, the tap on "Taken" only.
Constraints applied: none.
Open points: Q1, Q2, Q3, Q4, Q5, Q6, Q11.
E3 Weather closure
Trigger: Operations lead sets the site to closed. Can fire: any time.
Urgency: Immediate.
Told: Customer (bookings that day), by text; by email where the booking record shows no text agreement (K3).
Confirmation: not needed.
Timing: Text at once between 08:00 and 20:00; a closure set outside those hours is held until the next 08:00 (K1). Customers with no text agreement are emailed at once.
Fallback: text not delivered, as the text service reports: email. Customers reached by email only: none possible, because email reports no delivery.
Escalation: not needed.
Reply handling: text, replies unread. Email, Front desk, inbox read 09:00 to 17:00.
Repeat rule: not stated.
Delivery evidence: text, delivery report. Email, sending accepted only, which is not proof of delivery.
Constraints applied: K1, the text is held outside 08:00 to 20:00; K2, the text carries no payment amount, which changes nothing in this event; K3, email only where the booking record shows no text agreement.
Open points: Q6, Q8, Q9, Q11, Q12.
E4 Low stock of helmets
Trigger: Stock count below 5. Can fire: weekdays 08:00 to 17:00.
Urgency: Routine.
Told: Stock clerk, by email. The staff app, which the Stock clerk has and which is in place, is not in their preference order and is not used (Q5).
Confirmation: not needed.
Timing: at once. Every firing falls inside the Stock clerk's hours.
Fallback: none possible, because email reports no delivery.
Escalation: not needed.
Reply handling: email, Front desk, inbox read 09:00 to 17:00.
Repeat rule: not stated.
Delivery evidence: email, sending accepted only, which is not proof of delivery.
Constraints applied: none.
Open points: Q5, Q6.
Events not planned
E5 Damage reported: urgency not stated. Q10.
Channels
Text: in place. Delivery status reported: yes. Replies: unread, no reader named. Used by: E1, E2, E3.
Email: in place. Delivery status reported: no. Replies: Front desk, inbox read 09:00 to 17:00. Used by: E1, E3, E4.
Staff app: in place. Delivery status reported: yes. Replies: the tap on "Taken" is the confirmation and is read (E2); any other reply is unread. Used by: E2.
Phone call: not in place. Delivery status reported: no. Replies: unread. Used by: none; skipped in E2.
Constraints applied
K1 No customer text before 08:00 or after 20:00. Applies to: Customer. Approved by: Service owner. Used in: E1, E3.
K2 No payment amounts in a text. Applies to: Customer. Approved by: Service owner. Used in: E1, E3.
K3 Text only where the booking record shows text agreement. Applies to: Customer. Approved by: Compliance lead. Used in: E1, E3.
Questions for the owners: 12
For Priya, integration owner
Q1. E2. The confirmation sign is the Duty manager's tap on "Taken", and the text at 15 minutes has no reply route, so a reply to it confirms nothing. Should the text carry a way to confirm?
Q2. E2. If nobody has confirmed 45 minutes after the trigger, the plan stops and nobody further is told. Who, if anyone, is told next?
Q3. E2. The only confirmation sign supplied is the Duty manager's tap on "Taken". If the Operations lead takes the matter on, how is that confirmed?
Q4. E2. The Operations lead's first preference, phone call, is not in place, so the plan uses text. Is text acceptable for an escalation?
Q5. E2, E4. The Operations lead has email and the Stock clerk has the staff app. Both are in place but not in their preference orders, so neither is used. Email reports no delivery, so a failed email to the Operations lead would not be seen; the staff app reports delivery. May either be used as well or instead?
For Marcus, service owner
Q6. E1 to E4. No repeat rule was supplied. If a trigger fires twice for the same payment, closure, return or stock count, should the person be told twice?
Q7. E1. A payment made after 20:00 is texted at 08:00 the next day under K1, although the urgency is Same day. Is a next-morning text acceptable? Customers with no text agreement are emailed at once.
Q8. E3. A closure set before 08:00 or after 20:00 is texted at the next 08:00 under K1, although the urgency is Immediate. Customers with no text agreement are emailed at once. Should closures be an exception to K1, or is the hold intended?
Q9. E1, E3. Customers whose booking record shows no text agreement get email only. Email reports no delivery, and its replies are read from 09:00 to 17:00. Is that enough, or should someone reach those customers another way?
Q10. E5. Damage reported has no urgency. What is it?
For the compliance lead, who answers consent and communication requirements
Q11. E1, E2, E3. Replies to texts, and any reply in the staff app other than the tap on "Taken", are unread. Who reads a reply that asks to stop or makes a complaint, and within what time?
Q12. E1, E3. The plan applies K3 as written and gives no view on whether it is enough. Is its wording complete?
Draft for Priya's approval of the design and Marcus's approval of message rules and timing. Nothing has been sent, connected or changed, and no message wording has been written.
Every line traces to the event definitions, recipient preferences, channel list and constraints supplied above, and to the default urgency scale, confirmation windows and channel suitability.
Where it fits
- Software technology, where product and billing events reach customers and on-call staff through several channels.
- E-commerce and retail, where order, stock and delivery events notify both customers and the team.
- Logistics and trade, where a late or missing item has to reach the right person within minutes.
- Business systems and integrations, which owns the connections that carry the events.
- Growth & scaling, when notifications built one at a time begin to collide.
- Established businesses, where old alerts still run and nobody remembers who reads the replies.
It is separate from internal change announcement, which announces one decided change to staff, and from email sequence drafting, which writes a series of emails. This plan writes no message; it decides how events reach people. Appointment confirmation and no-show follow-up prepares the contact for one kind of event.
What has to change for your company
Set your urgency scale and how long each level waits for a confirmation. Decide which channels suit which urgency. Name the roles that answer consent questions and read replies. Keep the channel list current, because the plan can use only what it is told is in place. Agree who approves a change to the plan after launch. The plan gives no view on consent or on any communication law; those answers come from the people responsible for them.
What has been checked
Fully Powered AI wrote this capability template. It was editorially reviewed on 10 November 2026. It was tried once on its invented example in Claude on 10 November 2026, and the record is published with it. Small edits made to the instructions and the example after that run have not been run again. It has not yet been tested in a client environment. It has not yet been tested as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on an event your integration owner already knows well, with cases written in advance: a channel that reports no delivery, an event with no urgency, a reply route nobody reads, a constraint that holds back an urgent message. The integration owner checks every line against the event definitions before anyone builds from it. Pilot acceptance-test preparation sets those cases up, and what we test before we call an AI workflow ready describes the record we keep.
The full capability template
Everything above is the outline. The complete capability template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this capability to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this capability template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: