Factories, chain operators and overseas partners do not all need the same capsule toy system. Some want consistent store management, some want their own branded portal, and others first need to establish whether their existing controller boards can connect. Describing these business differences before choosing a solution is often more useful than listing a large number of features.
AnyTake Orbit’s platform customisation introduction describes an approach built on existing platform capabilities, covering branding, organisation, equipment and workflows. The following guide is intended to support early discussions.
Four areas to discuss before customisation
- Brand portal: Define requirements for a dedicated domain, visual identity, customer portal and languages, distinguishing customer-facing services from internal tools.
- Organisational permissions: Define access by headquarters, region, store and role, and confirm data ownership and responsibility for daily operations.
- Device compatibility: Document machines, controller boards and connection conditions, then assess interface scope, stability and acceptance methods.
- Business rules: Turn replenishment, transactions, field service and exception handling into steps that can be carried out and checked.
Clarify delivery scope before independent deployment
A branded portal, an independent business environment and source-code delivery are separate matters; none automatically implies the others. During solution planning, confirm hosting location, data management, operational responsibilities, upgrade methods and support scope individually. Source code, licensing arrangements and fees also need separate agreement and cannot be inferred from “independent deployment”.
Step 1: document needs and the current situation
Prepare a one-page brief covering your role, existing equipment, expected pilot scale, target countries or regions, current business systems and the problem you most want to solve. Mark undecided items as requiring assessment, so ideas are not mistaken for conditions already in place.
Step 2: turn the solution into verifiable acceptance items
The discussion should answer three questions: what is included, what is outside scope and who determines completion? Device integration, for example, requires more than a connectivity demonstration. Both parties should agree on test equipment, test conditions and how results will be recorded.
Step 3: test the workflow through a limited-scope pilot
Use real equipment, locations and participants. We recommend covering normal operation and at least one exception scenario, while recording whether field staff can complete their work using the process. This produces feedback closer to operational needs than simply viewing administration screens.
Step 4: review results before deciding how far to expand
After the pilot, review connection stability, the burden on field staff, data reconciliation and exception handling before deciding whether to extend to more devices, stores or regions. Expansion should follow actual results, without assuming fixed returns or a uniform launch timetable.
What should you bring to the next discussion?
Equipment and controller-board documentation, a list of organisational roles, your target market, intended start date and one current business workflow can help the assessment team choose between standard capabilities, module configuration, extension development and independent deployment. The specific solution and delivery terms remain subject to agreement between the parties.
Read about Orbit platform customisation · Submit system customisation and pilot requirements