To answer your original question, yes, it is possible to partition based on the CustomerID as 1 partition for some customers and 1 partition for ranges of customers. Just keep in mind that the ranges of customers cannot contain the customers that you want individual partitions for.

Shifting gears a bit and based on your answers to my questions, (Items 1, 4, and 5 are really important here), I'd probably [font="Arial Black"]NOT [/font]partition by CustomerID. Rather, I'd partition by the DateTime column for all the right reasons to partition. If you (for example) partition using separate filegroups for each month (for example), you'll get even more benefit.

1. If you partition by month (for example) and each partition lives on a single file in a separate filegroup for each month, the you can set "previous months" to read only and stop backing up the entire table. If you (for example) have 5 years of data in the table, this will drop your backups to anywhere from nearly 0 minutes at the beginning of a month to 1/60th (5 years *12 months = 60) of the time it currently takes to back the table up.

2. Index maintenance periods will drop in a similar fashion because you won't need to reindex the older partitions even if they weren't set to read only.

3. Online Piecemeal restores become a possibility.

Some of the queries that are based on DateTime ranges [font="Arial Black"]may [/font] enjoy some performance improvement due to partition elimination. I stress "may" because partitioning frequently does not provide performance benefits for queries and isn't a good reason to partition.

If you intend to "drop" customers from the table, especially on a regular basis, then a different partitioning approach might be in order.