While you can use the sys.dm_db_index_usage_stats view to identify when an index was last accessed by a user, this also requires that you make assumptions regarding the last time it was accessed to whether or not it will be accessed again. It's possible one of the report writers could have just finished up typing their query and preparing to hit F5, and the programmatic checking of this DMO told you it hasn't been accessed in awhile, the deletes begin, and now the user is waiting.
There are other ways to identify what's going on in a user's session using sys.dm_exec_sessions in conjunction with sys.dm_exec_requests, but this could potentially create the same aforementioned issue.
From what it sounds like, there isn't a major urgency to perform these deletes.
Why not schedule a job and have it run in the middle of the night when nobody's using the database?
I think this would be a great idea, that way you're not having to perform any complex checks within your stored procedure. Would you also be able to lower the batch size of your deletes on these tables to reduce contention? If not everything needs to be deleted all at once, you could possible run the procedure more frequently only deleting TOP (X) rows meeting your predicate criteria.