Challenges

When a project is client-facing, it involves work done by the internal team and sometimes it is outsourced to a freelancer or external partners. Involvement of an external team becomes complicated, as the partner might be assisting with multiple projects or there could be multiple partners assisting with projects, making collaboration messy. There is no proper visibility on who the partners helping with projects are, which projects they are involved in, and which exact member of the partner is doing so. There is also often a lack of accountability for the tasks that need to be performed.

What is Partner Central

It is a feature, that helps the vendor team (service or product provider) stay on top of what their partners are working on and which projects they are involved in. We can invite partners, just like team members, to help get the jobs of clients done (vendor’s customer). Partners can be assigned to tasks, engage in conversations within the system, and share updates, just like any other team member. Vendors can gain full visibility into their work, track progress, and assess their performance.

Process

Before the introduction of Partners, there were primarily two personas at Rocketlane: vendors and clients. Rocketlane is a customer-facing product, where the vendor refers to the service or product provider, and clients are the vendor’s customers. Now, there is a third persona called partners.

This feature was interesting to work on as it involved a lot of permissions and visibility control, which had impacts on areas that didn’t seem directly connected.

Inviting partners

In any organization, for a team member to start using a company tool, they need to be added to the system. Without that, even if they are employed, they won’t be able to perform any action on that system. Similarly, for partners to start contributing on the platform, they need to be added to the Rocketlane system. While the partner company is being created, the partner admin is also specified; they would be the point of contact for that company.

Form to invite partners

Email that partner admin receives

Types of partners

Partners are like external team members to vendors as they help them in completing tasks. But because they belong to another company, vendors might not be comfortable sharing all their project details, which might contain some sensitive and confidential data. So, we introduced three different access levels for Partners:

• Permissive

• Moderate

• Restricted

Permissive partners have all the capabilities like that of vendor team members but only for the projects that the partner company is part of. Moderate also has similar access but only for shared or public information. On the other hand, Restricted partners have access only to the resources they were assigned to.

Masking partners

Not all vendors like letting their clients know that they are working with someone else to help get their work done, and this preference could be due to various reasons, for eg. they don't want others to know how they function. To address this concern, we introduced a way for vendors to decide whether they want to expose the partner team to clients in the project or choose to hide it and make them appear as their team members.

Masking partner company

When masking is off, client sees partners inside project

When masking is on, client sees partner as vendor team member

Collaborating with partners

Every project starts with the project creation stage. During that time, the vendor team may not have clarity on who from the partner side could work on the project; the partner admin would have a better understanding on that front. So, at project create itself the partner company is added, which sends a project invite email to the partner admin. Once the project has been created, both the vendor team and partner team can invite existing partner members to the project. Partner company can also be added after the project is created. Different companies operate differently, majority of them set up all project details at project create stage, while some do it after project creation.

Adding partner

Invite modal inside project

Chicken and egg case

Once all major flows were designed, we discovered an edge case. In Rocketlane, 'role' is an important data that is used to assign members to tasks, analyze reports, and is even mandatory on the member registration form. Roles can only be created by the vendor admin to keep the system organised. Vendor admins might not always know what role the partner members being invited to the system would have, and because of this, the partner company creation was incomplete. Partner admins do get an email notifying them about their company being added as a partner to the system and are asked to sign up for the account. However, when they try to do so, they can't proceed because they have no options to select under the mandatory 'role' field.

To solve this, an intermediary step has been added before a 'New partner' is created for the first time. In that step, I ask the user to specify the role that the partner team members can use. This role comes from the roles created for the vendor team members.

In addition to the above, the solution also evolved at the account setting level where we create roles for vendor team members. We ask there to specify whether the roles should be available to partner members as well or not.

Impact

With the introduction of Partner Central now companies are able to better collaborate with their partners and customers. They are able to seamlessly perform project management with all their partners and customers in one tool.

Learn about Partner Central.