Custom B2B customer onboarding software

The user list arrived. The import has to wait.

Suppose a customer is starting a data reporting service. They have sent the list of people who will use it. Access to their data source still awaits their IT contact, so the implementation team cannot try the import yet.

The customer should be able to see that their file arrived and find the outstanding request for data access. That request needs to say who should handle it and why it is needed. The person coordinating the launch for the customer can then ask their own IT team directly, without another email to the provider asking for a progress update.

The implementation team needs to see, alongside the import task, that it is waiting for access from customer IT. This is a task dependency: completing one task allows another to begin. When the IT contact responds, the implementer can check access and try the import. The coordinator can find that response in the same place without asking both sides what happened.

This does not require an elaborate dashboard. A clear description, an owner, and an explanation of what is outstanding may be enough for each step. The main change is in the coordinator's work: they return to the same record the customer sees instead of reconstructing progress from email.

Your current tool may already support this

Standard project software includes task dependencies. Asana documents marking tasks as blocking or blocked by other tasks. Once all blocking tasks are complete, the person assigned to the next task receives a notification. Feature availability depends on the plan (Asana task dependency documentation).

Before commissioning an application, walk through the example in your current system. Can the customer see that the user list arrived while the access request remains open? Can the implementer see why the import is waiting? If so, the work may largely involve organizing tasks and agreeing who confirms completion. A dependency feature will not create that clarity if the team records all preparations as one task called “customer materials.”

Also look at the project from the customer's account. Asana supports guests who can see content explicitly shared with them. Sharing a task gives access to that task; sharing a project exposes all its tasks (Asana guest permissions). If the team keeps internal notes there too, choose a sharing arrangement that fits what the customer should see. Review the actual guest view.

When the customer's contact changes

Return to the access request. If the IT contact hands it to a colleague, that person needs to know what was requested and what has already been discussed. The coordinator should be able to transfer the open task with its conversation, preserving earlier responses. The team is still waiting for access to the same data source. Changing the contact should not mean starting the request again.

Agree with the customer who is taking over and whether the previous contact remains involved. If that person leaves the company, their access needs to be removed. The implementation history should remain available to their successor. Include this ordinary handoff when choosing a tool, particularly if the whole conversation currently sits in one person's inbox.

An extension or a separate application?

If the team works well in its project system but customers struggle with the interface, a focused customer view could help. It could show their open requests and let them respond to the relevant task. Internal planning could stay in the current tool. Before choosing an extension, establish whether the available connection can carry responses and task changes between the two. Having the coordinator copy them manually would preserve part of the existing workload.

A separate application becomes worth considering when launching the service requires connecting customer actions with information from several systems, and the existing tools do not handle that comfortably. Its scope could run from the start of implementation to service readiness. Sales and subsequent support requests could stay in the products you already use. Our article on a customer portal connected to a CRM covers the broader portal decision.

Include the work after launch when comparing proposals. Someone in your company will update the onboarding process as the service changes. The application provider needs an agreed scope for maintaining connections and handling failures. Helping customers with access will remain part of support. Those responsibilities affect the cost of a custom tool and belong in the comparison with a standard product.

Implementations already underway need particular attention during a move. Open requests should retain customer responses and dependencies so the team knows where to resume. Also agree on how you could later export that history, access the code, and transfer maintenance to another provider.

Start with an implementation that stalled

Syntalith builds custom applications. A possible initial scope is a view of outstanding customer requests linked to the implementation tasks waiting for a response. That example can help establish whether configuration is sufficient or whether you need a simpler interface and an additional system connection.

For a first conversation, describe the last implementation where the customer thought they had sent everything but your team was still waiting. Explain what was missing and where the coordinator recorded the follow-ups. See Syntalith pricing for information about billing.