How to Get Your Team to Actually Use a New Business System

The system went live three weeks ago. The build was signed off, the data was moved, and the supplier has gone quiet. Then you walk past the office and see it: the old spreadsheet is open on the admin's screen, the technicians are still sending job details by WhatsApp, and the new system holds about half of last week's orders. Nobody is being difficult. They are doing what is fastest for them this afternoon.

This guide is for owners and managers of small and medium businesses who have just launched, or are about to launch, a custom business system and want their team to actually use it. It covers the first 30 days after go-live: who owns the system, how to train, when to switch the old way off, how to deal with complaints and how to tell whether people are really using it. It is general guidance, not a promise about any supplier's training or support, and it is about people and habits rather than software.

Why systems fail after launch

A system that passed testing can still fail in daily use. The causes are usually human and fairly predictable:

• People keep the old way. The spreadsheet, the notebook or the WhatsApp group still works, everyone knows it, and nothing forces a change. If both ways stay open, the old one wins because it needs no effort.
• The new way is slower on day one. Typing a job into a form takes longer than scribbling it on a pad, especially for someone who has done the old routine for years. The benefits (fewer mistakes, instant reports, no retyping) mostly reach the owner and the office, not the person doing the entry.
• Nobody owns it. The supplier built it, the owner is busy, and each employee assumes someone else will answer questions and fix small problems. Complaints scatter across chats and nothing gets decided.
• Training was about features. A two-hour tour of every menu is forgotten by Friday. People remember the five things they must do on Monday morning.

None of this is a technology problem, so none of it is fixed by more software. It is fixed by a few decisions the owner makes in the first weeks.

Name one owner: the system champion

Choose one person inside your business to own the system day to day. This is the system champion. It is usually not the owner and not the most technical person, but someone who knows how the work really flows, is respected by colleagues and is willing to ask questions. In a small business it is often the office manager, operations lead or senior admin.

The champion does not need to be an expert on day one. Their job is to be the first person colleagues ask, to collect problems and to be the single contact with the supplier. Give them real time for it (an hour or two a day in the first weeks is realistic) and say so in front of the team, otherwise it becomes a side job done at night.

The owner's part is just as clear: use the system yourself, ask for reports from it rather than from the old spreadsheet, and back the champion when someone says "I'll just do it the old way." If the owner still asks for the spreadsheet, the team will keep it alive.

Train by real daily task, not by feature

The most common training mistake is walking through the menus. Staff do not use "the customer module"; they take a call, book a job, check what is outstanding, or issue a quotation. Build the training around those jobs, role by role, using real examples from this week.

A simple pattern works for most small teams: one 20-minute walk-through per role, a one-page cheat sheet, and "show me" sessions afterwards when someone is stuck. Do the walk-through with live (or realistic) data so people see their own customers and products, not a demo. If you ran user acceptance testing with real tasks, reuse those scripts as training material.

Keep the cheat sheet to one page, in the language your staff actually read (English, Bahasa Malaysia or Chinese), with real screenshots and the exact words on the buttons, and print it where the work happens. Short "show me" sessions beat long classrooms: ten minutes at someone's desk, using their own task, teaches more than an hour of slides. If your system has several user roles, the access each role has decides what each person sees, so train people on the screens they will really get.

Set a cut-over date and retire the old way

The cut-over date is the day the old spreadsheet or process stops being the place where work is recorded. Without one, the new system becomes "an extra thing to fill in," and double entry quietly becomes permanent.

Choose the date with the team, announce it at least a week or two ahead, and put it in writing. On that date, make the old way read-only: save the spreadsheet as a read-only copy, move it to an archive folder, and stop accepting job details through chat. The "no double entry after day X" rule is simple: after the cut-over date, a record exists in the new system or it does not exist.

Being firm does not need to mean being heavy-handed. A short parallel run is reasonable for critical records, such as a week or two where month-end figures or invoices are checked against the old sheet, with one named person responsible for the comparison. The key is that the parallel run has an end date, and that ordinary staff are not asked to type everything twice. It is a check on the new system, not a second job for everyone.

How you launch (everyone on one date, or one branch or workflow at a time) is a separate decision you should make before go-live; this guide assumes the date is set and concentrates on what happens after it. If you are still deciding when the system will be ready, see how long a custom business system takes, and if old records still need to be moved, read moving your data into a new system.

A first-30-days plan, week by week

The first month decides whether the habit sticks. This is a simple plan you can adapt; the dates matter less than having someone look at the numbers every week.

Expect the first week or two to feel slower. That dip is normal, and a team that was told to expect it is far less likely to read it as failure. Say it out loud on day one: "this will be slower for a few days, and we will fix what is slowing you down."

