Yes most definitively BUT :
- Link rot is going to be an issue, Ideally generate the link dynamically from a known target document but get the prefix from some form of configuration. Should the server change then you can keep older code valid by updating this config element. You can also make the doc locally available also just by changing this prefix config.
- Versioning : In the same spirit, if you can do include versioning in the link in some capacity so that the link always points to the correct version of the documentation.
- Make the doc editable Something like a wiki type site for your documentation where you can dynamically correct mistakes, ideally also allow users to comment directly on the page. this will make it much easier for your users to participate and find what they need and you will get golden information to keep your doc in good working condition but make sure you monitor it regularly and most of all participate actively yourselves.
- Generated templates have your build system generate the basic template for the documentation from annotations in the code directly. Keep it simple though, but this will ensure that every links always points to a valid documentation. If you do use a wiki make sure you can push these templates easily, and make sure you can promote the documentation site the same way you do for your code (have a dev site which is different from the prod site and promoting code to prod will perform the inserts in the prod site automatically).
If you develop with Java or .NET the doc could be included in a jar file or a DLL file and by changing the prefix your code could fetch it locally instead.
If you do choose the wiki approach I warmly recommend DokuWiki for it's simplicity and for the fact it is based on flat text files which would make it very friendly to automated injection from the build system. That said, I do not know enough about your environment or customers to really know if this would be a good fit YMMV.
Some of the most successful tools I've created took a similar approach where the error message was targeted to the actual user that would most likely perform the task. That meant that I had to do a LOT of exception catching and wrapping to make sure the error is at the appropriate level of abstraction. I also made sure that each error message would include the most likely sources of errors and points to potential solutions "Did you forget to set xxxx config value ?", "Make sure xxx and yyy do not conflict by giving them different names" etc. Where XXX and whatnot would be generated from the context where the error occurred.
This approach was somewhat simpler but also more limited. It however had the up-side that the documentation would always be present when needed no link rot possible.
Your approach is the next evolution. Much more complex but also has much more potential returns. It will be costly though but if done right will easily pay off for itself.