01
Dedicated access entry
The customer receives its own URL and login entry instead of sharing one generic backend view with everyone else.
Delivery Assets & Entry Points
Deliverables
Delivery PackageDelivery is not just handing over one account. It should explain how the customer keeps using the system, how results are checked, and how future updates continue.
The focus here is the actual entries, instructions, and result paths that a customer receives.
A standard ExecFabric delivery usually includes one isolated access entry, one customer-specific capability set, and one documentation entry that stays usable for ongoing work. That means the package is not only an account sheet. It also includes result entries, notice entries, customer notes, and update notes.
Dedicated URLAccounts & permissionsCustomer notesResult entry
EXECFABRIC // DELIVERY KITDOC 10
const deliveryKit = ['site_url', 'account', 'docs_entry', 'result_entry']const supportEntry = ['platform_notice', 'tenant_notice', 'update_guide']const handoffGoal = 'usable_after_go_live'
HANDOVER SHOULD STAY USABLE
02
Accounts and baseline permissions
The customer receives accounts and permission boundaries for its own space instead of all-platform super-admin access.
03
Documentation entry
The customer receives notes on how to use the platform, how to keep updating it, and where notices or documentation are accessed.
04
Result and artifact entry
If the project includes file processing or result export, the package should also include entries for result viewing and downloading.
Delivery Table
What a customer usually receives in standard delivery
| Delivery item | What the customer gets / sees | Purpose | Always included? |
|---|---|---|---|
| Access URL | Their own login entry | Enter an isolated customer space | Usually included in standard delivery |
| Login account | Account, initial password, or initialization method | Enter the authorized capability range | Usually included in standard delivery |
| Customer-specific capabilities | The capability list authorized for the current project | Carry the customer's real usage scenario | Usually included in standard delivery |
| Customer usage notes | How to log in, execute, and review results | Lower the usage barrier after delivery | Recommended as a fixed inclusion |
| Implementation & training notes | Implementation steps, training targets, and support boundaries | Help the customer continue using the system clearly after go-live | Recommended as a fixed inclusion |
| Customer script hot-update notes | How scripts are added or updated later | Support continuous delivery | Recommended as a fixed inclusion |
| Notice / documentation entry | Notice entry, customer notice page, or other document entry | Support long-term customer usage | Opened per project |
| File upload / result download entry | Upload input files, inspect status, and download results | Carry file-oriented tasks | Opened per project |
Document Entry
What each document entry is for
- Customer usage notes explain how to log in, execute, and inspect results.
- Customer script hot-update notes explain how later update requests should be submitted.
- Notice or customer documentation entries support long-term usage instead of relying only on chat history.
- If the project includes file processing, the result view and result download entries should also be made explicit.
Key Points
Core coverage of the delivery package
- Which entries and notes the customer receives
- How notices, documents, and results are viewed after go-live
- When result download and file-processing entries are included
- How the package supports continued usage after delivery
Training
Why implementation and training are also deliverables
- Delivery does not end when the pages go live. It ends when the customer knows how to keep using and expanding the system.
- Different roles care about different things, so business owners, tenant admins, general users, and IT operations should be trained separately.
- If the project includes baseline support, the support window and support boundary should also be explained during handoff.
Implementation Page
Continue with training roles, implementation steps, and support boundaries
If you are deciding who learns what after go-live and how far support goes, the implementation page is the clearer next step.
Source Boundary
Standard delivery is not the same as a source-code buyout
- Standard delivery focuses on runnable entries, accounts, documentation, result entries, and the required handoff.
- Even if the customer uses an isolated server or isolated environment, that does not automatically mean a permanent license to the whole repository source.
- Source handoff, buyout, or broader authorization boundaries should be written separately into the quote and contract.
- If the customer asks whether source code is included, move to the dedicated boundary page and confirm it there.
Quote Template
Continue with source-delivery and authorization boundaries
When the discussion has already moved into questions like "does private deployment include source code" or "can source be bought out," the dedicated boundary page is the more efficient path.
After Go-Live
What the customer owns and what the platform owns after go-live
Customer side
- Log in through the dedicated entry and use capabilities inside the authorized range.
- Confirm whether the business outcome matches the expectation.
- Use the formal request path when scripts need updates or new capabilities are needed.
Platform side
- Guarantee tenant, permission, and execution boundaries.
- Handle review, registration, authorization, and follow-up update flow.
- Maintain notices, documents, and result entries within the project scope.
Next Read
Continue with file flow, onboarding preparation, and deployment mode
Once the discussion becomes formal, the focus is usually not abstract positioning anymore. It is aligning delivery, upload flow, and onboarding preparation in one pass.