>Hi Mark,
>
>I'm trying to think aloud. It usually helps me to try to explain the problem, when I can get to the solution.
>
>We defined these fields just recently, BTW.
>
>Here is how I understand them, though I'm not 100% sure my understanding is right.
>
>The regular account limit is the number of accounts user can have in his queue for a day. It is set in his profile as a fixed number, which manager would be able to change.
>
>The Overflow number is the number of accounts user can have in addition to regular limit, if there are delinquent accounts. E.g. he can have 50 as a regular count and 10 for overflow, so he may leave 10 accounts not resolved on the prev. day and he would have 50+10 on the next day.
>
>The delinquent number I believe should be updated on a daily basis (however, there is no process in place which does it currently). I think, it's accumulative number of accounts which were not resolved and were not re-scheduled. E.g. they still would have a past date as a scheduled_time.

Reminds me of a polyclinic app I wrote 11 years ago, where, among other things, I had waiting lists. A patient would be assigned to a doctor on a given day (most commonly current day) in several ways - sent by reception desk, sent by another doctor (could just ask for an opinion, test or whatever), or scheduled in advance for a checkup. All entries in a waiting list were generally equal (only a status field and sometimes the location for the next list, if the patient was to be sent back to sender), and sorted by datetime. The doctor (or, rather, the nurse) would usually see only current list for today, but could see how many were there already scheduled for tomorrow or any future (or past) day.

In your case, you may just assign the accounts to your users by filling similar lists, and checking their statuses in the end of the day. Then you could just go through them, skip the closed ones, skip the already rescheduled ones, and deal with the rest. When assigning, you'd check the number already assigned, and fill the available slots (up to the limits you got defined).

Don't know how much can this model apply to your case, but you said you wanted ideas - that means not exactly solutions, right? :)