Skip to content
Back to Academia

Change management: making a new process work

15.08Strategy and marketing management
On this page

Go back to the time when an Almaty analytics reporting service was only just moving to its new CRM, the one whose purchase we broke down by buying roles. In the training, Zhanar's three sales managers confidently create a card and set a task. But after a call with a client, a manager still opens the old spreadsheet: Talgat, the owner, still expects the daily report there. Some open tasks got lost in the migration, and picking the next step on a phone is awkward.

A second training session will not bring the lost tasks back. First find out what stops people from doing the work, then fix the transition and test it on real enquiries. The project is done when the team runs clients through the new process and Talgat and Zhanar make decisions from its data.

Transition to a working CRM and archive

CRM transition

Working record

Customer agreement

Next action and deadline, or a closed-deal status.

Reporting
The manager uses the new report

Transition checks

  1. Reconciliation

    Reconcile open deals and tasks; restore missing records.

  2. Workflow

    Test customer handling and the new report on real enquiries.

  3. After checking

    The old spreadsheet stays read-only. Daily duplicate entry stops.

Retain history for reconciliation under company rules. Deleting the source file is not required.

Restore tasks and test the new workflow and reporting first, then retain the old spreadsheet as a readable archive.

Start with the action after a conversation

For the service, the working rule goes like this: after talking to a client, the manager records what was agreed and sets a next step with a due date, or marks the deal as closed. A colleague who opens the card should understand what the client was promised and what to do next. Zhanar uses these records to share out the queue.

A rule like this makes clear who acts, when, and who needs the result. "Use the CRM" says none of that. The number of logins says little about the work either: someone can open the CRM, look up the client's phone number and write the outcome of the call in a personal file.

Ask a manager to walk you through a recent enquiry. Where did they find out which accounting system the client uses? Where did they record the agreed pilot date? What will a colleague see if this manager goes on holiday? Watch the whole path, awkward exceptions included. A quickly created empty card can hide a lot of manual work outside the system.

Fields are chosen to fit these actions. If nobody uses some piece of information, find out why it is collected. If a field is required but the answer is not known yet, add a "needs clarifying" state and a task to clarify it. A made-up value entered just to fill the field will spoil decisions later.

Find the cause before you schedule training

Prosci's ADKAR model breaks a change down into awareness of why it is needed, desire to take part, knowledge, ability to act and reinforcement. These points make a handy structure for a conversation with an employee. But an empty CRM record will not tell you where the person tripped up.

What you seeWhat to find outHow it might be fixed
A manager does not see why a field is requiredWhat decision is made from itExplain its purpose or drop the requirement
The agreement was recorded in the wrong placeIs it clear where and how to record itGo through a real conversation together
A task disappeared after the migrationDo the old and new records matchRestore the task and check the rest
Records are put off until the eveningIs working from a phone convenientFix the form or the way of working
A deal is kept in two placesWhich report the manager in charge requiresAgree how reporting moves over

An employee's objection can reveal a mistake in the project itself. It does not cancel what was agreed, but it suggests what to fix. If access, data and instructions are already in order and the same failure keeps happening, Zhanar talks to the manager one to one, using examples from their own cards.

Ask Talgat, too, what he is willing to change himself. If he sent the team to learn the new process but still reviews only the old spreadsheet, the managers get two demands they cannot meet at the same time. Appointing one more person to enforce discipline will not fix that.

Work out the cost of double entry

Take some illustrative numbers. Three managers spend 20 minutes every working day copying into the spreadsheet what is already in the CRM. Over 20 working days that is 3 × 20 × 20 = 1,200 minutes, or 20 hours. For workload estimates an internal hour is worth 5,000 ₸, so double entry ties up 100,000 ₸ worth of time a month.

This is an estimate of time. The service's fixed costs of 6,800,000 ₸ already include the whole team's payroll, rent and shared services. If Meruert, the accountant, subtracts another 100,000 ₸ in the P&L, the same salaries get counted twice. After the transition, salaries may stay the same, but the managers will have time for other work.

