If your looking at implementing the ServicePortal, there are a few things i would recommend.
First and foremost, build yourself a new CSS template and get your branding on it. We've gone from the default template to this (end user view):
The CSS can be a bit hard to reverse engineer (as there is no docco readily available), but if you look in the templates folder ($WebRoot/$PortalRoot/App_Themes) you can see how they created them. The Container.css and ootb.css files are what you want.
The best tools to do all this in is Firefox and the single greatest addon EVER - Firebug. This way you can just 'inspect' each bit of the page and see what the corresponding CSS class is (and edit it). Without it i don't think we could have ever done it. Also make sure to check you changes in whatever your default browser is for your organisation (IEx ect).
We have created a redirect page at the root of our web directory that will take the user to the actual portal. This was implemented as sometimes it can take a bit of time for the thing to actually load (after a restart ect) and we didn't want them seeing a blank page. So we created a nice landing page too:
We made the banner up the top look exactly the same as the ServicePortal banner which gave us a much more seamless experience.
Custom Error Page
You most probably dont want to be giving the end user the default ASPX error page. A nice custom one that has the same look and feel as the portal works quite well. You can do this by opening your web.config file in your portal root directory and updating the customErrors page to this:
<customErrors defaultRedirect="~/yourGeneralErrorPage.aspx" mode="RemoteOnly">
RemoteOnly means that the end user will see the cutsom page, but if you login to the server and generate an error locally, you will see the normal ASPX page with all it's details.
Another really good tip is - do not use the WYSIWYG editor if you can help it. It tends to insert crazy HTML everywhere when you keep re-editing it. We just use the source code all the time. This means that we can just use <h1> <h2> and <p> tags, and our predefined CSS formatting will do the rest. It makes the content really consistent and reliable.
Moving the bigger queries (like complete customer history) to a separate tab worked wonders on the speed too. The end users loved having all their history there (it pretty much made the portal for them), but we found that it slowed down our SelfService tab way too much. If they want to see all their history they just hop to a seperate tab. We do have a 'current open tickets' query too (which they also love).
I'll add more as i think of it, but overall we are really happy with how well it came out.