I would suggest picking up either a free browser plug-in or some other free tool that can run in the background while your testers run their exploratory sessions.
I would treat the output of the tool this way:
- If no problems are found discard the log - The nature of exploratory testing requires intuition, guesswork, and a fair amount of serendipity. If a session finds no problems, and your automated checks find no problems, you have reasonable evidence that the part of the system in test being explored is fit for use.
- If there are problems use the log to generate reproduction steps - Testers may not remember exactly what they did when the problem happened, so the log will help to isolate and minimize reproduction steps.
- If anything logged looks like it might be an automation candidate, keep it - All that's needed is to save the session in a dedicated location for potential automation candidates, possibly with a note stating which part of the session should be considered for automation.
A lightweight system like this won't place a huge burden on the test team, may help with refining and reporting bugs, and may - if proposed the right way - be enough to satisfy your management team.
The alternative I use is to document test scenarios rather than test cases - that is, I have a list of broad scenarios that I document. They might be as simple as "valid login with full permission", "valid login with manager permission", "valid login with cashier permission", "invalid username", "invalid password". They can also be more complicated, like "manager creates an order for new product type, with tax set C applied and per-month invoice payments", or even "Manager-created orders vs cashier-created orders" - it depends on the level of detail I need at the time I perform the tests.