A team that publishes programming tutorials once did the maths for me.
Publishing ten videos to a short video platform, from picking material to tapping publish, takes under half an hour. The same ten pieces on Bilibili take forty minutes each.
I asked where the forty minutes goes. Uploading is a wait, transcoding is a wait, review is a wait, and in between there is category, tags, cover and description to fill in. Actual hands-on time is under five minutes. The other thirty-five are waiting.
The arithmetic is telling. The hard part of a Bilibili submission is not the operation. It is the waiting.
Take the submission flow apart first
To decide what can be automated, count the stages one submission passes through.
Upload. This is where it splits. Short video is usually tens of megabytes, longer video runs from a few hundred megabytes to several gigabytes. On the same connection, upload time differs by two orders of magnitude.
Transcoding. The platform converts your file to its own format. You do not control this, and the time depends on video length and the queue at that moment.
Review. Machine review is usually minutes. Anything routed to human review can take hours to a day. This step carries the most uncertainty.
Filling in details. Category, tags, cover, description, multi-part structure. Bilibili is stricter about category and tags than short video platforms, and getting them wrong affects distribution.
Publishing.
Of these five, the first two are time and bandwidth problems, the third is an uncertainty problem, and only the fourth is a genuinely standardisable operation.
What the computer can take, and what you can only wait on
By that split, the automatable part is the back half.
| Stage | Automatable | Note |
|---|---|---|
| File preparation and distribution | Yes | Push video into device libraries, handle several devices separately |
| Filling in details | Yes | Title, description, tags and category can be prepared in bulk and passed per submission |
| Submission logging and status tracking | Yes | Record time and title, come back and check status later |
| View data collection | Yes | Aggregate periodically for review |
| The upload wait | No | Depends on file size and bandwidth |
| Platform transcoding | No | Entirely on the platform side |
| Review outcome | No | Neither the result nor the timing is yours to control |
With that table in view, it is clear where the tool belongs. The last three rows are upstream constraints that no tool can touch.
Multi-part needs its own approach
Multi-part is a structure specific to Bilibili: one submission carrying several video segments that viewers watch in sequence on one page.
For tutorials, course series and collections, it is a practical format. It also adds work to batch submission, because what you manage is not one file but a parameter set: segment order, each segment title, which segment is the cover, and how the description reads.
There is a real trade-off here. If your content is naturally multi-part, say a course with twenty lessons, the parameter set is worth building once as a template and reusing. If it is an ordinary single video, forcing it into multi-part adds friction for no benefit.
Worth adding that the multi-part structure, several segments under one submission, tests flow stability harder on a phone than on a desktop. Each step has to wait for the previous segment to finish loading, and a wait that is too short produces errors.
Whether multiple accounts are worth it on Bilibili
I would be more cautious here than on other platforms.
The Bilibili ecosystem is held up by individual creator identity. Viewers follow the person, not the account. That already discounts the value of an account matrix, since ten anonymous accounts may be worth less than one with a loyal audience.
On top of that, Bilibili is stricter than short video platforms about reuploaded and non-original content, so pushing similar material across several accounts raises the odds of being flagged.
If you go ahead, split by content direction rather than by volume. One account for technical tutorials, one for product reviews, one for industry commentary. Three clearly positioned accounts do not confuse viewers and do not look like a matrix.
In other words, Bilibili rewards treating every account as a real one rather than spreading volume and hoping. That is different from how short video platforms work.
How to set it up
If your conclusion is to go ahead, work in this order.
First, turn the devices into reliable execution units. Install the workstation and phone-side program using the install selection page, then scan the phones in, alias them and group them. Aliases pay off especially well here, because different accounts map to different devices and a recognisable name removes a lot of “which one did I just run” confusion.
Second, get the files onto the devices. Use file distribution to push videos into the phone library. For large files, push in batches rather than all at once, or you saturate the network. On iPhone, grant photo library permission first or the script cannot save the file even after it arrives.
Third, describe the submission flow in plain language. On the Conversation page, describe the sequence: open Bilibili, enter the submission screen, choose the video from the library, fill in title and description, pick category and tags, tap submit. Leave submission for manual confirmation on the first run.
Fourth, freeze it into a workflow. Once it runs cleanly, save it to Workflows and leave title, description, tags and category as parameters. One template then covers a batch of submissions rather than one submission per flow.
Fifth, track with Execution History. After the run, check results in Execution History. Collect submission status and view data on a regular cycle so you can review properly.
If the flow hits a pure icon button with no readable text, add an image template so it knows what the button looks like.
Why I would not make it fully automatic
People ask: if it can be automated, why not automate all of it?
Because of those three upstream factors. Uploading takes time, transcoding depends on the queue, and the review outcome varies. Full automation cannot help with any of them. And when a submission stalls, a fully automatic pipeline is painful to diagnose, because you cannot tell whether it failed or is still waiting for review.
What I would recommend instead: upload by hand with logging, and let the computer handle logging, status tracking and data collection. It sounds less impressive than full automation, but it is far steadier and far easier to debug.
Back to that tutorial team. They did not chase full automation in the end. They split the work in two, with the person and the computer each owning a half. Someone taps upload, which also stamps the time and title into the log. Category, tags, status tracking and view data all go to the computer. In their words it is less stressful than full automation: the waiting still happens, but nobody has to sit and watch it.
For one or two accounts of your own, honestly, the web upload page is more convenient. But if you run several accounts and want them on the same flow as your other platforms, try the steps above, starting with one video.
Frequently asked questions
- What separates Bilibili from short video platforms the most?
- File size and flow length. Short video is usually tens of megabytes. Longer video runs from a few hundred megabytes to several gigabytes, so upload time goes from under a minute to several minutes or tens of minutes, with transcoding and review in between. The bottleneck moves from number of taps to bandwidth and waiting.
- So which steps can actually be automated?
- Automatable: file preparation and distribution, bulk entry of cover and title, submission logging and status tracking, and data collection. Harder to automate: the upload wait itself, platform transcoding and the review outcome. You do not control the timing on those three.
- What is multi-part and why does it need separate handling?
- Multi-part is a Bilibili specific structure where one submission carries several video segments that viewers watch in sequence on a single page. The complication is that segment order, each segment title and which segment acts as the cover all need setting individually, so you are managing a parameter set rather than one file.
- Is running multiple accounts on Bilibili worth it?
- I would be more cautious here than elsewhere. The Bilibili ecosystem runs on individual creator identity. Viewers follow a person, not an account, so ten anonymous accounts may be worth less than one with a loyal audience. If you do it, split by content direction rather than duplicating the same material.
- How long does an upload take, and can they run in parallel?
- It depends on file size and bandwidth. A few hundred megabytes takes several minutes on ordinary broadband. Several gigabytes takes tens of minutes. Parallel uploads compete for bandwidth so total time is not necessarily shorter. Push in batches by device priority instead.
- How long is the review?
- Unpredictable. Machine review is often a few minutes, and anything routed to human review can take hours to a day. That is why batch submissions cannot be managed as publish then immediately verify. You need a mechanism that comes back and checks later.
- How do video files get onto several phones?
- Choose by file size. Small files push in bulk, even across dozens of devices. Large files go in batches, or sit at a reachable address that each device downloads from. On iPhone, grant photo library permission first, or the file arrives but never saves to the library.
- Why not make the whole thing fully automatic?
- Because three upstream things are outside your control: upload duration, platform transcoding and the review outcome. Full automation cannot help with any of them, and when it breaks the troubleshooting cost is high. Manual upload plus scripted status logging is the steadier combination.
Give the automatic parts to the computer
Hand upload and logging to the computer, keep judgement for yourself
Software is completely free and runs on your own computer.