The new system is ready. The old spreadsheet is still open.
Consider a team that has entered its first customer enquiry into the new tool. The question about the enquiry remains in chat. The reminder to call back is in a colleague’s calendar. Everyone has signed in, but the work still follows the old route.
Before calling this resistance to change, look at what the spreadsheet knows that the new system does not.
The old spreadsheet is doing a job
When a team keeps using its old list, look at the list before asking people to abandon it. Perhaps it makes overdue calls obvious. Perhaps it has somewhere to note an exception that the new form cannot represent.
Continued use does not establish that people dislike change. It may reveal a missing part of the new process. Insisting on adoption can obscure the information people need to finish their work.
An enquiry makes the distinction clear. A name and an email address are enough to create a record. The colleague taking over also needs to know whether anybody has spoken to the contact and what was agreed.
Introduce one complete journey
A useful first trial can be small: an enquiry arrives, someone takes responsibility, a conversation happens and its next step is recorded.
That boundary gives you a way to make tradeoffs. Another dashboard might be interesting. If nobody owns the enquiry yet, the dashboard can wait. Other departments can wait too while the first team still needs a private list to finish the journey.
Our documented lead process starts with the source, owner and next action for that reason. A contact does not need a complete qualification profile on arrival. The team first needs to see which conversation requires attention.
The recovery path is part of the rollout
What happens when an enquiry is entered twice? When its owner is away? When an AI summary leaves out an important sentence?
These cases deserve a place in the pilot alongside the successful run. People need to correct a record, take over a task and reject an incorrect recommendation. If the only way to do that is to message the developer, the workflow is not yet ready for ordinary use.
AI adds a specific requirement: the reviewer needs to compare the suggestion with its source. Showing a polished summary without its original message sends the person back to another tool whenever they are unsure. The old process may then be easier.
Measure work reaching an outcome
Sign-ins tell you that people opened the software. For this pilot, unanswered enquiries and time to first response tell you more.
Before launch, establish how you will record those measures. Afterwards, compare similar cases and include the time spent correcting them. Intake might become quicker while review becomes slower. That is useful information even if it makes a less exciting success slide.
Discuss the detours as well. Every private reminder and extra list says something about the workflow. Some gaps can be fixed. Some work may sensibly stay in another tool. In that case, the handoff needs to be explicit.
A practical reason to expand
Ask someone who did not create the record to take it over. They should be able to find its source, conversation history and next action, then complete the work. Try an exception too, not just the cleanest example.
If that still requires help, keep the pilot small. You have room to supply the missing information before repeating the same gap across more teams.
Give the old spreadsheet a working counterpart in Pharen Hub
You can model the enquiry in Pharen Hub Lists with fields for status, responsibility and the next call. Saved views let the team focus on the relevant stage, while Workflows coordinates the preparation and review. Start by reproducing the useful information from the old spreadsheet, including the exception that made people keep it open.
Show us the spreadsheet your team still keeps open to start with the part they actually need.
