In Creating Complexity Where None Existed, I noted that it's possible to create complexity out of thin air.
Indeed, by wallowing in the supposed drama, one can turn the differences between sales and service delivery into a hopelessly complex situation. A focus on a manufactured "conflict" leads to the following question: "What are the standard techniques for conflict resolution ?"
Standard Techniques. Conflict Resolution.
First, there's no "conflict". Sales offers something. The customer may or may not understand that offer. The customer commits to something. Sales may or may not understand what the customer thinks they're buying. And delivery has to fill in these gaps between what sales offered and what the customer thought they were buying.
It's very simple. I called the lawn service, asking someone to mow my lawn. But they didn't trim my hedge. No one asked me if I had a hedge. I didn't have one when I called. I had it put in after I placed the order for the services. Is this "conflict"? Does it require "resolution"? Or, does it require that the folks selling the services on the phone and the folks delivering the service have some smarter way of coping with the inevitable differences of understanding?
Reality
The trick to avoiding 482 words of drama (using code names!) to describe sales and delivery is simple. Get Out Of Fantasy Land.
In the real world, sales has one view of the order, and delivery has a different view.
This is not news. Accounts cope with this variability all the time. They ask people to create a "budget" or a "plan". And then they measure actual expenditures against the budget. Budgets changes. Actuals don't match the budget. This is not "conflict". There's nothing to "resolve".
There's planned and actual and they're different.
The real sales promise, memorialized in an "order" is one thing. This order can change, of course, making things complex.
The delivery on that promise, memorialized in an "invoice" is another thing. The delivery may be done in "scramble" mode; folks struggling to balance ability to deliver against promises made. Or, the delivery may be done in a more leisurely pace; the work being fit in to a schedule as time and resources permit.
Ideally -- of course -- order and invoice match. In reality, they don't always match.
Before the invoice is sent, someone needs to be sure it matches reality; someone has to affirm that the work was actually done. It may not be what the customer ordered, in which case there will be issues to resolve.
But there is not "conflict". There's no "drama". We don't need to assign code names ("Flintstones", "Rubbles") to sales and delivery.
Above all, we don't need to impose a weird legacy software world-view on something as simple as order, delivery and invoice. Sales has orders. Delivery has invoices. Hopefully, sales order changes get to delivery in time to adjust what's really happening. Some has to look at the mismatches and exceptions to determine what the consequences are. Maybe the customer gets a credit. Maybe someone sales is over-promising. Maybe someone in delivery, is under-delivering.