The main layout issue that I see is that you indicate that you have 100 tasks. that would be 100 columns of data--something that wouldn't fit on a computer screen or printed page very well. A matrix of 100 rows, one per task and a column for each group, on the other hand, would be manageable. And if you only viewed data for a few tasks at a time and hand controls above each column for specifying the task, you could select different tasks to view in the columns of such a report.
Either way, the most common approach is to set up a series of filtered portals. Example:
Each row could be one customer or one group. A series of portals produce the columns of data. Typically one relationship works for all the portals, in this case to list all tasks for that customer or group. A different portal filter is then set up on each column of one row portals to filter for only records for a particular task. A summary field in the task table can then placed in the single row portal to show an aggregate value for all tasks of a specified type for the given customer.
There are many variations of that basic approach. Sometimes the row is a sub summary layout part in order to work from groups of records.
And ExecueSQL calculation fields are now sometimes installed in place of portals to list such data.