Conversational OneDrive capacity increases for multiple users, run and verified with Sia.

You open the admin center. You search for the user. You find the OneDrive setting and bump the number. You close the ticket.

Then the next one lands. Same request, different name.

Increase my OneDrive storage.

It is one of the most common tickets any help desk sees, and the reason it piles up has nothing to do with the fix being hard. The fix takes thirty seconds. The problem is there is no way to do it for more than one person at a time. One screen, one user, click through, save, repeat, for however many names are waiting.

A ticket that never really goes away

Every OneDrive quota request looks the same on paper, and each one hides two or three separate small jobs.

Checking the current allocation: Suraj is sitting at 200 GB, Vikas Mishra at 100. You need to know that before you know how much headroom to grant, and that means opening a profile just to read one number.

Raising the quota itself: Type the new number, save, move to the next name on the list. On a good day this is fast. On a busy one, a dozen employees space these same requests across the week, and the fast part happens a dozen times.

Confirming the new quota actually took place: A change that looks saved on one screen does not always show up on another, so the number is worth a second look before the ticket gets closed.

None of this is hard. All of it is repetitive, and the repetitive part is exactly what turns a thirty-second fix into a queue with someone's name stuck at the bottom of it.

What we asked Sia to do

Here is that same request, handed to Sia as one plain-English instruction, typed into the Sia CLI, covering two different users in a single line:

"Please increase the OneDrive storage quota for Vikas Mishra and Suraj to 500 GB."

Sia broke that into steps and worked through them one after another, setting Vikas Mishra's quota first, then Suraj's. Its own output showed the change: Vikas Mishra's quota moved from 100 GB to 500, Suraj's from 200 to 500.

Then the same number was confirmed a second time, straight in the Microsoft 365 admin portal. Vikas Mishra's OneDrive settings showed 500 GB. So did Suraj's. Same number, checked twice.

The same pattern holds for requests that did not make it into this demo. "Set Priya's OneDrive quota back to 250 GB." Done. "Tell me which users are over 90 percent of their allotted storage." Done. No screen-by-screen work behind either one, just the same short loop: instruction in, quota checked or changed, confirmed.

Watch it happen

The full sequence above, run and verified live in the Microsoft 365 admin portal. 

Before Sia, with Sia

Before Sia: open the admin center, search for a user by name, click into their profile, find the OneDrive setting, read the current number, type the new one, save.
With Sia: one sentence naming every user and the new quota, and it runs the instant it is sent.

Before Sia: repeat that whole sequence once for every name on the ticket queue, because there is no bulk option for OneDrive quotas in the admin center.
With Sia: as many users as fit in one sentence get handled in one pass.

Before Sia: click back into each profile a second time to make sure the change actually stuck. With Sia: the confirmation is already sitting in the response, and a look at the portal is a formality instead of the only proof you have.

Before Sia: field a dozen copies of the same request spread across a week, each one its own interruption.
With Sia: the interruption disappears. The request becomes a sentence that gets answered.

What Sia actually touches

Sia works directly against the Microsoft 365 admin center: user identities, their OneDrive storage allocation, and the SharePoint Online service that allocation sits on. This walkthrough used quota increases for two users. The same connection point covers checking current usage, applying a new limit, or rolling one back, for any user in the tenant.

Every change runs through the same governance that lets Sia act on production systems generally: a mutation gate with three verdicts, allow, require approval, or block, sensitive changes queued for a human, destructive operations blocked outright, and every action written to an append-only, HMAC-signed audit log that exports with its signatures intact. When someone asks who has how much OneDrive storage and why, the answer is a query against a signed record, not a search through old ticket threads.

This is not only a help desk job anymore

None of this needs a help desk administrator at the keyboard for every request. A team lead could ask Sia to raise storage for someone on their own team without ever opening the admin center. Access control does not disappear. Sia runs inside the role-based scope you set, so the permission model moves from a human clicking with admin rights to an agent acting within a policy you defined.

It is the same Sia whether the request comes in through the command line, the web, or the desktop app. The surface is just the door.

What this actually changes

Storage tickets stop waiting for a free ten minutes in someone's day. Multiple users get handled in the same message instead of the same queue, one after another. Nobody has to remember to check that the change stuck, because the confirmation already came back with it. And the help desk spends its day on requests that actually need a person, not the ones that just need a number typed into a field.

You do not have to open the admin center at all. You just have to ask.

Availability

OneDrive capacity management runs on the Microsoft 365 integration that is in Sia now, across the Sia CLI, the Sia Desktop App, and the web. We deliver Sia as part of the Scogo platform to enterprise customers, so there is no public download.

If your help desk is still opening one profile at a time to raise someone's storage quota, we want to put Sia in front of your tenant. Start with a pilot at scogo.ai/request-demo.

Autonomous where it is safe, governed where it matters, on the record everywhere.