An illustrative example: a company tries its first shared system instead of spreadsheets and messages. When the manager asks, “Is everything convenient?”, employees nod. A private conversation reveals that orders are still copied onto paper because people cannot find the next step.
A pilot is a limited trial of a new way of working. Its value lies in finding obstacles before a wider launch, rather than unanimous approval. Feedback needs to describe the work instead of judging the person.
Ask about the last action
Instead of “Do you like the system?”, ask an employee to show how they completed a particular assignment. What were they trying to do? Where did they stop? What did they expect to see? How did they continue?
Collect observations from different roles. A salesperson creates a record, another employee receives the work and a manager checks the outcome. Convenience for one participant does not guarantee that the handover works.
Do not require a beginner to provide a technical diagnosis. “I couldn't find the assignment I received” is enough reason to review the scenario together.
Separate four different obstacles
An error means a promised action fails. A training gap means the action works but the employee does not know how. An unresolved agreement means the team understands the process differently. A wish is an extra feature without which the current scenario can still be completed.
This is a practical classification for discussion, not a set of labels employees must select themselves. One comment can have several causes. An extra field, for example, may be both confusing and genuinely unnecessary.
Record the action, expected outcome and actual outcome. Add an anonymised example instead of an export of the whole customer database. Keep passwords and unnecessary personal data out of shared discussions.
Where to keep feedback
A shared list is enough initially: observation, person reviewing it, decision and checking method. You do not need to build a separate suggestions portal straight away.
If the pilot uses Bitrix24, a task with a description, discussion and files can be used to investigate a specific obstacle. These features are described in the official task guide. Check participant permissions and the required features on your plan.
The list alone does not measure usability or replace a conversation. No recorded complaints may mean that people do not know where to write or are afraid of appearing inexperienced.
Respond and repeat the scenario
Explain the decision for each reviewed observation: change a setting, clarify a rule, demonstrate an action or postpone a request with a reason. Do not leave the employee feeling that feedback went into a black hole with a “Thank you” button.
After the change, ask the same participant to repeat the action without hints. Check whether the work can be finished, rather than whether a new button exists. If the problem remains, return to the observation instead of arguing with someone's impression.
For a team in Kyrgyzstan, gather examples in the languages and on the devices employees use. A check on the manager's computer alone is insufficient for colleagues working on phones.
QQDev implements Bitrix24 and trains teams. On the implementation page, you can discuss how to organise the review of early difficulties. Start with one anonymised scenario: what the employee tried to do, what happened and what outcome the business needs.