Skip to main content

What should the first 90 days with a technology partner look like?

A realistic look at understanding your operation, delivering an initial improvement and using the evidence to choose what happens next.

Veda AI5 min read19 October 2026
Veda AI branded laptop and desk cover for What should the first 90 days with a technology partner look like.

The first few months with a technology partner should give you a clearer understanding of the business, evidence of useful work and a realistic basis for deciding what comes next.

That does not mean every engagement should follow an identical timetable. A team AI adoption programme and a complex systems integration need different preparation. Available capacity, access and staff involvement will affect the pace.

Veda AI's published partnership starts with an initial three-month commitment. That makes it especially useful to discuss how the early relationship will establish direction, use capacity and provide evidence for the next decisions.

The sequence below is an illustrative way to structure the first 90 days. It describes the questions and evidence worth expecting, rather than promising particular deliverables by particular dates.

Before work starts: agree how you will work together

Name a decision-maker inside the business and establish who will coordinate the external team. Agree how staff will provide information, when decisions will be reviewed and how concerns should be raised.

Clarify what the engagement includes and what uses the agreed capacity. Investigation, meetings, testing and training take time alongside implementation. Plan for those activities rather than treating them as invisible extras.

Create a safe route for access to the relevant systems and information. If approvals or other providers are involved, identify those dependencies early.

The first objective is a workable relationship with enough access and attention to make progress.

Days 1–30: understand the operation and select a priority

Begin with the people doing the work. Ask them to walk through real tasks, including the awkward cases, rather than relying only on leadership descriptions or existing process diagrams.

Consider an illustrative business where order processing feels slow. Following several orders might show that time is being lost while staff confirm incomplete specifications. The apparent need for faster data entry may be less important than improving what arrives in the first place.

Review the relevant systems and constraints. Identify which assumptions need checking before a recommendation can be made.

By the end of this stage, you should have a shared description of the main problems, a reasoned first priority and a short list of what is needed to act on it.

Establish a baseline you can actually use

Choose a small number of observations connected to the priority. For order processing, those might include time spent clarifying requirements, the number of incomplete orders and how often a job needs rework.

Check whether the information already exists and whether it is reliable enough. If it does not, agree a proportionate way to collect it. A small, clearly described sample may be more useful initially than delaying all improvement while building a large reporting system.

Record the limitations. Busy periods, unusual orders and changes elsewhere in the business can affect the result.

The baseline should help you judge change, without creating more measurement work than the decision requires.

Days 31–60: deliver a bounded improvement

Choose work that is useful enough to matter and small enough to test within the available capacity. The first improvement does not need to demonstrate every capability the partner offers.

In the order example, this could be a clearer intake form with checks for missing specifications and an agreed route for exceptions. Depending on the existing systems, it might involve configuration, integration or a process change.

Define what the team will inspect before treating the work as ready. Test ordinary cases and the exceptions that could create delay or confusion. Agree how a trial will be limited and what would trigger a pause or reversal.

If early investigation shows that a safe implementation needs longer, the useful output may be validated requirements, resolved technical uncertainty and a credible delivery plan. Explain that explicitly rather than presenting activity as a completed improvement.

Make staff involvement part of delivery

Give the people using the changed process time to try it and raise concerns. Explain what they are expected to do differently and where they can get help.

Assign an internal owner for operational questions. Technical staff can correct a system fault, but they may need your manager to decide how an exceptional customer request should be handled.

Watch the early use closely enough to spot friction. If staff return to the previous process, investigate why before assuming they need more persuasion.

A small adjustment at this stage may make the difference between a promising demonstration and a dependable working practice.

Days 61–90: review evidence and decide what follows

Return to the original problem and compare what is happening with the baseline. Distinguish what has been delivered, whether people are using it and what effect can reasonably be observed.

For the order example, you might see fewer incomplete submissions while clarification time remains uncertain because the sample is still small. Report both findings.

Use the review to decide whether to extend the change, improve it, investigate another priority or pause. Update the roadmap with what you have learned, including ongoing costs and responsibilities. Consider the mix of advice, automation, AI support, training and development that would best serve the next priorities. The next period should follow the evidence, rather than simply extending the original task list.

Avoid filling the next period simply because time is available. There should be a business reason for the work being proposed.

What you should be able to judge at 90 days

You should be better able to assess the partner's understanding, communication, delivery discipline and willingness to surface problems. You should also understand what your own business needs to contribute.

For Veda AI’s Business Improvement Partnership, onboarding and the initial roadmap use the monthly allowance. The scope of early work therefore needs to fit the capacity agreed.

When discussing a new relationship, ask the prospective partner to explain their first 90 days against one of your actual problems. That conversation will tell you more than a generic promise of rapid transformation.

VA

Written by

Veda AI

Practical AI, automation and business improvement from Veda AI.

Veda AI Edge

Get Veda AI Edge.

Practical briefings on AI adoption, automation, intelligent products and business improvement — what changed, why it matters and what to consider next. No hype, no AI theatre.

Sent when it is worth sending

By joining you agree to receive Veda AI Edge from Veda AI. Unsubscribe any time.

Ready to find what’s worth fixing?

Turn the idea into steady improvement.

Work alongside a team that helps you prioritise and deliver AI, automation and software changes each month. Explore the Business Improvement Partnership or discuss the business on a free call.