Who answers questions in the first weeks

People stop using a system when they are stuck and nobody is near. Decide in advance who answers what, and tell everyone in one message.

• "How do I do this?" The champion, or the backup when they are away. The cheat sheet comes first, then a quick "show me."
• "This looks wrong or broken." The champion logs it, tries to repeat it, and decides whether it is a mistake in use, a bug or a change request.
• "Can it do this instead?" The champion logs it as a request, and the owner decides later (see the next section).
• Supplier questions. Only the champion contacts the supplier, in one batch, so the supplier hears one tidy list.

Ask your supplier, before launch, what support you will have after go-live and for how long, and get the answer in writing. This guide cannot tell you what any supplier offers.

Handling resistance: listen for the real friction

When someone says "I don't like the new system," treat it as information. Often the complaint is about one specific step, and the person is right. Sit with them and watch them do the task before deciding anything.

Not every request is a bug. Something that used to work and now does not, or that contradicts what was agreed, is a bug the supplier should fix. Something new that you would like is a change request, which the owner prices and schedules. Sorting these properly keeps arguments with the supplier short; software maintenance after launch: bugs versus changes explains the difference and how to ask for each. A good rule in the first month: fix the quick wins fast, collect the bigger requests in a "later" list and decide on them together at day 30, so the team sees feedback is heard without the system changing every day.

Listen for patterns too. If three people hit the same step, the step needs fixing. If one person keeps avoiding the system, ask privately what is in the way before assuming attitude.

Collect feedback in one place

Complaints in six chat groups cannot be counted, prioritised or answered. Keep one feedback log, a shared sheet or a form, and tell everyone that if it is not in the log, it did not happen. The champion owns the log and reviews it with the owner weekly.

Four rules keep a log useful: one line per item, always the date and the person, a type (question, possible bug or request), and a status someone can read at a glance. Tell people when an item is closed. A log that nobody answers teaches staff not to bother.

Measure adoption in simple ways

You do not need a dashboard to know whether people are using the system. A few plain measures, checked weekly, are enough. Pick two or three and write the number down in the same place each week.

For illustration only, with made-up numbers: a servicing business completes 50 jobs in a week and finds 38 in the system, so about 76% were entered. If that moves to 44 and then 49 over the next two weeks, the habit is forming. If it stalls at 38, find out which jobs are missing and who handles them, then ask what is in the way.

What does good look like? There is no universal benchmark, because it depends on your work and your people. A sensible target is simpler: by the end of the first month, nearly all work flows through the system, the spreadsheet is no longer being edited, a routine task takes no longer than the old way, and the owner reads reports from the system. If a measure is flat after a month, treat it as a question to investigate, not a verdict on the team.

Checklist: the first 30 days

• A named system champion and a backup, with time set aside for the role.
• A cut-over date announced in writing, with the old spreadsheet or process made read-only on that day.
• A short parallel run, only if needed, with an end date and one person responsible.
• One 20-minute walk-through per role, built on real daily tasks.
• A one-page cheat sheet per role, printed where the work happens.
• One feedback log, reviewed weekly, with closed items reported back.
• Two or three adoption measures written down each week.
• A "later" list for change requests and a decision meeting at day 30.

Common mistakes

• Leaving both ways open indefinitely. Without a cut-over date, the old way stays.
• Training on every feature. Teach what each role does on a normal Monday.
• No named owner. Questions scatter and small issues never get fixed.
• Treating complaints as attitude. Most contain a real problem worth fixing.
• The owner still using the spreadsheet. The team follows what the owner asks for.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, from an indicative RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide is general advice and does not describe any training, handover or support terms, so ask any supplier, Gotka included, to put what happens after launch in writing. If you are still deciding whether to build, see signs your business has outgrown spreadsheets; to brief a developer well, what to prepare before your first conversation. For specific kinds of system, see also quotation to invoice automation, staff attendance, leave and claims, customer portals, multi-outlet management and a simple CRM. The team is reachable through the contact page.

Key terms used in this guide

• Go-live: the day a new system starts being used for real work.
• Cut-over date: the day the old spreadsheet or process stops being the place where work is recorded.
• System champion: the one internal person who owns the system day to day and is the first contact for questions.
• Parallel run: a short, planned period when old and new records are compared, usually for critical records only.
• Double entry: recording the same information in both the old and the new system.
• Cheat sheet: a one-page, role-specific guide to the daily tasks, with screenshots.
• Adoption: how far people actually use the system for their real work.
• Change request: a new or different feature, as opposed to a bug, where something does not work as agreed.