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.
A retainer is for customers who want predictable access to an engineer for incidents and change work. Selecting a retainer applies to L2–L4 (incident investigation, development, and governance). L1 remains optional.
Priority queue position and predictable availability for higher-level work. Best when you regularly need incident investigation, development changes, or governance/roadmap support and want faster engagement than ad-hoc support.
If the retainer is selected, L2–L4 are treated as covered by the retainer (the lane toggles stay visible for clarity). 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.
Retainer (if selected) sets the engagement response target for L2–L4. L1 remains separate.
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