Service Acceptance Criteria

[BorisBear]

I work for one of the world largest vendors and amazingly they size development effort by 'the finger in the air' method.............bear with me, this is relevant.

So I'm wanting to put some service acceptance criteria in place for the warranty/post go live support period for project changes and there are 2 ways I could go with this:

1) Base the criteria on size/complexity of the change (change of X size is allowed a maximum of X change related warranty incidents).
2) Base the criteria on a % of steady state incidents that we see in Live/Production/Maintenance support.

or indeed a combination of the two.

Option 2 is difficult to execute because we have many project changes going into each Release so trying to apportion to each project is very unscientific.

Option 1 would be ideal if we sized developments (e.g. Function Points), but we don't so I'm struggling to come up with something equitable which projects would agree with.

Has anyone got any useful advice or experience of working through a similar scenario.