BCrypt was well designed, and there was much thought put into its operation. There is a special setting included called Work Factor intended to add work when the attacker tries to crack the password.
These two solutions take the same amount of time to compute.
bcrypt(15, bcrypt(15, bcrypt(15, bcrypt(15, "password"))))
(work factor 16 takes twice as long as 15, and 17 takes four times as long as 15)
There is nothing gain in complicating your code process. Just choose the ideal work factor. I usually suggest adjusting the work factor so that it takes ~100ms to complete (with appropriate brute DoS protection) on your target hardware. (noting that attacker hardware would probably be faster)
If you are looking for ways to improve on this, I would suggest pre-pending Pepper in front of the password. Pepper is simply a random string that is not stored with the hash itself. You can either hard-code the pepper in your application, or save it in a separated text file. (not in the database) I recommend using a pepper with 72-bits of entropy. (12 Base64 characters, or 18 hex characters)
Since BCrypt has a max-length of 55-56 bytes, it may be wise to first run an SHA-256 hash on the Pepper and the Password, to achieve a consistent 32 character hex string, which fits nicely in BCrypt. (otherwise, supposing you used a 12 character pepper, any characters beyond a 43 byte password would be truncated) Thanks @Walfrat.