Implementation to Support Handover | Internal Support Hub

The gate

What delivered means

A project is delivered when both conditions are met. One without the other is not enough.

Condition 1

Customer sign-off

The customer has formally signed off on the delivered scope, and the sign-off is recorded in the Project Closure Survey.

Condition 2

Handover accepted by Support

Support has received the full handover package, reviewed it, and confirmed it can operate the project.

Going live is not the same as delivered. A project can be live for the customer and still not be delivered to Support.

Who does what

Roles

Implementation owns the project until the gate. Success owns it after. Support decides whether the package is complete.

Role	Team	Responsibility
Implementation Project OwnerIPO	Implementation or partner	Completes the closure documents, prepares the handover package, triggers the handover and makes sure every document and environment is accessible.
Project ManagerPM	Implementation or partner	Prepares the handoff documents and coordinates the meetings.
Support team	Support	Reviews the package, checks access, and accepts the handover or returns it with a list of gaps.
Customer Success ManagerCSM	Success	Takes ownership of the customer relationship after the handover and runs the onboarding meeting.

Step by step

Procedure

Four steps, in order. Step 2 is the gate: nothing moves to Success until Support accepts the package.

1
Project closure and documentation

Owner: IPO

Complete the Project Closure Survey and the handover package: customer use cases and workflows, expected support requests, performance benchmarks, and the four core items described below.
- Project sign-off obtained from the customer and submitted through the survey
- Performance analysis completed
- Access granted to every environment Support needs
- Repositories transferred to the main Threekit GitHub organization
- Custom apps registered in Salesforce with repo, hosting and domain
- Handover document uploaded to Salesforce and Google Drive
2

Documentation review

Owner: Support team

Support reviews the package internally and tests access to each repository, hosting dashboard, log source, Threekit org and admin tool listed in the inventory. If anything is unclear, Support schedules a working session with the IPO.

Outcome: Support either accepts the handover, or returns it to the IPO with a written list of gaps. A returned package goes back through step 1 for the missing items only.
3

Notify Success and prepare the transition

Owner: IPO

Once Support has accepted, send the Project Closure Survey and the handover package to the CSM.
4
Customer onboarding meeting

Owner: CSM

Organize the Customer Success onboarding meeting with the customer and Support.
- Introduction to Support, up to date
- Support processes, priorities and communication channels
- How to log a case, and the support metrics the customer can expect
- The customer contacts who will log cases are named and introduced to Support
- The customer knows what they can do on their own, and what requires a case

What Support receives

The handover package

Every project, whatever its architecture, comes with these four items. They are the minimum Support needs to see what was built, where it runs and how to operate it.

Architecture diagram

One diagram of the whole solution, readable by someone who did not build it.

Every component: front-ends, back-ends, admin tools, webhooks, AI services
External systems and how data flows between them
Who owns each block: Threekit, partner or customer

Data and deployment inventory

Where every piece lives, component by component.

Repository, GitHub organization and branch model
Hosting platform and domains per environment
Threekit orgs and tenants in use
Where product data lives and how it syncs

Access

Support can open everything in the inventory before accepting the handover.

Repositories in the main Threekit GitHub organization
Hosting dashboards and logs
Threekit orgs, tenants and admin tools
Secrets kept in the secret store, never pasted in documents

Runbook

How the project is operated day to day.

Recurring operations, such as data syncs, publishes and content updates, with their steps
What the customer can do self-serve, and what needs Threekit
Known issues and their resolutions
Monitoring and escalation path

Supporting sections of the handover document

The handover document template also covers the following. Open each section for the full list.

Project overview 5 items

Customer needs
Key stakeholders, on the customer side and in the implementation team
Delivered configurators: URLs, public or private, and how to access them
Configurator functionality and system integrations
End-user personas

Technical documentation 8 items

Detailed architecture: data flow, front-end and back-end
Integrations requiring maintenance, and their owner
Custom apps involved, their purpose and their maintenance owner
Threekit org structure: assets, attributes, rules, logic, data organization
Threekit features used: Production Data, Renders, Configurations, Orders, Webhooks, Data Tables, Pricing, Apps, Languages
APIs and external services, with where their credentials are stored
Tech stack: front-end, e-commerce platform, back-end (API type, database, job queue, email service)
Code repositories and branch management

Performance analysis 6 items

Test environment: device, OS, browser, processor, RAM, internet speed
Initial loading time, from Performance Insights and the Network tab
Player fetch timing: as early as possible, pre-fetch recommended
Player initialization timing
Platform caching: CF-Cache-Status HIT is expected, MISS or BYPASS is an issue
Static Publish enabled or not

From Support's side

Why each item matters

Seen from Support, each gap in the package turns into a specific problem after go-live.

No diagramSupport cannot tell which component is failing, or who should fix it. Every case starts with an investigation of what was built.

No inventoryProjects use different GitHub organizations, hosting platforms and domains. Without a list, Support has to rebuild the map from Salesforce, Slack and the hosting accounts.

No accessSupport cannot debug or maintain what it cannot open. Repositories left in organizations Support has no access to block every fix.

No runbookManual operations that only the builders know, such as an on-demand data sync, come back as a new case each time the customer needs them.

No introductionCases arrive from customer contacts who were never onboarded, about tools they were never shown how to use.

The handover comes before any discussion of support scope or ownership. Questions like what Support covers, or what the customer runs on their own, can only be answered once everyone agrees on what was delivered.

1

Clarify what was delivered

2

Document it to this standard

3

Hand it over to Support and the customer

4

Decide scope and ownership

Ownership is then agreed with each customer, using the architecture diagram. Blocks Threekit owns fully come straight to Support. A customer with a web team can take over parts like the UI, while back-end, AI configuration and tenants are decided customer by customer.

Who hands over

Implementation partners

Handovers come from internal Consulting or from external partners. The standard is the same for all of them. Completeness varies by partner, so Support flags gaps during the step 2 review.

Elementals
Zaelab
Digitize
Source 360
Balink
VO2
EY
Capgemini

Quick reference

Acceptance checklist

Support accepts a handover when every line below is true.

Customer sign-off recorded
Architecture diagram covers every component and owner
Inventory lists repo, hosting, domains and orgs per component
Repositories in the main Threekit GitHub organization
Custom apps registered in Salesforce

Support access tested on everything in the inventory
Runbook covers recurring operations and self-serve limits
Known issues and monitoring documented
Performance analysis completed
Customer contacts introduced to Support