A working installation does not guarantee a complete reporting workflow. Android device settings, SIM identification, connectivity and permission changes all affect what reaches a dashboard. This checklist focuses on acceptance testing. The SIM-based call tracking product page explains the underlying approach; use this guide when preparing the actual phones.
List the devices and business numbers
Record the phone model, Android version, business SIM and employee who will perform the test. Use supported devices and approved business numbers. On a dual-SIM phone, confirm that the employee can identify the intended SIM and that call records expose the necessary SIM information. Do not assume that two phones from the same manufacturer behave identically.
Check permission and notification states
Read the in-app disclosure before requesting call access. Verify which permissions are required for your chosen features and which are optional. Business synchronization should remain visible through the CallTrackly notification. Test what happens when notifications or call access are disabled: the employee should understand that synchronization is paused and know where to restore the appropriate access if they choose to continue.
Run a controlled call sequence
Use test numbers whose owners know why you are calling. Include an answered outgoing call, an incoming call, a rejected call, a missed call and an unanswered attempt. Compare the phone history with the console after synchronization. Check direction and duration as well as the number; a dashboard total alone will not reveal a record assigned to the wrong employee.
Check the selected SIM boundary
Repeat an authorized test on the selected business SIM and inspect whether it appears under the correct profile. Where the phone supports an identifiable second SIM, test the configured exclusion too. If the device does not expose reliable SIM identity, investigate the compatibility issue before introducing the phone into a larger deployment. Do not promise personal-call separation without validating the actual configuration.
Test an interruption
Temporarily disconnect the network, generate an eligible test call and restore connectivity. Confirm that the queue synchronizes without a missing or duplicated record. Check battery and background restrictions if the phone stops reporting. Device freshness helps distinguish an inactive employee from a phone that has not synchronized recently; verify that distinction in your operating instructions.
Keep audio testing separate
Call metadata is not an audio recording. If recording synchronization is enabled, test a compatible file from the employee-selected folder and verify authorized playback. Recording availability depends on the phone, dialer and file source, as well as the organization’s settings and consent process. Do not make recording a pass condition for a deployment that only requires metadata.
Sign off the handover
Confirm the organization timezone, employee identity and access-revocation process. Reassign a test phone only after resetting its connection through the supported workflow. Keep an acceptance record with the tested scenarios and limitations. Your team can then repeat the same checks after a phone replacement, OS update or SIM change instead of discovering gaps during a monthly report.