If I'm understanding you right, you want to set the transaction isolation level to SERIALIZABLE. Assuming MSSQL has true serializability (it might not; true serializability is rarely needed and often quite costly to implement), this will guarantee that even if you execute many transactions at once, the end result will be identical to executing one (though which one is usually non-deterministic), waiting for it to finish, then executing another transaction, and so on. Be careful, though: there are often subtle "bugs", be they actual bugs or misfeatures, in database SERIALIZABLE implementations, since this stuff is really tricky to get right. Especially nasty is the fact that some MVCC-based databases (Oracle and PostgreSQL use MVCC, and I know the Postgres lists were recently discussing these issues with their DBMS) don't really implement SERIALIZABLE perfectly, going instead for what should be called SNAPSHOT isolation -- this gives 99% of the benefits of SERIALIZABLE with minimal performance hit, but that's no good if you fall into that 1%.
If SERIALIZABLE is not an option, either because it doesn't do what you want or for some other reason, you can always have each SP take an exclusive lock before doing its dirty work. This might lead to deadlocks or timeouts and require other tuning elsewhere, so it's kind of an ugly option, but it should do the job.