You're asking potential testers to use their imagination for tests.
I can't do the testing myself but I can imagine a scenario.

1. Peakd.com checks every user that logs in how they're doing with RC.
2. If they are low on RC we open up our pool to them (is this the right terminology?)
3. Can we set a time frame or do we just come back with a bot and turn it off later? Or maybe just keeping them on until the next time they log in and we can check again to see their needs?
4. We assign them enough to do a decent amount of RC which I suppose regenerates much like regular rc 20% a day? But not enough to be a potential spam factory.
5. At 100k hp we may not be able to cover all our users but we can overassign so that 10k users all get 20hp worth of rc which would only be a problem if 5k of them actually used up all 20hp worth of their rc.
6. But someone operating an RC pool would likely have a nice pie chart visualization on peakd and they can see their status. And they see its low.
7. So they perhaps get some people to delegate to that same pool. And maybe that solves the issue.
8. But let's assume not... can we go back in and assign everyone in our pool to 15hp worth of rc instead? What about those who have already used up 20hp? Will we be able to change them or will it object? It's fine if it shows up at 20 of 15 used because it will then fix itself for the next day.
9. So our crisis is averted the people who delegated RC to our pool can take it elsewhere now... my question is how often can you change that pool delegation? From moment to moment?

1. Next example is we have 1 million active users.
2. I suppose we will want to run tests to see what the average pool usage is. The thing is we notice there are two types... those that just consume... they vote, use a ton of api calls to read stuff and from time to time comment. Then the other group create content or play a game. (Question both us and the game have opened our pools to this gamer... who's rc pool does he use? Is it based on slot number?)
3. Ok so in our scenario is it best to analyze the user and put "viewer" types in one pool with lower rc allotments and put the "creator" types into another with bigger allotments? Peak Creator pool vs peak viewer pool... haha
   4.i guess the other option is to do one pool but analyze on the fly how much we expect they would need based on past usage.
4. Seems over delegating is important to avoid customers running out and causing a support request.

A. How educated about this experience do we want that user? I suppose they will need to assign themselves to our pool. Which I assume we present them with the code to execute when they sign in.
B. Excuse my ignorance but I assume none of this rc pool stuff is done on the blockchain level it's all 2nd layer right?
C. But if we craft the code for them to assign themselves to our pool they still have to execute it and it has some connection to them signing as the proper account key holder. So maybe it is a transaction on the chain?
D. So pie charts are likely Goin to be the best method here? 2 pies in and out. For incoming slots it will always be divided into 3 but for outgoing it could be as much as you want right? Meaning you can delegate your rc pool to as many rc pools as you want?

Ok I think that's my visualization exercise trying to figure out how our user experience may have to be