Automated testing and Automated testing tools are development... you are writing and executing code of a sort. Even record and playback... all that consists of is a means to "easily" write code based upon UI interaction... but as baxatob notes, objects in the UI, especially in modern applications, have dynamic identification values so when you record the first time it DOES automatically map... but it uses the values at the time of record. Playback, those values may change.
Additionally, when you are recording, you are, as a human being, making note of on-screen cues as to when to click the next button or enter the data field... the automation isn't watching those queues so, on playback, it tries to run at "full speed" and the application may not be ready for a click or text field or something.
So, while record/playback is a good "starting" point, to be able to playback with consistency, you need to spend development time in many different places: adjusting object identification to account for dynamically generated identification proprties, adjusting timing with "wait" code and and delays, using "if/then" logic to detect the presence of fields and objects on screen to give cue as to whether or not the automation can proceed, etc.
This is the case for any automated testing tool... Selenium, UFT, TestComplete, AutoIT, etc...
For your purposes, I would suggest not using an automation tool like TestComplete. If you want to be able to see what someone did when they found a bug, have them do a screen video record using something like Jing or Snag-it to capture a video of their steps so you can see the reproduction. DEFINITELY a non-technical solution, gives you, the developer, what you're looking for, and doesn't require the development practices intrinsic to automated testing.
Keep in mind that TestComplete is an automated test development tool and, as such, requires a set of skills that go along with developing automated tests not unlike any software development practice.