August 12, 2024

Onboarding a BD Tool Without an IT Project

Many firms delay useful tools because they assume an IT project is required. Often the real work is smaller and sits with the BD team.

Start with one workflow

Pick a single, well-understood task, such as assembling a first draft from approved paragraphs or logging trigger events, and set up only that. A narrow start is easier to explain and easier to judge. The most common reason for delay is uncertainty about who must approve, and a short list of names solves that quickly.

Resist connecting everything at once. Each connection adds review work and delays the point where anyone sees a benefit. Choose users who are respected by their peers, since their opinion travels.

Ask the security questions early

Even a light rollout should answer a few questions: where data is stored, who can see it, whether client material is kept separate and how access is removed. Put these in writing and send them to whoever handles risk. Firms with strict client confidentiality obligations will want written answers, and a reputable vendor should provide them without fuss.

A short review at the start avoids a forced stop later. It is not an IT project; it is a checklist. Ask the pilot group to note the time each task takes, before and after.

Use a small pilot group

Choose a handful of users who are willing and representative: one partner, one BD lead, one coordinator. Agree on a short period, a few weeks is a reasonable assumption, and a few questions you want answered. A pilot that has a clear end date is easier to approve than one that runs indefinitely.

Collect their comments weekly. Fix the small problems quickly so they see their input matters. Keep the data in the pilot to what is needed, and remove it if the pilot ends.

Keep existing systems in place

Where the tool needs client or contact data, start with an export or a manual upload rather than a deep integration. You can connect systems later if the pilot shows value. Manual steps at the start are acceptable, since the aim is to learn whether the tool helps and not to build a permanent connection.

That keeps the change reversible, which makes it easier for a cautious firm to say yes. Give each user a way to report a problem in under a minute.

Write the two-page guide

Training decks are rarely read. A two-page guide with the steps for the pilot workflow, what to do when something looks wrong and who to ask is enough for most users. People will read a short guide, and they will forget a long one.

Update it after the pilot with the questions people actually asked. Hold a short review at the halfway point, and change something visible.

Decide up front what success means

Agree on one or two measures before starting: drafting time, review rounds, or how many trigger events were acted on. Compare against the last few proposals, not against a guess. Be clear that a stopped pilot is a normal outcome, and thank the group for taking part.

If the pilot does not show a gain, stop. A clear no is a good result. Write down what you would do differently, and use it for the next tool.

Plan for the day something goes wrong

Any new tool will produce an odd output or a confusing screen at some point. Decide before the pilot who users should contact, how quickly they will get an answer, and what to do in the meantime. A named person and a clear route are enough.

Also agree what happens if the tool is unavailable on the day a proposal is due. The old process should still work, and everyone should know where it is. A fallback removes much of the anxiety that slows adoption.

VIPMarketing Editorial