Capability template for business systems and integrations
Service inbox routing plan
When a new service inbox is being set up, the service owner gets a routing plan: each approved address, the queue it should reach and who owns it, checks to run before it goes live, and the wrong-address risks, loop risks and unconfirmed queue owners still open. Nothing is configured.
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 a new service inbox goes live, the service owner can see on one page where every approved address leads. Each address has a queue it should reach, a named owner for that queue and a short list of checks someone can run once the setup is done. Where the company's current settings already send an address somewhere else, the plan shows the path step by step and says what would have to change.
The plan also lists what could go wrong, in plain terms. An address that looks almost like another one, a forward that ends in one person's mailbox, a chain of forwards that comes back to where it started, an automatic reply that could be answered by another automatic reply, a queue whose owner nobody has confirmed. Nothing is smoothed over: a gap stays a gap until a person fills it.
The systems administrator approves any configuration. The service owner accepts how the routing will behave before the inbox is switched on. The AI assistant changes no mailbox, address, rule or setting, and sends no test message.
Who starts the work, and when
The service owner, or the person helping them, starts it when a new service inbox needs a routing plan and the list of addresses has been approved. It can be run again whenever the list, a queue owner or the current settings change, so the plan always shows what is still open.
The systems administrator supplies the current settings and makes any change. The queue owners confirm that they own their queues.
What they supply
- Plan settings: the business, the service, the service owner, the administrator, the date, the company's email domains, the planned activation date and a line saying what the system does with automatic messages such as out-of-office replies.
- The approved addresses, one row each, with its purpose, who approved it and when, the queue it should reach and whether it sends an automatic reply.
- The current settings: every address, alias, forward and mailbox that exists today and where each delivers.
- The queues, with an owner, whether the owner has confirmed, opening hours and a backup.
- Test scenarios, if the service owner already has some: what is sent to which address and where it should land.
No connection to a mail system is needed, and the capability never asks for a password, a login code or a key.
What comes out
One plan in a fixed order. It opens with a summary and gives a block for each approved address: its purpose, the queue and owner, the path it takes today, the proposed routing and the change the administrator would need to consider. It then lists the queues, the other addresses found in the current settings, the checks to run before activation, and a numbered register of wrong-address risks, loop risks, unconfirmed queue owners and other gaps.
It ends with the two decisions that belong to people and a line saying nothing has been created, changed or sent.
An invented example
Illustrative example with invented data. The business, its addresses (on the reserved example domain), the roles, the help desk and every date below are invented. Client N is an invented online kitchenware retailer opening a returns inbox. In this example the service owner is the customer care manager. First come the inputs supplied, in full, then the plan the capability returned.
The inputs
1. Plan settings
Business: Client N (an invented online kitchenware retailer)
Service: Returns inbox
Service owner: Customer care manager
Administrator: Systems administrator
Prepared for: Customer care manager
As-of date: 2026-11-10
Planned activation date: 2026-11-23
Company domains: clientn.example
Automated mail handling: Out-of-office replies are discarded; bounces go to the Returns queue
2. Approved addresses (addresses.csv)
address,purpose,approved_by,approved_date,intended_queue,auto_reply
returns@clientn.example,Customers asking to return an order,Customer care manager,2026-11-04,Returns,yes
exchanges@clientn.example,Customers asking to swap an item,Customer care manager,2026-11-04,Returns,no
refunds@clientn.example,Customers asking when a refund will arrive,Customer care manager,2026-11-04,Billing queries,yes
3. Current settings (current_settings.csv)
name,kind,delivers_to,status
care@clientn.example,shared mailbox,General,in use
return@clientn.example,alias,care@clientn.example,in use
exchanges@clientn.example,forward,priya@clientn.example,in use
priya@clientn.example,personal mailbox,,in use
refunds@clientn.example,forward,finance-queue@clientn.example,in use
finance-queue@clientn.example,forward,refunds@clientn.example,in use
4. Queues (queues.csv)
queue,owner,owner_confirmed,hours,backup_owner
Returns,Returns coordinator,yes,Mon-Fri 09:00-17:00,Customer care manager
Billing queries,Accounts receivable clerk,no,Mon-Fri 09:00-17:00,
General,Customer care manager,yes,Mon-Fri 09:00-17:00,Returns coordinator
5. Test scenarios (scenarios.csv)
scenario_id,sent_to,sender_kind,description,expected_queue
T1,returns@clientn.example,outside customer,Customer asks to return a mug,Returns
T2,exchanges@clientn.example,outside customer,Customer asks to swap a size,Returns
T3,refunds@clientn.example,outside customer,Customer asks where a refund is,Billing queries
T4,support@clientn.example,outside customer,Customer writes to an old address,General
The plan
SERVICE INBOX ROUTING PLAN: Returns inbox, Client N
For: Customer care manager (service owner). Administrator: Systems administrator. As of 2026-11-10. Planned activation: 2026-11-23.
SUMMARY
Addresses planned: 3 (1 not set up, 2 set up differently, 0 matching today).
Not approved, left out: none.
Open items: 5 (3 wrong-address risks, 1 loop risk, 1 unconfirmed queue owner, 0 other gaps).
Checks: 9 prepared; 4 supplied (3 compared with the plan, 1 outside the approved list).
ADDRESSES
returns@clientn.example
Purpose: Customers asking to return an order. Approved by Customer care manager, 2026-11-04.
Queue: Returns. Owner: Returns coordinator (confirmed). Hours: Mon-Fri 09:00-17:00. Backup: Customer care manager.
Auto-reply: yes
Today: not set up.
Proposed routing: returns@clientn.example -> Returns
Change from today: create the address and deliver it to Returns.
Risks: 1
Checks: V1 to V3
exchanges@clientn.example
Purpose: Customers asking to swap an item. Approved by Customer care manager, 2026-11-04.
Queue: Returns. Owner: Returns coordinator (confirmed). Hours: Mon-Fri 09:00-17:00. Backup: Customer care manager.
Auto-reply: no
Today: exchanges@clientn.example -> priya@clientn.example (personal mailbox). Ends there.
Proposed routing: exchanges@clientn.example -> Returns
Change from today: deliver the address to Returns in place of the forward to priya@clientn.example.
Risks: 2
Checks: V4 to V6
refunds@clientn.example
Purpose: Customers asking when a refund will arrive. Approved by Customer care manager, 2026-11-04.
Queue: Billing queries. Owner: Accounts receivable clerk (not confirmed). Hours: Mon-Fri 09:00-17:00. Backup: none named.
Auto-reply: yes
Today: refunds@clientn.example -> finance-queue@clientn.example -> refunds@clientn.example (loops back).
Proposed routing: refunds@clientn.example -> Billing queries
Change from today: deliver the address to Billing queries in place of the forward to finance-queue@clientn.example; the forward from finance-queue@clientn.example back to this address is the loop.
Risks: 3, 4, 5
Checks: V7 to V9
QUEUES
Returns: owner Returns coordinator (confirmed); hours Mon-Fri 09:00-17:00; backup Customer care manager. Reached by: returns@clientn.example, exchanges@clientn.example.
Billing queries: owner Accounts receivable clerk (not confirmed); hours Mon-Fri 09:00-17:00; backup none named. Reached by: refunds@clientn.example.
General: owner Customer care manager (confirmed); hours Mon-Fri 09:00-17:00; backup Returns coordinator. Reached by: no address in this plan.
OTHER ADDRESSES IN THE CURRENT SETTINGS
care@clientn.example (shared mailbox) -> General. Not part of this plan.
return@clientn.example (alias) -> care@clientn.example -> General. Looks like returns@clientn.example (risk 1).
priya@clientn.example (personal mailbox), ends there. On the path of exchanges@clientn.example (risk 2).
finance-queue@clientn.example (forward) -> refunds@clientn.example. On the path of refunds@clientn.example (risks 3 and 4).
CHECKS TO RUN BEFORE ACTIVATION
Run each check only after the Systems administrator has made the change shown for its address and the Customer care manager has accepted the behaviour. The plan sends nothing.
Supplied by the service owner:
T1: returns@clientn.example, outside customer. Expected Returns. Plan: Returns (agrees). Today: not set up.
T2: exchanges@clientn.example, outside customer. Expected Returns. Plan: Returns (agrees). Today: ends at the personal mailbox priya@clientn.example.
T3: refunds@clientn.example, outside customer. Expected Billing queries. Plan: Billing queries (agrees). Today: loops.
T4: support@clientn.example, outside customer. Outside the approved list: no routing is planned for it. Add the address to the approved list or drop the scenario.
Prepared by the plan:
V1: returns@clientn.example. A plain message from an outside sender. Expected: lands in Returns; one auto-reply goes to the sender.
V2: returns@clientn.example. An automatic out-of-office message from an outside sender. Expected: Out-of-office replies are discarded; bounces go to the Returns queue.
V3: returns@clientn.example. Risk check for risk 1: a plain message to return@clientn.example from an outside sender. Expected: whatever the service owner accepts for that address; today it reaches General.
V4: exchanges@clientn.example. A plain message from an outside sender. Expected: lands in Returns; no auto-reply.
V5: exchanges@clientn.example. An automatic out-of-office message from an outside sender. Expected: Out-of-office replies are discarded; bounces go to the Returns queue.
V6: exchanges@clientn.example. Risk check for risk 2: a plain message after the change. Expected: lands in Returns; nothing arrives in priya@clientn.example.
V7: refunds@clientn.example. A plain message from an outside sender. Expected: lands in Billing queries; one auto-reply goes to the sender.
V8: refunds@clientn.example. An automatic out-of-office message from an outside sender. Expected: Out-of-office replies are discarded; bounces go to the Returns queue.
V9: refunds@clientn.example. Risk check for risks 3 and 4: a plain message. Run only after the loop is removed. Expected: lands once in Billing queries; no delivery to finance-queue@clientn.example.
RISKS AND GAPS
Wrong-address risks
1. returns@clientn.example: return@clientn.example is in use and looks almost the same (the final "s" differs). It delivers to General through care@clientn.example. To resolve: the service owner and administrator decide whether return@clientn.example stays, is redirected or is retired. Who can supply: Customer care manager.
2. exchanges@clientn.example: today it ends at the personal mailbox priya@clientn.example, not at Returns. To resolve: the administrator changes the delivery once approved. Who can supply: Systems administrator.
3. refunds@clientn.example: the path passes through finance-queue@clientn.example, which is not on the approved list. To resolve: the service owner approves it or the administrator removes it from the path. Who can supply: Customer care manager.
Loop risks
4. refunds@clientn.example: the path returns to refunds@clientn.example (refunds@ -> finance-queue@ -> refunds@) and auto-reply is on. To resolve: the administrator removes one forward. Who can supply: Systems administrator.
Unconfirmed queue owners
5. Billing queries: owner Accounts receivable clerk has not confirmed, and no backup is named. To resolve: the owner confirms and a backup is named. Who can supply: Customer care manager.
Other gaps
None.
Next step: The Systems administrator approves any configuration. The Customer care manager accepts the routing behaviour before activation on 2026-11-23. No address, mailbox, rule or setting has been created, changed or connected, and no test message has been sent.
Every path and value traces to the plan settings for Returns inbox and the approved addresses, current settings, queues and scenarios supplied. The plan changes nothing and sends nothing.
Where it fits
- Business systems and integrations, where the owner of the systems has to know what a new address will do before it is switched on.
- Customer support and service, where a service inbox feeds a queue that people have to staff.
- Software and technology, where support and billing inboxes multiply with each product.
- Ecommerce and retail, where returns, refunds and order questions each get their own address.
- Professional services, where a shared client inbox replaces a partner's own mailbox.
- Growth & scaling, when addresses accumulate faster than anyone records where they go.
- Established businesses, where old forwards and aliases still sit under the new setup.
It does not sort the mail that arrives (inbox triage), set reply targets (support service level definition) or sort tickets once they exist (support ticket triage). It covers the step before those: where each address leads.
What has to change for your company
- Your domains. List every domain that counts as yours, so the plan can tell an internal address from one outside.
- Your words. Use the kinds your mail system uses for an address, alias, forward, shared mailbox and personal mailbox, or rename them once to the defaults. When a header does not match, the assistant stops and asks.
- Your queues and owners. Name each queue as your help desk does, and say who owns it and who covers.
- Your automatic messages. State once what your system does with out-of-office replies and bounces, so the plan can check for loops.
- Your sign-off. Decide who is the systems administrator and who is the service owner for each inbox.
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, on an earlier wording of the instructions, in Claude on 10 November 2026; the run was not blind, and the record is published with it. It has not been tested in a client environment or as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on an inbox your administrator has already set up, with cases written in advance: a forward that loops, an address one letter from another, a queue with an unconfirmed owner, an automatic reply with no stated handling. The administrator checks every path against the real settings before anyone relies on 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: