Like opc.three, I would go for option 3. As well as being a truly relational approach (unlike option 2) it is probably reasonably storage efficient.

Option 3 also has the advantage that it is easy to solve what I suspect will be the next problem that you hit: a communication may have different attributes depending on whether it is a customer communication or a job communication or a something else communication, and you need somewhere to put these attributes: the linking tables in option 3 are a suitable place - of course they will then be something more than just linking tables; the communicationhistory table isn't because it has only information common to all communication types and the customer and job and something else tables aren't because they contain attributes of a customer (or a job or whatever) and not attributes of communications. Trying to handle this in option 2 would be problematic, in option 1 it would lead to a proliferation of nullable columns.