Onboarding Planning

Planning for Onboarding

From the point of view of the 3PL business, onboarding is the process of bringing on new clients. From a systems point of view, a 3PL client takeon should be thought of as a project in itself.

For straightforward or vanilla implementations which largely involve just a replication of an existing configuration, the project will be small in scope. However, for larger, more bespoke clients, the takeon may be a significant project in itself. It is very helpful to think about the task in those terms, so that each project can be planned and managed appropriately.

The planning stage involves two main activities:

Requirements Gathering to determine the scope and to get an indication of the likely cost of the project.
Activity or Task Planning to ensure that the necessary activities are effectively planned, both in terms of resource requirements and timing.

High Level Requirement Considerations

It is very useful to have a high level understanding of what types of tasks are involved during an onboarding process, and at least an order of magnitude understanding of effort that may be involved.

In this section we detail some of the areas in which requirements may vary considerably, and what impact this can have on the effort required.

The table below gives an indication of some of the example requirements which may determine the overall effort. In the table below, we classify these example requirements according to whether they are simple, medium or complex. Needless to say, the amount of time that you would need to budget can vary greatly depending on whether we are dealing with a simple or complex requirement.

Example Requirements

Areas to Consider	Simple Requirement	Medium Requirement	Complex Requirement
Basic Setup	Customer does basic setup without supervision	Customer does basic setup with supervision	All setup done by Realtime Despatch
Project Management	No project management required	Project management done by customer	with involvement of Realtime Despatch
e-Commerce Integration	Replicate setup from existing channel	Make use of existing integration with bespoke elements	New bespoke e-Commerce integration
Data Import Rules	Use import rules from 'cloned' channel	Simple bespoke import rules	Complex bespoke import rules or data transformations
Courier Integration	Reuse existing courier integration	Make use of existing courier integration, but with different services or destinations	New courier integration
Courier Selection	Reuse existing courier selection logic	Simple bespoke courier selection logic	Complex bespoke courier selection logic
Customer Paperwork	Reuse existing paperwork with different logo	Simple bespoke despatch note	Complex bespoke despatch note
Reporting and Dashboards	Enable existing reports	Simple additional reports for client	Complex reporting requirements for clients

It may not be helpful to try to put a specific time estimate of the above elements, but the following yardstick may be useful:

the Simple Requirements described above are ones that could be managed as part of the overall project effort, with each individual task likely to involve 2 hours or less of effort
the Medium Requirements are ones which would need to be project managed individually as separate pieces of work, but would tend to be measured in hours rather than days of effort. We would ordinarily seek approval for the work required for these tasks.
the Complex Requirements are ones that individually may require anything around one or two days of effort to a number of weeks, depending on the area. These we would not undertaken without specific approval to proceed with the work required.

Requirements Scoping

The details discussed in the previous section will hopefully help determine how you as the 3PL should be positioning your commercial offering client prospects.

In order to translate this into a specific project plan, it is useful to get as much detail as possible on the requirements for the project. For this reason, requirements gathering is a task typically undertaken by the 3PL in direct consulation with the client. Realtime Despatch does not maintain any direct relationship with 3PL clients unless this is necessary to address specific questions or technical issues.

In many cases, it will be appropriate to get this information before committing to take on the new client. This can be helpful not only in planning internally for warehouse activity, but also for planning for the system tasks required to bring the customer on, and for ensuring that there is a shared understandng on the cost implication of a new client takeon.

Some of the key questions that should be covered as part of this requirements gathering process are listed below.

Overall Profile

These questions are around the client's business, in terms of its nature and scale.

Does the new client have an existing business (i.e. a current daily order load), or is this a new business?
What order volumes will need to be fulfilled? Will orders be received continuously, daily or only sporadically?
How many SKUs will the 3PL be maintaining stock for the client?
What is the profile of the orders in terms of average number of lines, proportions of single line and single item orders?
To what destination countries is the client shipping?

Answers to the questions above will give an indication of the likely scale and complexity of the implementation task, and the likely benefits of customising the implementation to match the client's order and product profile. It will help to determine what kind of customisation is viable from a cost/benefit point of view.

Sales Channels

If the client is operating multiple sales channels, then there are some additional questions to consider:

How many sales channels will present orders to the OrderFlow platform?
Are orders from multiple sources going to be received from a single channel (i.e. Amazon and eBay orders routed through the shopping cart)?
Are these sales channels supported by existing integration modules available within OrderFlow?
Will all of the sales channel share the same product catalogue?
Are all SKUs uniquely identified with a single reference that is used by all the sales channels? Will this reference be contained within the order data received by OrderFlow?
Is there a 'master' channel that the client uses to maintain an overall view of products and inventory across the sales channels?
Do the stock updates pushed to different sales channels need to be configured to minimise the risk of overselling?

Answers to the questions above will help identify complexities in the implementation that will require careful consideration and potentially implementation effort.

e-Commerce Integration

These questions deal with the mechanics of getting the details of products and orders from the client's e-Commerce system into OrderFlow, Where appropriate, it will also cover notifications on shipments, stock updates, and returns from OrderFlow to the client's e-Commerce system.

Note that if more than one integration is required for different sales channels, these questions will need to be specified separately by sales channel. It also covers the any notifications that go from OrderFlow to the e-Commerce system, for example, to handle stock updates and shipment despatch notifications, plus any other integration requirements.

What type of integration will be used for the client? Options here are direct integration using the e-Commerce system's API, direct integration using the OrderFlow API, or indirect integration using file transfers?

If we are planning to use direct integration using the e-Commerce system's API, then the following questions are applicable:

What e-Commerce system is the client using? Is this a system for which there is already an integration with OrderFlow?
Does the client have a test instance of their e-commerce system(s)? This will make the implementation much easier!
Are there any non-standard configuration points in the client's e-commerce system(s)? Are we able to use use out-the-box integrations?
What data flows need to be covered in the integration? The most widely used data flows are order import, product import, inventory notification, and shipment despatch notification.
Does pricing information need to be captured for the purposes of reporting or paperwork generation?

Products

The following are more detailed questions about the product that will have an impact on the customer takeon requirement.

What is the nature of the products that the client is selling, in terms of size, average value?
Will all the SKUs be uniquely barcoded when they are received, or is there a requirement to add individual barcodes to some or all products while receipting?
Is there a need to support anything other than the 'default' product type? Examples of other product types include kits, product bundles, tracked products, virtual products etc.
Do different SKUs need to be need to be held in specific types of location or in distinct areas of the warehouse?
Do products need to be batch-tracked, or do they have expiry dates?

Depending on the answers to the above questions, setup will be required. In the most simple case, the 3PL will be fulfilling simple products that have been barcoded prior to being received in the warehouse.

Courier Integration

This concerns the choice and use of couriers for shipping of parcels to the end customers.

Which couriers and courier services are required to support the client?
For which of these is international shipping required? Please specify country destinations.
Are these courier services supported by existing integration modules available within OrderFlow?
Do you the 3PL already have established relationships, both technical and commercial, with the courier required for integration?
Will the client be using their own courier customer accounts, or will they be using those held by the you the 3PL?
Will the order information received from the client specify which services should be used, or does OrderFlow need to apply custom logic to determine the appropriate choice?
Is the courier selection logic channel specific?

Of course, the effort required for the implementation may vary considerably depending on the answers to the questions. If the new client is using the same courier services and logic already implemented elsewhere on the system, then the implementation effort may be trivial. However, if new courier logic, services, destinations or even integrations are required, the effort required will be more substantial.

Some further questions that will need to be verified with the client prior to agreeing to implementation:

Will the information required to apply courier selection logic always be available as part of either the order or product data? For example, will weights always be part of the product definition if they are required to calculate a shipment weight?
If orders need to be shipped internationally does the product or order information contain the information required to create the necessary customs information?**

Locations

Although not a prerequisite of the OrderFlow environment most 3PLs prefer to dedicate specific areas within the warehouse to each client. Locations can be restricted to a single client organisation or can be shared.

Incoming locations within the Goods-Inward area and mobile locations used for picking are typically defined as shared. A typical configuration will ensure that most pick locations, bulk storage locations and return locations are client specific but may also define an area of shared space to allow for occasions when a dedicated areas becomes full.

Will the new client require new locations to be created (both physically and within OrderFlow) or can existing locations be assigned to them?
Does the client stock require locations if different sizes or types (e.g. shelves, bins and pallet spaces).

Paperwork

The primary consideration here is around the use of the despatch note that is included with each shipment to the end customer?

Will the new client require a custom despatch note, or are they happy to have their logo a standard despatch note or one used by an existing client?
Can the client provide an example of the required paperwork?
Does the despatch note documentation need to be multilanguage and display non-ASCII characters?
Are there any specific fonts that need to be installed to render or print the despatch notes?
Does the paperwork contain pricing details? Is OrderFlow required to calculate any of the pricing elements or is all the necessary information contained within the order data received from the sales channel?
Are there any variable elements that require logic to be embedded in the paperwork? For example, should new customers receive a 'welcome' note, or is there an integrated courier label?
Is product specific paperwork required (OrderFlow datasheets)?
Is a returns label and/or returns form required?
Is the paperwork channel-specific? If not, then please specify which existing paperwork should be used.

If a bespoke despatch note is required, the effort required will of course depend on the complexity of requirement, and how accurately this can be conveyed to the Realtime Despatch Customer Delivery team.

Note that some of our 3PL customers have developed an in house capability of producing their own despatch note. This is helped OrderFlow's ability to test the production of despatch notes.

Returns

Requirements relating to returns (if present at all) can very from the use of the basic out of the box features right through to more complex workflows involving integration with third party systems.

Do customer returns need to be supported?
Does the returns process differ from those already supported for other clients? If not, please specify if appropriate which existing process to use.
Does the returns process require any integration with client systems? These may, for example, create an RMA or pass back details of the returns that have been processed by OrderFlow.
What information does the client need to process customer refunds or trigger the despatch of replacement items?
Is the returns process channel-specific?

If any non-standard returns related requirements are present, these will need to be scoped as part of planning for the project implementation.

Client Access

OrderFlow can be optionally be configured to allow the client access to the system on a read-only basis.

Will the client require read-only access to OrderFlow?
Will the client need to be given the ability to make any specific targeted changes within the OrderFlow environment?

Note that specific client access requirements will need to be scoped if present, and will certainly need to additional configuration work (assuming development changes are not required).

Workflow and Business Rules

This concerns whether there are any custom workflow or business rules required for the client.

What Service Level Agreements have been made with the new client? For example, are there any cut-off times for same day despatch?
Will there be any client-specific picking required?
Are there any other specific workflow rules or processes required for the client? For example, is there a need to hold certain shipments for approval, etc.
Is there any need to ringfence stock by channel? For example, is there any need to separate stock that can be used for trade as opposed to consumer orders

Again, the implementation effort will depend on whether it is possible to reuse the rules already being applied for an existing client, or whether there are new rules to consider.

Reporting and Dashboards

OrderFlow can be configured to provide additional management information and operation capability through custom reports and dashboards.

Will the new client need access to any new reports or dasboards that are not already provided to existing clients?
Do these need to be defined as automated periodic reports or will the client run them manually from within OrderFlow?

Note that it is possible for 3PL technical staff to be trained in providing reports. A knowledge of SQL is required. Custom reports provided by Realtime Despatch can vary greatly in complexity and preparation time, from around an hour or two in simple cases through to days in more complex cases.

