Part 3 of the “Route next hop by calling party” is an exercise of reducing dial-plan dependencies. When working with customers that have several or thousands of different remote offices like retail, we try to create a dial-plan that makes sense for the branch as much as the corporate site and standardization is always top of mind. Our typical branch dial-plan suggestions for these type deployments fit into this model: The branch office has a site code, you can dial between branches with the site code+extension, and within the branch you don’t need to dial a site code to call a local extension.
With these requirements we would end up with a single digit branch access code (#), a 3-4 digit site code and a 2-4 digit extension. In our example we will pretend that each branch has a handful of phones in various areas and that the branch has a 3 digit code provided to them by corporate. We will use that to create a # + <3 digit site code> + <2 digit extension>. Then we can take this same setup and repeat for each branch. When a user needs to call receiving at another store they just need to know the store code and then they will use the same 2 digit extension that they are used to. When users need to call into corporate, they can either dial the users DID which we translate and keep on-net or use a published “universal” pattern for different departmental uses ie – 990010 for shipping etc.
Once we have defined our different sites we build the extensions based on the full number <sitecode>+<extension>. Next we create our dialing habits so the user can dial 2 digit internal numbers. Again we have to create a new calling search space and partition in order to handle our “Route next hop by calling party” logic. In our Branch_RouteByCLID CSS we need to add patterns matching each site code.
For inter-site dialing we simply create a translation pattern match #.XXXXX. Discard Predot and route it through the Branch_DN_PT. This way we can limit our exposure for inter-digit timeout and # makes for a pretty convincing training story “You press # and then the store number. Like ‘number’ 520, then the extension.” 
By routing the internal dialed digits by calling party number it lets us get away with a single calling search space and partition across however many sites you want where in a traditional deployment you would need to create a unique calling search space and partition group for each site to get the same functionality. The lack of calling search spaces does add a bit of complexity in the design though so you have to balance that out. If you have a team doing basic MACD functions in CUCM where you want to lower the knowledge “cost of entry” to CUCM, this might be a good place to look. Less options does mean less chance for screw up. The down side is if an error is made somewhere in that single CSS, you could impact all sites and not just one. But because everything is pretty baked in, the need to make changes on dial-plans is fewer and further between.
Like I said before. This is more of an exercise of whats possible than a “this is how you should do it.”