The useful starting point
Evaluate the whole workflow around a device. A long feature list is less useful than seeing whether staff can find the right record and understand its current state.
Begin with an individual device
A count tells you how many items are in stock. An individual device record helps identify which phone a member of staff is handling. IMEI tracking is one way a phone-retail system can distinguish those devices.
Before choosing a system, agree which identifiers the business uses and what staff should do when an identifier is missing or entered incorrectly. Those questions belong in the workflow, not just in the database design.
Follow one device through a complete task
Illustrative example · a sample workflow to evaluate, not a screenshot of a client system
| Stage | Information needed | Action to demonstrate | Check before moving on |
|---|---|---|---|
| Identify | A sample device identifier and its existing record | Find the device without creating another record | A repeated lookup still identifies the same phone |
| Record a repair | The device and the information the repair task requires | Create and later find the repair record | Another staff member can identify which device the record concerns |
| Update the work | The current repair information | Record a meaningful change | The history remains understandable |
| Check stock | The relevant shop and stock information | Find the device in the appropriate view | The view uses the agreed meaning of stock |
| Review across shops | Shop labels, reporting period and underlying records | Explain a figure in a multi-shop report | A manager can trace what is being counted |
This demonstration is more revealing than a tour of five dashboards. Ask the person showing the software to keep following the same example and to explain what each view knows.
Keep device, repair and stock concepts distinct
An IMEI identifies a device; it does not by itself say which repair is open or whether the device counts as available stock. A repair status and a stock classification may change for different reasons. Agree their meanings before linking them in reports.
- 1Find the device
- 2Open the relevant work record
- 3Make the permitted change
- 4Check the operational view
For a new scope, write down what should happen if someone enters an existing identifier, opens another repair for the same phone or corrects a record. Treat these as acceptance examples, rather than assuming every action is an ordinary new entry.
Know when to buy, integrate or build
If an existing system can demonstrate the required tasks clearly, custom development may not be the next sensible expense. If the gap is one external connection, integration may be enough. A custom product becomes worth discussing when the important workflows cannot be supported cleanly by those options.
Our retail case brings together IMEI tracking, repairs, stock and multi-shop reporting. That establishes relevant scope; it does not mean your operation should copy that product’s requirements. Start with your own staff tasks and the exceptions that make them difficult.
Walk through a repair from start to finish
Ask someone who handles repairs to describe a normal job. What do they need to record when a device comes in? How do they find the job later? What information must another member of staff understand without repeating the conversation?
Use that example in a demonstration. Follow the same device and repair record through the proposed system. This makes it easier to spot a missing step than reviewing disconnected screenshots of a dashboard.
Make stock visibility useful across shops
Multi-shop reporting raises a different question from a single stock list: what does a manager need to compare across locations? The answer should determine which views are needed and how records are grouped.
If stock transfers, reservations or sales integrations are part of your operation, include them explicitly in the scope. Do not assume a reporting feature also implements those processes. They need their own rules, user actions and acceptance examples.
Agree what the reports mean
A report is useful when the people reading it understand the records and period behind it. Agree what each label means, which shop it refers to and what should happen when a record changes.
- Can staff find an individual device by its identifier?
- Is a repair record easy to locate and update?
- Can managers see the stock information they need for each shop?
- Can a user explain where a number in a report came from?
- Do unusual cases have a clear next action?
The scope behind our retail case
Codek’s phone-retail work spans a mobile application and backend, with IMEI tracking, repair records, stock and reporting across shops. The recorded implementation includes an Expo application and a NestJS backend.
That scope brings together staff-facing actions and the operational information behind them. The single-device demonstration in this guide is a useful way to evaluate a related requirement: follow one example from identification through work on the record into a management view.
The retail case study describes the work. It connects the individual-device task with the broader operational view.
Common questions
Does multi-shop reporting include stock transfers?
Not automatically. A reporting view and a transfer workflow are separate capabilities. Transfers need their own actions, record changes and rules if your operation requires them.
What should we bring to a scoping call?
A description of one ordinary device task, one repair example, the reports you use and the situations staff find difficult. Use sample or anonymised information rather than customer records.