In this scenario, you have successfully deployed SharePoint for your department and others have started to take notice.  Other departments want to share in your success--even if they need to pay for it.  Since you already have the infrastructure, logistics, and expertise, this could be an opportunity to create an economy of scale in your enterprise despite the decentralization of IT.

You want to start bringing on new "customers" because each department would likely bring their own analysts, developers, and resources.  Not to mention that, as an enterprise, productivity gains from using SharePoint could increase the overall health of the organization.  Only one problem causes you to hesitate:  "If they become our customers, how do we support them?"  This comes down to the SLA (service level agreement).

An SLA typically defines the support relationship prior to entering into the agreement.  Things like backup schedules, restoration times, and maintenance windows need to have clear benchmarks so everyone can feel comfortable with the arrangement.  One of your potential customers wants to feel "plugged in" to the portal.  They have a low user base, so a separate web app would only be a drain on the WFE memory.  They want to use the same domain name.  And they don't have high expectations for data backup and recovery (but you do).  How can you make this customer happy without over-supporting them or making other areas harder to support?

Here's my solution so far, let me know if you have a better one: 
1.  Create the new Site Collection for the customer under the existing web app (port 80 and /or 443). 
2.  Go to Central Administration > Application Management > Content Databases and create a new database (named for the new Site Collection).
3.  Run STSADM -o enumsites on your domain to an output file (see the actual commands).
4.  Edit the output file to include only the new site collection.
5.  Run STSADM mergeconentdbs to move the site collection from your content database to the new one (created in step 3).

Both site collections have the same web app, SSP, and search.  They use different content databases though, so I can set backups according to the SLA and a full restore would be faster for any single database.