A Marlton organization may need one of three different IT service models: incident support for a specific problem, recurring managed IT for ongoing ownership, or a scoped project with a defined end state. Start by identifying which model applies, then compare providers against the same systems, responsibilities, evidence, and acceptance criteria. A long service list is not a substitute for a clear operating scope.
Which Rivell page should you use?
- This guide explains how to define requirements and compare IT service options for an office in Marlton.
- The managed IT services in Marlton page covers Rivell’s recurring outsourced service for organizations that want ongoing technology ownership.
- The New Jersey IT support page covers user and incident support, while the broader business IT services page maps the available service categories.
Choose the service model before comparing providers
| Service model | Use it when | Evidence to require |
|---|---|---|
| Incident support | A known issue needs diagnosis or repair without transferring broader responsibility. | Problem statement, access approval, work record, resolution test, and unresolved risks. |
| Recurring managed IT | The organization wants continuing ownership for users, devices, platforms, monitoring, maintenance, and escalation. | Responsibility matrix, service boundaries, response workflow, reporting, onboarding, and exit terms. |
| Scoped project | A migration, deployment, upgrade, network change, security improvement, or recovery project has a defined outcome. | Assumptions, design, milestones, dependencies, acceptance tests, rollback, documentation, and handoff. |
Organizations sometimes need more than one model. A Microsoft 365 migration can be a project, followed by recurring administration. An existing internal team may retain strategy while a provider handles the help desk or selected infrastructure. If the business has offices beyond Marlton, compare the regional coverage and onsite assumptions described for managed IT services in South Jersey.
Build a current-state inventory
A provider cannot price or accept responsibility for an environment it has not identified. Create a current-state list covering users, locations, endpoints, servers, network equipment, internet circuits, domains, Microsoft 365 tenants, cloud platforms, line-of-business applications, backup systems, security tools, phone systems, vendors, warranties, and administrator accounts. Record the owner, purpose, support status, and business dependency for each item.
Document known problems separately from desired improvements. Include recurring incidents, unsupported hardware or software, capacity constraints, licensing gaps, incomplete diagrams, shared accounts, missing recovery evidence, and vendor contracts nearing renewal. This prevents a proposal from treating hidden remediation as ordinary onboarding.
Use a responsibility matrix, not a generic service list
For every system, assign who approves changes, who performs work, who monitors it, who receives alerts, who contacts the manufacturer, and who verifies recovery. Distinguish the provider, client, software vendor, internet carrier, equipment vendor, landlord, and any internal IT team. A shared responsibility should name the handoff point rather than assigning the same task to two parties.
The matrix should cover user onboarding and offboarding, endpoint configuration, patching, Microsoft 365 administration, network changes, firewall rules, backup jobs, restore tests, security alerts, incident escalation, domain renewals, vendor access, procurement, warranty claims, and documentation. Review Rivell’s Microsoft 365 implementation and consulting scope, cloud hosting services, and backup and disaster recovery services only where those systems are actually part of the required operating model.
Define cybersecurity and provider access
The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around Govern, Identify, Protect, Detect, Respond, and Recover. Use those functions to ask who owns policy, asset knowledge, protective controls, monitoring, incident decisions, and recovery. The framework is risk guidance, not a certificate or a promise that incidents cannot occur.
A joint government CISA advisory for managed service providers and customers recommends clear contractual responsibilities, secure remote access, multifactor authentication where possible, monitoring, logging, backups, incident planning, and transparent communication. Ask which privileged tools the provider uses, where logs are stored, how technicians are authorized, how access is removed, and how the client can obtain evidence after an incident.
The NIST enterprise patch management planning guide describes patching as a lifecycle of identification, prioritization, acquisition, installation, and verification. A proposal should state which operating systems, applications, firmware, and network devices are included, how exceptions are approved, and how deployment success is verified. Rivell’s cybersecurity services may be evaluated as a separate or coordinated scope depending on the organization’s risk and operating requirements.
Make backup and recovery measurable
Ask what is backed up, where copies are stored, how access is protected, how long data is retained, who reviews failed jobs, and which workloads are excluded. Define recovery point and recovery time objectives in business terms. A backup completion notice is not the same as evidence that a useful restore can be completed.
NIST SP 800-34 Rev. 1 connects contingency planning with business impact analysis, recovery strategies, testing, training, and plan maintenance. Although written for federal information systems, its planning structure is useful for buyers. Require a restore-test schedule, representative test cases, exception records, and an owner-approved recovery runbook for business-critical systems.
Review the provider as a technology supplier
CISA’s SMB vendor and supplier assessment guidance includes a use case for vetting managed service providers that may have critical access to systems or data. Use a consistent questionnaire covering policies, asset management, administrator training, contractual protection, hardening, incident practices, recovery, subcontractors, and material changes.
Request evidence appropriate to the risk. Examples include a security policy summary, access-control process, incident contact path, backup responsibility, insurance documentation, subcontractor disclosure, service report sample, and a list of client-retained credentials. Evidence should be current, scoped, and reviewable. A badge, logo, or broad claim does not establish that a control is operating for your environment.
Define service levels in operational terms
Separate acknowledgement, triage, active work, workaround, resolution, and closure. Define business hours, after-hours eligibility, severity levels, communication intervals, client dependencies, and the conditions that pause a target. Clarify which requests are included, billable, scheduled as projects, or sent to another vendor. If onsite service matters, state the covered locations, dispatch conditions, access requirements, and any separate charges.
Do not compare one provider’s acknowledgement target with another provider’s resolution target. Use sample scenarios such as a locked account, failed workstation, internet outage, suspected phishing message, unavailable application, server alert, and restore request. Ask each provider to classify the scenario and explain the workflow.
Compare proposals on the same scope
| Comparison field | What to make explicit |
|---|---|
| Included inventory | Users, devices, locations, platforms, vendors, and support hours. |
| Exclusions | Projects, after-hours work, onsite visits, licensing, cabling, procurement, compliance work, and unsupported systems. |
| Security ownership | Identity, endpoint, email, network, logging, vulnerability, incident, and third-party responsibilities. |
| Recovery | Covered data, retention, failed-job review, restore tests, objectives, and incident handoff. |
| Commercial terms | One-time fees, recurring fees, minimums, changes, renewals, pass-through costs, and termination. |
| Evidence and reporting | Inventory, ticket data, patch status, backup status, security findings, recommendations, and decision records. |
Use the managed IT services pricing guide to identify pricing inputs, but request a proposal based on the same verified inventory and responsibility matrix. The lowest unexplained total and the longest feature list can both hide scope differences.
Plan onboarding, acceptance, and exit before signing
Onboarding should produce an approved inventory, access register, network and system documentation, baseline findings, unresolved-risk list, support workflow, escalation contacts, and initial improvement plan. Set milestones for credential transfer, tool deployment, vendor introductions, backup verification, monitoring activation, and user communication. State which findings change the recurring price or require separate remediation.
Define acceptance tests for ticket intake, account changes, endpoint enrollment, alert routing, backup status, a representative restore, administrative access, documentation delivery, and escalation. Record failures, corrections, retests, and owner approval. Rivell’s case studies provide project context, but your acceptance record should be specific to your systems and requirements.
Exit terms should cover documentation export, credential return, tool removal, license ownership, configuration handoff, data retention and deletion, subcontractor access, open tickets, vendor introductions, and cooperation with the successor. Name the format, timing, owner, and any fees. A usable exit process reduces dependence on undocumented provider knowledge.
Require evidence that supports business decisions
A recurring report should help an owner decide what needs attention, not simply count activity. Ask for a stable inventory, important changes, unresolved risks, support trends, aging devices and software, patch exceptions, backup exceptions, restore-test results, security findings, license changes, vendor issues, upcoming renewals, and recommendations with an owner and target date. Separate observations from verified facts and label assumptions that still need investigation.
Agree on how recommendations will be prioritized. Useful fields include the affected business process, likelihood, impact, current control, proposed action, dependency, estimated effort, decision owner, due date, and disposition. Keep declined or deferred work in a decision log so the provider and client share the same record. If a recommendation becomes a separately priced project, require the proposal to reference the original finding and define the expected end state.
Before selecting a provider, ask for a representative service report and walk through it using a realistic scenario. Confirm who receives the report, who can challenge the data, how corrections are recorded, and which issues trigger immediate communication instead of waiting for a scheduled review. Reporting frequency should match the organization’s risk and decision cadence. More frequent reporting is not automatically more useful when the underlying evidence is incomplete.
Use final decision questions
- Which systems and responsibilities are included, excluded, shared, or assigned to another vendor?
- What access will the provider receive, how is it protected, and how is it removed?
- How are incidents classified, communicated, escalated, documented, and closed?
- What recovery evidence will be produced, and who approves the results?
- Which onboarding findings can change scope, price, or schedule?
- What information, credentials, configurations, and licenses remain client-owned?
- How will the client verify onboarding completion and obtain a usable handoff at exit?
Prepare for an IT service review
Bring your location list, user and device counts, application inventory, current providers, support history, known risks, renewal dates, security requirements, recovery objectives, and desired decision date. Mark what must remain client-owned and what may be assigned to a provider.
If recurring outsourced ownership is the intended model, review Rivell’s managed IT services in Marlton. If the model is still unclear, request a scoped technology review and use this guide to document assumptions, exclusions, evidence, and acceptance criteria before comparing a proposal.
