Change requests · How it works
Requesting a change, from first idea to go-live.
You raise one ticket. Mercans turns it into a formal change request (CR) document, assesses it, and sends it to you for approval. Nothing is built until you approve, and nothing reaches production until it has been tested and accepted.
Is it a change request? Yes No
Choose what best describes your situation.
Raise a ticket with the category "Change Request".
Use step 2 below to see exactly what to include for your type of change.
This applies to anything that departs from your agreed scope or documented requirements, even if Mercans spotted the need.
Raise a standard support ticket.
No CR is needed. Describe what is happening, what you expected, and the employees and pay period affected.
The fix is tested in Acceptance and confirmed in the ticket before release. See the process.
Nothing to raise.
Mercans implements statutory changes for all affected clients and notifies you by email, with 5 business days to object.
If you want a regulatory change handled differently from the standard, raise a CR with the type "Regulatory".
What to put in your ticket
There is no form to download. You raise a ticket in the Support Center with the information below; Mercans then prepares the CR document for you. Select your type of change to see exactly what we need.
Your description must cover
- Which report is new or which report changes
- The fields to add, change or remove, and their format
- The employee groups and pay periods it covers
Technical details to include
- Lists of values not yet in the system
- Calculation formulas and validation rules
- The file format (xlsx, csv, pdf…)
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
Mandatory attachments, or the CR is returned:
- Technical specification
- Sample file in the exact target format
Your description must cover
- Which file is new or changes, and its direction (inbound or outbound)
- The data elements, their mapping and format
- The frequency, timing and delivery method
Technical details to include
- Data flows and mapping rules
- Validation and rejection rules
- File format and encoding (txt, csv, xml…)
This change needs an end-to-end test-file run. Have your test tenant ready and tell us if a bank or vendor sandbox needs dummy or anonymized data.
Mandatory attachments, or the CR is returned:
- Sample calculations
- Test scenarios with expected outcomes
Your description must cover
- The wage type or calculation to add or change
- Who it applies to and from which pay period
- Its tax, social security and reporting treatment
Technical details to include
- Calculation formulas
- Lists of values not yet in the system
- Validation rules
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
Your description must cover
- The functionality or screen required
- Who uses it and what they need to do
- The data shown or captured
Technical details to include
- Screen mock-ups or user journeys
- Validation rules
- Data flows
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
Mandatory attachments, or the CR is returned:
- Copy of, or reference to, the regulation
Your description must cover
- The regulation and how you want it applied
- The effective date and pay periods affected
- The employee groups affected
Technical details to include
- Calculation formulas
- Expected results for sample employees
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
Your description must cover
- The pay periods involved
- The number of employees affected
- The data elements to change
- The expected result
Technical details to include
- Lists of new values
- Calculation formulas
- Validation rules
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
Your description must cover
- The scope or schedule change: new entity, country, module, service, payroll calendar or cut-off
- Headcount and pay frequency, where relevant
- The effective date
Technical details to include
- Entity and registration details, for new entities
- Current and requested calendar, for schedule changes
Include test scenarios and measurable acceptance criteria, for example "net pay matches expected for all 25 scenarios".
- Category
- Change Request
- Subject
- CR – UAE Entity – Add cost center to payroll register
- Priority
- High, Medium or Low, based on payroll impact
- Description
-
- Legal entity and country
- Requested go-live date
- The change and why you need it
- Employees affected and payroll impact
- Fallback if it is not live in time
- Test scenarios and acceptance criteria
- Attachments
-
Report mock-up or example layoutTechnical specification Sample file in the exact target formatSample calculations Test scenarios with expected outcomesScreen mock-up or user journeyCopy of, or reference to, the regulationEmployee list with old and new valuesSupporting documents for the new scope or schedule
One ticket per change, per entity.
Raise a ticketRequests sent by email or chat, or tickets missing mandatory attachments, are returned before assessment starts.
The CR document
From your ticket, Mercans creates the formal CR document, named like CR07_Client_Country_Description, in the CRs folder of your shared drive. You can view and comment on it at any time. Select a section to see what it contains.
Header
- Ticket number
- Legal entity and country
- Requested go-live date
- Priority
You provide this information in your ticket; Mercans transfers it into the CR document for you to check.
Change type & description
- Type of change
- Full description of what is needed
- The business reason for the change
You provide this information in your ticket; Mercans transfers it into the CR document for you to check.
Your impact assessment
- Your view of the risk
- Whether payroll calculations or net pay change
- Number of employees affected
- Your fallback if the change is not live in time
You provide this information in your ticket; Mercans transfers it into the CR document for you to check.
Testing plan & acceptance criteria
- Test scenarios with expected outcomes
- Measurable acceptance criteria
- Preferred test data, if you have a preference
- Whether a test-file run with your test tenant is needed
You provide this information in your ticket; Mercans transfers it into the CR document for you to check.
Attachments
- Links to every supporting document
- Mandatory items for your type of change: specification and sample file, sample calculations, or the regulation
You provide this information in your ticket; Mercans transfers it into the CR document for you to check.
Mercans impact assessment & test plan
- Feasibility and risks
- Risk level, which sets testing depth and lead time
- Teams involved and target completion date
- Mercans test plan
- Documents to update: scope, SOP, wage type catalog, data dictionary, report book, blueprint
Your approval
- Your formal approval of the full CR
- Or a link to your approval by email or signed PDF
- Nothing is built before this section is complete
The full process: 14 steps, five phases
Select any step, or use Next to walk through it. Each step shows who owns it, what happens, what we need from you, and what you get.
Identify the need
What happens
- You identify a need for something new or different.
- If Mercans spots a deviation from agreed scope or documented requirements, we tell you immediately.
- Unsure whether it is a CR? See step 1 of this page or ask your account manager.
Your input
- What you need and why
- Your target go-live date
Outcome
- Agreement that a CR is the right route
Prepare your request
What happens
- Gather the information for your type of change (see What to put in your ticket).
- Collect every mandatory attachment.
- If Mercans identified the need, we prepare the request and approve it internally first.
Your input
- Description, impact, test scenarios and acceptance criteria
- Supporting documents
Outcome
- A complete request, ready to submit
Raise the ticket
What happens
- Raise a ticket in the Support Center with the category "Change Request".
- Write the request in the description and attach all supporting documents.
- One ticket per change, per entity.
Your input
- CR ticket with request and attachments
Outcome
- CR ticket registered
Completeness review
What happens
- We check the request is complete and that a CR is the right route.
- Incomplete requests are returned with exactly what is missing.
- We confirm priority and ask any questions in the ticket.
Your input
- Answers to our questions
Outcome
- Request accepted for assessment, or returned
Impact analysis
What happens
- We create the CR document in the CRs folder of your shared drive, from your ticket.
- We assess feasibility, risk on five dimensions, payroll-calculation impact and the teams involved.
- We set the test plan and target completion date.
Your input
- More detail, only if needed
Outcome
- Mercans impact assessment and test plan
- Risk level, which sets testing depth and lead time
Documentation impact
What happens
- We identify every document the change affects: SOP, wage type catalog, data dictionary, report book and blueprint.
- Proposed SOP changes are made in suggesting mode and linked in the CR.
Your input
- None
Outcome
- Documentation impact recorded in the CR
Functional approval
What happens
- The owner of the area the change touches approves the assessment: product, configuration and integrations, or compliance.
- Scope, schedule and mass data changes go straight to delivery approval.
Your input
- None
Outcome
- Functional sign-off recorded
Internal approval
What happens
- The Director of Operations (live clients) or Implementations Director (during implementation) approves, then the Head of Strategic Accounts.
- High-risk changes are also reviewed by the Change Committee.
- Internal comments are removed and the CR is shared with you.
Your input
- None
Outcome
- CR document ready for your approval
Your approval
What happens
- Review the full CR, including our impact assessment and test plan.
- Comment in the document if anything needs to change; edits restart approval.
- Approve in section 7, or by email or signed PDF linked to the CR.
Your input
- Approval from your authorized contact
Outcome
- Approved CR: work can start
Final checks & build
What happens
- Quality, Compliance & Risk Management and Finance complete final checks.
- We build the change in the Acceptance environment, never directly in production.
- Client-specific changes are built on a client test entity, a replica of your current setup.
Your input
- None
Outcome
- Change built and ready to test
Testing
What happens
- We test against the agreed plan in Acceptance.
- Integration changes get an end-to-end test-file run with your test tenant.
- All results are evidenced in the ticket.
Your input
- Your test tenant and test files, for integrations
Outcome
- Evidence pack: scenarios, files, expected vs actual, logs
Your acceptance
What happens
- Check the outputs against your acceptance criteria.
- Confirm acceptance or raise findings in the ticket.
- Without feedback within 3 business days, outputs are treated as accepted.
- Findings are fixed and retested before go-live.
Your input
- Acceptance or findings in the ticket
Outcome
- Recorded acceptance
Production deployment
What happens
- We promote the tested change to your production entity in the agreed window.
- A documented rollback plan is ready for every change.
- The client test entity is deleted within 15 days of testing.
Your input
- Confirmation of the deployment window, if asked
Outcome
- Deployment confirmation in the ticket
Documentation & closure
What happens
- We finalize the SOP, wage type catalog, blueprint, data dictionary and report book.
- The ticket is closed with the full history of requests, approvals, tests and deployment.
Your input
- Acceptance of your updated SOP
Outcome
- Up-to-date documentation
- A complete audit trail
Who approves your CR
Every CR is approved inside Mercans before it reaches you. The route depends on the type of change.
- Step 7 Functional owner Configuration & Integrations lead approves the assessment.
- Step 8 Delivery director Director of Operations for live clients, or Implementations Director during implementation.
- Step 8 Head of Strategic Accounts Final internal approval. High-risk changes also go to the Change Committee.
- Step 9 Your approval In section 7 of the CR document, or by email or signed PDF.
- Step 10 Final quality & finance checks Completed within 2 business days, then the build starts.
How approvals work
- Internal approvals run in parallel and complete within 3 business days.
- Overdue approvals are escalated.
- Internal comments are removed before the CR is shared with you.
- Any edit after approval, by either side, restarts approval.
How you approve
- In section 7 of the CR document in your shared drive.
- Or by email or signed PDF, linked to the CR.
- Approval must come from your authorized contact.
- No work starts before your approval.
Other approval routes
- Changes Mercans identifies: approved internally first, then sent to you for approval.
- Statutory and Mercans-initiated changes: a notification with 5 business days to object.
- Emergency changes: senior technical or executive approval; still tested first.
Timings and ground rules
Business hours for our first response to your CR ticket.
Business days for Mercans' internal approval of the assessment.
Business days for your feedback on test outputs. Without feedback, outputs are treated as accepted.
Typical delivery after approval. Minimum lead times by risk level are in Risk.
- No approved CR, no work. Nothing is assessed in depth, built or deployed without a formal CR.
- One change, one entity, one CR. It keeps assessment, testing and the audit trail clean.
- Everything in the ticket. Questions, decisions, test evidence and acceptance are all recorded there.
- Tested in Acceptance first. Every change is tested and accepted before it reaches production.
Raise a ticket with the category "Change Request".