These sort of questions come up when seeing blockchain "only" as a new database technology. However, we are forced to think in a new - decentralised - fashion: It is solely up to the miner to select transactions from the backlog - currently we have a few thousand transactions waiting to be mined.
Keep in mind that the selection and ordering of transactions in a block is not defined in the protocol and can hence be implemented differently by different clients or client versions. While two transactions from the same sender will be executed in the order of their nonces, you do not know how many other transactions of other accounts will be included in between.
But practically it's not that bad: Usually miners sort transactions by gas price first (check the gas price of all transactions in some block to see for yourself), so you could try setting an unusual gas price (e.g. 23.0000023 GWei). Now you should have increased chances of having them in the same block, because many people choose 21GWei so there is a chance the clients dont order by account and just randomly split your tx up. This also depends not stability of network latency, specific client behaviour, so is likely not going to get you as far as you'd like to.
Beyond that, at high level there is no way to enforce transactions in the same block. However, if at least one of the functions is in a contract that you are currently writing yourself, you could re-structure to execute both functions in one transaction. This is in any way usually a lot more gas-efficient as you would not have to pay the 21'000 flat fee for the second tx - for simple function calls without too much data and storage writes this is usually significant. Of course this does not always work and would notably fail for restructured versions of a token
transfer() because the
msg.sender is different.