What to define before testing
- Modules
- Territories
- Team
- Languages
- Target date
The target date helps plan the project; it is not a guaranteed service timeline.
Implementation · Recommended method
Prepare MapMyStaff around your real rules before opening.
The guide recommends scoping the project, naming owners, documenting business rules and data, preparing a test set, training each role, and validating real scenarios before opening.
Implementation preparation
5 stepsFrom scope to the first live workflows
01
DefineScope and responsibilities
Define02
ClarifyBusiness rules and data
Clarify03
PrepareTest set and role-based training
Prepare04
TestScenarios, edge cases, and decisions
Test05
ProduceProgressive opening and first workflows
Monitor01Scope the implementation
Decide what you want to use — and who owns each part.
The guide recommends defining the modules, territories, team, languages, and a target date. These elements frame what must be prepared and validated.
Name one customer-side owner and one MapMyStaff owner. The guide then clarifies who prepares the rules, configures the product, provides the data, tests, and approves opening.
Who does whatBusiness rules and data are primarily customer responsibilities. Configuration is owned by MapMyStaff product with technical support; testing is a shared responsibility with a joint decision.
01
Expected resultAn explicit scope and named owners before the next implementation steps.
02Clarify your rules and data
Write down how your business really works.
List the services, durations, prices, taxes, zones, availability, absences, promotions, and exceptions that are part of the project.
Prepare only the data that is needed and clean it before testing. Avoid adding information that is not useful.
Before testingSituations are easier to verify when the rules that affect them are already documented.
02
Expected resultClear rules and only the data that is needed.
What to prepare
- Services, durations, and prices
- Taxes, zones, and availability
- Absences, promotions, and exceptions
- Useful data prepared
- Unnecessary data excluded
If something differs, diagnosis compares what was expected with the configuration actually saved.
03Prepare testing and people
Prepare a test set that looks like your operations.
Before opening, the guide recommends a representative test set that reflects what your team will actually do.
Prepare people by role as well: administrator, office, field team, and follow-up owner.
Before openingThe test set and the people involved should be ready before validating real situations.
03
Expected resultA representative test set and the relevant roles ready to test.
Roles listed in the guide
- Administrator
- Office
- Field team
- Follow-up owner
The goal is to test the chosen scope with representative situations.
04Test real situations
Test what really happens in your day — including less common cases.
Validate real situations and edge cases that match the chosen scope.
Record the decisions made, the limits observed, and the approved changes before opening.
What testing confirmsA successful test confirms behavior in the tested context; it does not guarantee that every other case will behave the same way.
04
Expected resultTested situations, with decisions and limits recorded.
What to check before asking for support
- Reproduce the issue in the simplest possible context.
- Change one thing at a time.
- Keep the useful information before trying again.
- Compare what was expected with the configuration actually saved.
- If the issue continues, send only the information needed for support.
05Open progressively
Start progressively and check the first workflows.
After testing, the guide recommends opening progressively and monitoring the first workflows.
This method helps structure implementation. It does not promise a fixed timeline, permanent availability, or a guaranteed result.
What the guide does not promiseThe implementation method does not by itself create a contractual commitment on a timeline, availability, or result.
05
Expected resultA progressive opening based on what was prepared and tested.
What should be ready before opening
- Scope defined
- Owners named
- Rules written down
- Useful data prepared
- Representative test set
- People prepared by role
- Situations and edge cases tested
- Decisions and limits recorded
The guide recommends a progressive opening with monitoring of the first workflows.
06If you need support
Gather the right information without sending more data than necessary.
The guide also documents how to prepare a support request and how to diagnose a behavior that does not match the expected result.
What should be prepared for a support request?
Prepare the page or module involved and the path followed; the approximate date and time; the expected result, observed result, and exact message; a non-sensitive identifier when available; a cleaned screenshot when useful; recent configuration changes; and the browser, device, and language when relevant.
What information should not be shared?
Do not share a password, authentication code, API key, token, or technical secret; a full card number or sensitive payment information; a medical record or personal information without a need; or a complete database copy when a minimal example is enough.
What should you check before sending an issue?
Reproduce the issue in the simplest possible context, change one thing at a time, and keep the useful information. Then compare what was expected with the configuration actually saved. If the issue continues, send only the information needed.
Does the guide define a timeline or guarantee a result?
No. It describes a recommended method. It does not create a service timeline, an availability level, a result guarantee, or a contractual obligation unless a signed document expressly provides one.
Next step
Discuss implementationPrepare implementation around your real rules and real situations.
Bring the modules you are considering, the business rules to document, and a few scenarios or edge cases to validate.