Billing

If you are using OrderFlow's billing module, then the following applies:

Will the billing metrics differ from those already supported for other clients?

If custom metrics are required, we will request further detail on the specific metrics that will be used for the client.

Purging and Anonymisation

Data that is received from clients may need to be anonymised and will eventually be purged from the system. The following questions apply here:

Has the data purging policy in place within the live OrderFlow environment been made clear to the client?
Does the client have any specific requirements for the anonymisation of their data?

Timing

The timing of a new client implementation may have to be carefully coordinated to avoid any business disruption for the client. The receipt of stock is obviously required for a new client to go live, but planning is required to ensure that the stock can be checked in without due delay after arrival. We request that you be able to answer the following questions prior to agreeing to the client takeon.

Where is the stock (physically), and when will it arrive in the warehouse?
Are you able to control and/or carefully coordinate the timing of the go-live?? This is to help ensure that it is properly supported by Realtime Despatch and can proceed smoothly?

Project Phases

As with an entirely new OrderFlow implementation, a 3PL client implementation can be divided into different stages. While the project is progressing, it is useful to be aware of these phases, and in particular, into what phase particular activities fall. In some cases, it may be necessary to have formal sign-off on the phases.

The different phases are shown in the diagram below, and described in the section that follows.

Phases

Planning

This involves identifying the scope of the project, and involves getting answers to the questions covered in the previous section.

Preparation

This involves preparing any solutions for complex configuration, paperwork, etc., and is done initially outside of the live OrderFlow instance.

Setup

Execute the steps to put the client live in 'test mode'. Normally the new client's organisation and channel on OrderFlow have a 'test' status. This allows for example for test orders to be received, processed, and subsequently cleared down.

Any other configuration changes required to support testing and subsequent go-live are applied at this point.

Testing

This involves executing processes end to end on the live system, but in test mode. Because of the test status of the new client's organisation and channel, processes can be tested end-to-end as many times as is necessary to ensure that you the 3PL are properly prepared for processing live orders.

The orders are typically sourced from the client's test system, as they may be updated as part of end-to-end testing.

At this point verification should take place on all interactions with the e-Commerce system, as well on courier integrations and the format and content of labels and despatch notes.

The mechanics for ensuring that the client's correct stock position can be reflected at the point of go live are also tested.

Go Live

Here the client's organisation and channel will be switched to live status following the input of the correct stock position. Connectivity is switched over to live systems, so that from this point onwards, live orders from real end users can be processed.

The Go Live phase is completed when all of the processes are fully operational, and have been verified against the requirements identified during the Planning Phase.

Responsibility Matrix

As you as a 3PL become more experienced in working with OrderFlow and bring new clients onto the system, you can expect responsibility for different parts of the process will increasingly move from Realtime Despatch to your own organisation. Encouraging this process will help with cost savings, in allowing you to make better use of your 'in house' resources, and avoid unnecessary Realtime Despatch consultancy charges.

The Responsibility Matrix table below shows how this responsibility may evolve from the earlier days with the first client implementations through to a situation of greater self-sufficiency and independence.

Responsibility Matrix

Project Phase	Initial Responsibility	Target Responsibility
Planning	Led by 3PL with assistance from Realtime Despatch	Fully managed by 3PL. Involvement from 3PL in planning for advanced tasks
Preparation	Performed by Realtime Despatch	Performed by 3PL
Setup	Performed by Realtime Despatch	Performed by 3PL
Testing	Performed by 3PL with some backup support from Realtime Despatch	Performed by 3PL, generally without support
Go Live	Coordinated with direct Realtime Despatch Involvement	Performed by 3PL, with Realtime Despatch available for support if necessary

Realtime Despatch is able to provide advanced technical training to help foster greater autonomy in carrying out customer implementations.

In the next section of the document, we go through the main technical tasks that are associated with each phase in the project implementation.