Start with a working product, an industry template and a plan shaped by delivery experience. Agree what the system must do, what your team prepares and how success will be checked.
For a released standard product that meets 80%+ of your agreed needs, with the remainder handled by configuration.
From kickoff to go-live, with agreed data, access and key-user readiness. The remaining needs are explicitly resolved or excluded before starting.
Review the standard routeWalk through the product and industry template, then agree the workflow and gaps before configuration, customisation and integration.
Each phase takes 1–2 months. The plan names the go-live date and the end of initial support separately.
Review the customised routeThe standard product meets 80%+ of the agreed needs, and the remaining agreed needs can be handled by configuration.
We confirm the released product, data readiness, access and key-user participation at kickoff. Major development or new integrations follow the customised route.
Collect requirements and agree the functional requirements document (FRD): what the system must do. Separate standard setup from optional customisation.
Confirm the FRD and configure standard users, roles, rules and templates.
Provide training and a user manual. Support user acceptance testing (UAT), where your team checks the agreed tasks before accepting the system.
Start using the system with the agreed initial support and fine-tuning.
Use the standard product and preconfigured industry template during live walkthroughs, so requirements are grounded in actual work.
Run representative scenarios together. Record the workflow, roles and gaps in the requirements document (FRD), and agree how each gap is handled.
Configure the standard functions and deliver separately quoted customisation or integration, demonstrating progress in stages.
Train key users and run user acceptance testing (UAT) against the agreed test plan. Provide go-live support, extra support soon after go-live and fine-tuning.
The three-to-six-month plan states the formal go-live milestone and the initial support end date separately. Larger projects are scoped against their own dependencies and milestones.
Agree the requirements, responsibilities and acceptance criteria first. Then show working progress and test in stages, using your actual workflow to check the configuration.
The proposal turns these assurances into named scope, dates, responsibilities and acceptance criteria.
Walk through your main process with the standard product and industry template. Agree what is standard, configured or customised.
Confirm the available product, scope and readiness. Standard deployments take 1–2 weeks; customised work follows the agreed 3–6-month plan.
Test the agreed business scenarios. We correct in-scope delivery issues; the related acceptance balance is due when the criteria are met.
Named key users practise the agreed tasks. Additional instruction needed to complete those tasks is provided without an extra training charge.
Itemise the licence or subscription, standard implementation, optional customisation, maintenance and third-party charges. SMERP absorbs underestimated work within the agreed scope; new requests are quoted first.
If a delivery issue caused by SMERP prevents the agreed go-live on time, we fix it at our cost. Your proposal states the related subscription extension or fee credit. The normal billing-start rule is explained in the payment FAQ.
Confirm the available product, agreed scope, data/access readiness, customer decision-maker and key-user participation. Changes or external dependencies are recorded and their effect on the plan is agreed. SMERP-attributable delays activate the stated billing assurance.
The implementation fee covers the following standard services. Optional customisation and integration are separately scoped and quoted.
Collect user requirements and agree the functional requirements document (FRD), which records what the system needs to do.
Configure the standard product against the agreed FRD. Identify optional customisation separately.
Provide training, the user manual and support for user acceptance testing (UAT).
Prepare for launch and provide the agreed go-live support.
The FRD distinguishes standard configuration from optional custom development. The proposal states deliverables, training arrangements, UAT criteria, manual scope and the go-live support period. Annual maintenance is a separate service from included go-live support.
Choose cloud hosting or your own servers, then decide whether you need high availability to reduce service interruptions. We assess your IT environment, data needs and budget with you.
Run the system in a cloud hosting environment, with access and support responsibilities agreed in your proposal.
Run the system on your own servers, with equipment, access and support fitted to your IT arrangements.
A standard setup, without a high-availability failover arrangement. Backup and recovery are agreed for your needs.
High availability (HA) reduces disruption if a system component fails. Your proposal states how the system switches to a backup component and how service is restored.
Your proposal lists the system setup, backup and recovery, required equipment, licences, hosting, maintenance and related fees.
Your team needs the system to keep supporting everyday work. SMERP Care brings maintenance, help with usage and practical issue resolution into the ongoing relationship.
We judge severity by the impact on your daily operations. For covered critical incidents, we guarantee full recovery of normal operations within two hours.
General support requests are usually resolved on the day they are raised. The service result is a resolved issue and a team that can continue its work.
Explain the situation to a member of the support team and get help with the next step. Email support is also included.
The service agreement states the covered incidents, support hours and how the two-hour recovery period is measured.
Customer-requested customisation, new features and major functional modifications are separately scoped and quoted. Standard-feature bug fixes and the security maintenance listed above remain part of the included service.
For a one-off on-premise licence, annual maintenance and support can be purchased separately; first-year maintenance is optional. Your solution states the coverage and renewal arrangements.
Your consultant first understands the work and demonstrates the relevant product, then provides a proposal with the fees and rollout arrangements clearly listed.
Customisation is optional and is not included in the implementation fee. Additional integration, equipment, hosting, HA-related infrastructure and third-party services are itemised where required. All additional work is agreed before it starts.
Amounts, licence scope, maintenance/support coverage, payment milestones, due dates and renewal terms are stated in the proposal. Deployment location and HA configuration are confirmed separately from the commercial model.
Yes. A consultant reviews one everyday workflow, demonstrates the relevant product and gives you a one-page recommendation on suitability and how to start. Detailed requirements, the functional requirements document and implementation are paid services, starting after order confirmation and the agreed initial payment.
The annual subscription and any purchased on-premise maintenance start from the earlier of software licence activation and system go-live. For example, activation on 1 November and go-live on 15 November means a 1 November start. The activation and go-live dates are recorded in the agreed arrangement.
Payment dates are separate from the service-period start. The proposal states the initial payment, any stage payments, acceptance balance and renewal payment arrangements. Work begins after the agreed initial payment is received.
First-year maintenance is optional. The implementation service still includes the agreed go-live support. The proposal distinguishes that support from annual maintenance and states the maintenance coverage and subsequent renewal arrangements.
Implementation covers the agreed standard services and configuration. The requirements document separates these from optional custom development, which is quoted and agreed before it begins.
We fix delivery issues caused by SMERP within the agreed work at our cost. If they prevent the agreed go-live on time, your proposal states the subscription extension or fee credit. This delay arrangement does not change the normal service-period start explained above.
It selects the standard route; it is not a promise to deliver only 80%. Every agreed need is addressed through standard functionality, configuration or a clearly stated exclusion. Needs requiring development move to the customised route.
Test the agreed business scenarios, resolve the required issues, train the key users and complete the agreed acceptance criteria before the go-live decision.
Explain the new need, assess the scope, timing and cost impact, and confirm the change before extra work starts. In-scope correction is not treated as a new requirement.
Book a free initial consultation. See the product using one everyday workflow and receive a one-page recommendation on product suitability and how to start.
Your follow-up is with a product and implementation consultant.
Detailed requirements, the functional requirements document and implementation are paid services. They begin after the order is confirmed and the agreed initial payment is received.
