Keep, Connect or Replace? How to Review a Business Tool

Before replacing a business tool, write down the job it cannot do. A broad complaint such as 'our systems are a mess' can lead to a broad and expensive change. A specific job gives you something to test.

For example: the person preparing a proposal needs the customer's latest answer. They cannot find it in the place where they work. Start with that handoff before comparing a new collection of features.

Name the job and the evidence

Choose one tool and one recurring task. Write who does the task, what information they need and what should happen next. Find a recent record that shows the problem, if one is available. Keep customer details in the existing restricted record. Use an anonymous label on your decision sheet.

Check what the current tool can already do. A missing feature, a disconnected record, restricted access and an unclear routine are different problems. They may need different changes. If you cannot establish the cause, record it as unknown.

Compare four decisions

• Keep: the tool can do the job. Clarify the routine, access or responsibility, then test it.
• Connect: useful information exists in another place. Check whether a supported connection can make it available safely and reliably.
• Replace: a required capability is genuinely missing, or the current setup cannot meet the agreed need. Test the replacement against that exact need.
• Investigate: the evidence is incomplete. Set a question, an owner and a review date before making a purchase.

These are provisional decisions. A feature listed on a pricing page is a reason to investigate, not evidence that it will work in your account. Confirm the plan, permissions and actual workflow before relying on it.

Include the work around the subscription

Compare setup, data transfer, training, ongoing administration and support as well as the subscription. Check what you can export and which records or links must stay available. Find out how the proposed change affects access and existing automations.

Do not cancel the current service while critical records or working routes still depend on it. A small authorised test can help you decide whether to proceed. Use fictional data where possible. It does not prove that every future case will succeed.

A fictional proposal handoff

This example is invented to explain the decision. A consultancy considers replacing its CRM because a proposal writer misses updated customer answers. During the review, the team finds that the answers are already visible to that role. The missing step is a notification and an agreed person to act on it.

The provisional decision is Keep. The team defines the handoff and checks one authorised test from incoming answer to updated proposal. If the role still cannot access the right record, the team reopens the decision. No saving, sales result or customer outcome is claimed for this example.

Use this decision sheet

Tool and job:
Anonymous example record:
Expected handoff:
What the current tool can do:
Observed gap, or Unknown:
Decision: Keep / Connect / Replace / Investigate
Smallest authorised test:
Responsible role and review date:
Evidence that would change the decision:

Complete the sheet for one tool. A useful answer can be 'keep it as it is'. If a change is needed, describe the expected behaviour before choosing how to implement it.

Check your decision

Ask someone who knows the work to explain the proposed test from your sheet. Can they tell what should happen and what evidence would count? If the answer is vague, make the job more specific. You have finished this review when the next decision is clear, even if buying software is not the next step.

Next action: Use the decision sheet above to review one tool.