Response expectations that work for 10 users often don’t work for 300+ users. These inputs adjust the indicative estimate and help set realistic SLAs.
L1–L2 cover incidents and operational support. L3 covers development/changes. L4 covers proactive governance and planning. Response targets apply within the selected window unless explicitly agreed otherwise.
First line handling for “how-to”, user issues, posting errors with known workarounds, basic permissions and setup checks, ticket hygiene, and escalation packs (repro steps, screenshots, sample data) for L2/L3.
Incident investigation beyond L1: deeper NAV/BC functional troubleshooting, data fixes, configuration changes, liaison with key users, and vendor/ISV coordination where appropriate.
New features, enhancements, integrations, reports, and code-level fixes. Requires a minimum spec pack (goal, scope, acceptance criteria, test scenarios). Work is scheduled; “start now” requests are handled as Emergency Change.
Prevents “everything is urgent”: demand shaping, backlog triage, architectural guidance, quarterly planning, release governance, vendor management, and making specs/test packs good enough that dev is not guesswork.
Response targets apply to L1/L2 tickets. Cadence targets apply to L3/L4 planned work.
Boundary conditions: L1/L2 do not include new development; L3 requires a spec pack; “start now” development is Emergency Change.
£—ex VAT • scaled to your inputs