The team estimated preparing the transition at ten hours of one-off work, or 50,000 ₸ of the same internal time. That covers reconciling data, setting up the report and working through exceptions. If Bekzat, the developer, does this within his paid hours, the amount does not become an additional cash expense. If a contractor or overtime is needed, the agreed cost of that goes into the budget.

Say that after the transition four hours a month of record-quality checks remain. Then the net time freed is 20 - 4 = 16 hours, 80,000 ₸ a month at the same rate. The team checks both figures by measuring: whether the double entry has really gone, and how long the new check takes. Until then this is a forecast of time saved.

It is too early to turn these hours into revenue growth. Talgat can give the freed time to overdue contacts, but sales also depend on demand, the offer and how clients are handled. The link is checked against results, and time, costs and income stay on separate lines of the report.

Run a pilot across the whole client path

Pick a small stream of enquiries and decide in advance who a manager goes to when stuck. The pilot should take in a new lead, a compatibility check, booking and rescheduling a meeting, a refusal, a repeat enquiry and handing a client over to a colleague. Only then will it become clear whether the data and rules are enough for everyday work.

Before the start, Bekzat exports the list of open deals with stable IDs. After the migration, compare owner, status, last agreement, open tasks and due dates. Go through the tricky cases by hand. The row count can match even when tasks have ended up attached to the wrong clients.

Decide in advance what happens when something breaks, too: where a manager temporarily records an agreement, who later moves it into the CRM, and how they mark the reconciliation as done. This path is needed before the first problem. Otherwise a temporary personal file easily becomes a permanent second source.

For the transition period both sources are sometimes needed. Name who owns the reconciliation and the condition under which parallel entry stops. Switching the spreadsheet off on a date without reconciling the data is not an option. But an open-ended "let's keep both for now" takes the point out of the transition.

Remove the old requirement after the check

Zhanar checks the new report against the agreed definitions: what counts as an open deal, an overdue step and a completed task. She runs a team meeting from the CRM, checks that colleagues can see the cards they need, and makes sure no unfinished commitments to clients have been lost.

After that the old spreadsheet is switched to read-only and kept as an archive under the company's rules. The history stays at hand for reconciliation, and daily updates stop. There is no need to delete the original file.

Write down where to look for answers now and who changes fields and statuses. Update the onboarding instructions for new staff. Otherwise, a month later, one newcomer will restore the old file from a saved instruction and another will invent yet another way of keeping records.

Adoption is measured on cards, not on training

Say all three managers have completed the training. In a check of 100 open deals that need a next step under the rule, only 60 have a current action with a due date. All three were trained, yet only 60% of cards carry the required attribute. It is too early to close the project.

The remaining 40 records have different causes: tasks lost in the migration, a wrong status, missing access, an unclear rule or a manager simply breaking it. Separate the causes first, then fix them. A "get in touch later" note without a date does not make a card ready to hand over.

A period later, a similar check of 100 eligible deals shows 85 usable records. Completeness has risen by 25 percentage points. That is record quality; sales are counted from their own numbers.

Exercise: can the project be closed?

The team has trained all the managers and reports that double entry is gone. The check shows 85 usable cards out of 100. Measurement confirmed the earlier 20 hours of repeated work a month and the current four hours of checks. Talgat wants to record 80,000 ₸ as additional profit. What needs correcting in the report, and what has to be finished before the project closes?

The 16 freed hours are valued internally at 80,000 ₸. As long as pay does not change, profit does not grow from this. The report shows time, actual additional costs and the work's results on separate lines. Before closing, the 15 cards that are not ready for handover need working through, and three things need confirming: Talgat and Zhanar work from the new report, the archive opens, and nobody requires the spreadsheet to be filled in any more. The project is closed when a working process has been handed to an owner, who from then on keeps an eye on record quality.

Need help applying this to your analytics?