In purist terms, you should have a common data class which is exported from the service classes and can be formatted by the Output classes. That way you can add new Outputters or a new service without needing to modify existing code, as long as they use this common intermediate class. Check out
loose coupling for more info.
Adjunct: the application I'm working on lets users manipulate the business object graphs themselves for export, custom wizard building, etc. Sometimes the graph is presented in a tree-view, and sometimes in cascading popup menus. But both ways are essentially a tree with nodes, some of which have child nodes. So I'm going to write wrapper classes around TreeView, TreeNode, PopupMenu and MenuItem, which implement common interfaces so I can write a single class to populate both without mucking about. Then when I add a WPF-based UI, I can simply write another wrapper and all the existing code will
Just Work™.
Singletons are generally bad, btw. There's a difference between only needing one instance of a class, and
needing only one instance of a class.