Q-Service (Quantum Service) has two major app journeys: one for customers who need services and one for skilled service providers who want to discover and manage work. This tutorial explains both journeys from the first sign-in to the final job outcome, including the rules that can affect what users see and what actions are available.
1. Before you start
Q-Service supports different user roles. A customer uses the app to find and request services. A service provider uses the provider experience to discover relevant work and manage accepted jobs. Some public information can be browsed without signing in, while protected actions require an account.
2. Language selection
Q-Service supports Bangla and English. Use the available language control to choose the language that is easiest for you. Public pages and app information can differ by language while representing the same service workflow.
3. Customer account and sign-in
Customers should use their customer account for protected customer actions. If a guest tries to perform an action that requires authentication, the app can ask the user to sign in before continuing.
4. Customer home and service discovery
The customer experience is organized around finding a suitable service. Home sections and service categories help users browse available options. Always choose the service that most closely describes the actual requirement.
5. Choosing the correct service
Accurate service selection matters because category information is used throughout the platform. Choosing an unrelated service can reduce matching quality. If a specific service option exists, prefer it over a vague category when it accurately describes the problem.
6. Creating a service request
After selecting a service, provide the required job information. Describe the problem clearly and provide the correct service address or area. Where location information is requested or available, accurate location data helps Q-Service determine geographic relevance.
7. Writing a useful requirement
Explain the real symptom or required work rather than writing only a generic phrase. Useful details help a provider understand the job before accepting it. Do not include misleading information simply to attract more providers.
8. Location and service area
The customer's location is important for physical services. Q-Service can use service areas and usable geographic information to identify relevant providers. Correct location information is especially useful near the boundary of two service areas.
9. Submitting the request
Review the selected service, requirement and location before submitting. Once submitted, the request becomes a job record used by the platform's matching and operational workflow.
10. What happens after submission
The job can become available to eligible providers according to service compatibility, location and platform rules. Not every registered provider necessarily sees every job.
11. Following job status
Customers should use the current job status to understand progress. A job can move through stages such as Pending, Accepted, Ongoing and Completed, with additional outcomes such as Cancelled or Returned, Due, Scheduled, Rejected or Reopened when applicable.
12. When a provider accepts
Once an eligible provider accepts the job, the request becomes linked to that provider and moves into the accepted-service workflow. The customer can then follow the job according to the features available in the app.
13. Communication and messaging
Use the app's available messaging or support communication features when clarification is needed. Keeping service-related communication connected to the platform can make the job easier to understand and support.
14. Calling during a job
Direct calling is controlled by the job workflow. In the current Q-Service logic, job calling is associated with the Ongoing stage rather than being universally available at every status. If the call option is unavailable, first check the current job stage.
15. Completing a service
A completed status represents a completed service under the platform workflow. Completion can have payment-related conditions. Customers should ensure that the recorded outcome reflects what actually happened.
16. Cancelled, returned and other outcomes
If a job does not follow the normal completion path, the platform can use other outcomes such as returned, due, scheduled or rejected. These statuses preserve service history and can affect later provider eligibility or job handling.
17. Ratings and reviews
Where rating or review features are available, use them to describe the actual service experience. Fair, specific feedback is more useful than an exaggerated review and helps future customers interpret provider history.
18. Viewing provider profiles
Public provider profiles can contain service specialization, areas, completed-job information, ratings, reviews, skills, experience-related information and verification status where available. Review the current profile rather than relying on one signal alone.
19. Understanding verification
A verified provider indicator means the account has the applicable Q-Service verification state. It is useful context, but it is not an absolute guarantee of the outcome of a future service.
20. Customer notifications
Allow notifications if you want the app to alert you about relevant account, job or message activity. If notification permission has been denied at the operating-system level, the app may need you to grant permission again through the available prompt or device settings.
21. Using Q-Service on more than one device
Q-Service's notification system is designed around registered installations and role links. If the same account is used on multiple devices, each active installation needs valid notification registration for reliable device-specific push delivery.
22. Customer safety and accuracy tips
Use a real service address, describe the actual requirement, review provider information, confirm job-specific cost where needed and keep the recorded job outcome accurate. Never assume that a platform indicator alone replaces normal judgment about a real-world service.
23. Switching to the service-provider journey
The provider experience is designed for skilled people who want to receive relevant service opportunities. Provider registration, profile information, service category, service area, account status and verification can all affect how the account participates in the platform.
24. Creating a provider account
A provider can register with the required account information. Email can be optional where the current registration flow allows it. Registration can create and sign in the account, but being registered and being verified are separate concepts.
25. Provider verification and purchase restrictions
A newly created provider account can be active while still awaiting verification. Applicable platform rules can restrict job purchasing or acceptance until the required verification condition is satisfied. Follow the status shown in the current provider account.
26. Setting up the provider profile
Complete the profile with accurate identity and professional information. Add appropriate profile and cover images, service information, skills, experience-related information and other available fields. A complete profile helps customers understand the provider's professional identity.
27. Selecting services correctly
The provider's registered service category is a major matching input. Select only services the provider can genuinely perform. Parent and child service relationships can be considered by the platform, so accurate categorization improves job relevance.
28. Choosing the correct service area
The registered service area helps Q-Service understand where the provider normally works. Keep this information accurate. Where the app uses current geographic information, fresh location data can improve nearby-job relevance.
29. Provider location freshness
Location-aware matching should not treat an old device location as permanently current. When the app requests or updates location, allow accurate location access when appropriate so the platform has useful recent information.
30. New Jobs page
For the provider role, New Jobs is the main discovery area. It is designed to show open opportunities relevant to the provider under the current matching and eligibility rules.
31. How New Jobs relevance works
Jobs can be filtered or prioritized using service compatibility, location and provider eligibility. Same-area jobs can be important, while nearby jobs from other areas can also be relevant under applicable distance logic. Other-area job views can be ordered by geographic relevance where location data are available.
32. Why a job may not appear
A job may be absent because the service category does not match, the provider is outside the applicable geographic rule, the account is not eligible, the provider has reached an active-job limit, the job was previously returned or blocked for that provider, or the opportunity is no longer open.
33. Active-job limit
Q-Service can restrict new acceptance when a provider already has too many recent active jobs under the platform rule. This is designed to distribute work more responsibly and reduce excessive accumulation of open work.
34. Returned-job block logic
When a provider has already accepted and returned a particular opportunity, blocklist logic can prevent the same job from being offered to that provider again under the applicable workflow.
35. Special-category matching
Some categories can have broader matching behavior than ordinary distance-based services. Providers should therefore rely on the jobs actually shown by the current app rather than assuming every category follows identical geographic rules.
36. Reading job details before acceptance
Open the job details and review the service, requirement, location and available pricing information before accepting. Do not purchase or accept a job solely from a notification without understanding the request.
37. Understanding provider job price
The amount associated with accepting or purchasing a job is a platform-side job-access amount. It is not automatically the customer's final service bill. Customer service cost can depend on labor, parts, products, transportation and the actual work.
38. Base and area-specific pricing
Q-Service can use service-category base pricing and an area-specific override where configured. If an area-specific value is unavailable, the applicable base value can be used. Returned opportunities can follow adjusted pricing rules.
39. Credit balance
Where job purchase uses provider credit, the applicable job amount is deducted from the provider's credit when the acceptance workflow succeeds. Keep sufficient credit if the current platform requires it for the desired opportunity.
40. Accepting a job
When acceptance succeeds, the job becomes linked to the provider and its status changes into the accepted workflow. The platform can also record acceptance history and apply the applicable credit transaction.
41. Where the app goes after purchase
The intended provider navigation is to open the purchased job's details after a successful purchase rather than dropping the provider back into the general job list. From the job-details back action, the provider should return to the provider's own jobs list.
42. Moving from Accepted to Ongoing
Accepted means the provider has taken responsibility for the opportunity. When service work actively proceeds, the job can move into Ongoing according to the available workflow.
43. Calling from the provider workflow
The current Q-Service job logic permits job calling at the Ongoing stage. If the call control is unavailable while a job is only Accepted or in another state, this can be expected behavior rather than a calling fault.
44. Completing the job
Use Completed only when the service has actually been completed and the platform's completion requirements are satisfied. The workflow can require a positive paid amount before completion is accepted.
45. Using Service Notes
For applicable outcomes such as returned, due, scheduled, rejected or reopened states, the workflow can require a Service Note. Write a meaningful note explaining the real situation; this becomes part of the operational history.
46. Provider profile performance
Completed jobs, ratings and reviews can contribute to the public profile information shown by Q-Service. Good profile information and genuine service history can make the provider easier for customers to evaluate.
47. Provider online status
Q-Service can use recent activity information to indicate whether a provider is online or recently active. This indicator depends on recent platform activity and should not be interpreted as a guarantee that the provider will immediately respond.
48. Provider notifications
Keep notification permission enabled and allow the app to maintain a valid device registration. New-job and message notifications depend on successful installation and push registration as well as server-side eligibility.
49. Role changes on one device
If one device is used with different Q-Service roles over time, notification registration needs to remain associated with the correct current role and account. The unified installation design is intended to manage device identity and role links without treating every login as an unrelated physical device.
50. Provider messaging
Use the available conversation features for relevant communication. Support workflows can also allow the Q-Service team to contact a provider and help with account or job issues.
51. Public profile visibility
A provider can be active in the system while public search visibility is controlled separately. Public discovery should depend on the current account status, visibility setting and deletion state, so keep account settings accurate.
52. Profile discoverability
Where public provider pages are available, service specialization, areas, completed work and reviews can help customers and search systems understand the provider. Avoid inaccurate skills or service areas simply to appear in more searches.
53. Using the app responsibly
Do not accept work you cannot reasonably perform, do not misrepresent location or skills, keep job status accurate, use service notes honestly and communicate professionally. These practices improve the usefulness of the whole ecosystem.
54. Common customer troubleshooting
If a protected action does not open, confirm that you are signed in. If notifications do not arrive, check operating-system permission and app registration. If a provider or service is not shown, current area coverage or eligibility may be the reason. If a job appears stuck, review its current status and use support where available.
55. Common provider troubleshooting
If New Jobs is empty, check service category, service area, account eligibility, verification, active-job load and location permission where relevant. If a job cannot be purchased, review verification, credit and eligibility. If calling is unavailable, check whether the job is Ongoing. If push does not arrive, verify notification permission and device registration.
56. Best practice for customers
Choose the most accurate service, write a clear requirement, provide a correct location, follow the job status, use platform communication where appropriate, review current provider information and record the real outcome.
57. Best practice for providers
Keep profile, service category and area accurate; keep location and notification permissions usable where appropriate; review job details before acceptance; maintain enough credit when required; manage statuses promptly; add meaningful notes; and complete only genuinely completed work.
58. A complete customer example
A customer needs AC repair. The customer signs in, selects the correct AC service, describes the cooling problem, provides the service location and submits the request. Eligible providers can receive or discover the job. When one accepts, the customer follows the accepted and ongoing stages, communicates through the available channels and records the final outcome. If review features are available, the customer can leave factual feedback afterward.
59. A complete provider example
An AC technician has a provider account with the correct service and area. The provider opens New Jobs, reviews a relevant opportunity, checks its details and job-access amount, accepts it if eligible and sufficiently credited, then opens the purchased job details. When the service begins, the job moves to Ongoing and job calling becomes available under the workflow. After the real service outcome, the provider records the correct status and required note or completion information.
60. Final rule: trust the current app
Q-Service continues to evolve. Screens, labels, matching limits, eligibility and individual features can change. When this tutorial and the current application differ, follow the current Q-Service application, official service pages and current platform rules.
61. Understanding the three app access levels
Think of Q-Service access in three layers: public browsing, authenticated customer activity and authenticated provider activity. Public visitors can discover information without receiving every protected capability. Customer actions belong to the customer account context, while job discovery and provider work-management actions belong to the provider context. When an expected action is missing, first confirm that the app is currently operating under the correct role.
62. Customer registration checklist
Use accurate account information and keep the phone number or other required identity information under your control. After registration, confirm that the app is using the intended customer role, select the preferred language and allow only the device permissions that are useful for the features you want to use. Accurate account information becomes especially important when support needs to identify your service request.
63. Provider registration checklist
A provider should treat registration as the beginning of profile setup, not the end. Complete the required identity information, choose the correct service specialization and service area, add professional profile information and then check the account's verification state. A registered account can exist before every provider capability is available.
64. Why service taxonomy matters to both roles
The service selected by the customer and the service specialization registered by the provider are two sides of the same matching structure. Accurate classification improves the chance that a request reaches people with relevant skills. Customers should avoid selecting a popular but unrelated category, and providers should avoid adding services they do not actually perform.
65. Parent and child service relationships
Q-Service can consider relationships between broader service categories and more specific service options. This allows matching logic to recognize relevant relationships without treating every service label as completely isolated. Users do not need to calculate these relationships manually; they should simply choose the most accurate option presented by the app.
66. Understanding the New Jobs time window
The provider New Jobs experience is intended for current opportunities rather than becoming an unlimited archive of old requests. The platform can use a recent-job window when presenting opportunities. Providers should therefore check New Jobs regularly instead of assuming an old notification will remain actionable indefinitely.
67. Read indicators and highlighted jobs
Job lists can use read or unread indicators and can highlight a job opened through a notification or deep link. These visual cues help the provider distinguish newly discovered opportunities from jobs already reviewed. They do not change the underlying eligibility of the job.
68. Deep links from notifications
When supported, tapping a relevant Q-Service notification can open the associated screen or conversation instead of forcing the user to navigate from the home page. If a deep link opens the app but not the expected content, confirm that the account and role currently signed in are the ones associated with the notification.
69. Lazy loading and long job lists
Large job lists can be loaded in batches rather than downloading every record at once. When more results are available, scrolling or the current list behavior can load additional items. This improves performance and should not be mistaken for the platform containing only the first visible group of jobs.
70. Nearby jobs from other service areas
A provider's useful work radius does not always end at the named boundary of the registered area. Q-Service can consider nearby opportunities from other areas when service compatibility and geographic rules allow it. Where distance information is available, those other-area opportunities can be ordered so geographically closer work is easier to discover.
71. How provider location is used carefully
Location-aware matching can use a provider's recent usable coordinates, but old coordinates should lose value as they become stale. Q-Service's matching design therefore distinguishes recent location information from indefinitely old location data. Providers who want nearby matching to work well should keep location access usable when appropriate.
72. Lead location fallback
When an exact job coordinate is available, it can provide the strongest geographic reference. If exact coordinates are unavailable, the platform can use maintained service-area location information as a fallback where the workflow supports it. This allows geographic matching to remain useful even when perfect GPS information is not available for every request.
73. Ordinary distance-based matching
For ordinary service categories, Q-Service's current matching design can keep eligible same-zone providers relevant and also consider eligible cross-zone providers within the configured nearby radius. The production logic has been designed around including all eligible providers within the applicable 25-kilometre nearby boundary rather than stopping after an arbitrary small recipient target.
74. The special “Others” service behavior
The general “Others” service can follow a broader district-level rule instead of the ordinary nearby-distance rule. This is intentional because miscellaneous requirements may not map cleanly to a narrow specialist category. Providers should therefore not infer the matching behavior of every service from one category.
75. Provider location freshness window
For nearby matching, Q-Service can reject provider coordinates that are too old to be considered useful. The current matching architecture has used a maximum freshness window of seven days, with newer information naturally being more representative. This is a matching safeguard, not a requirement that a provider must continuously broadcast location.
76. Job eligibility and provider status
Provider eligibility depends on more than distance. The provider must satisfy the applicable account and service conditions, and a job itself must still be in a state that permits provider acquisition. A nearby provider can therefore correctly see no purchase option when another eligibility rule is not satisfied.
77. Understanding the active-job cap
The provider workflow can count recent jobs in active working states and block further acceptance when the configured cap is reached. In the current Q-Service logic, the cap is based on ten relevant active jobs within the recent sixty-day window. Providers should finish or correctly update existing work rather than trying to work around this control.
78. Why returned jobs are treated differently
A returned opportunity has already had a provider interaction. Q-Service can remember that interaction through its blocklist and can also apply different job-access pricing to returned work. This prevents the system from treating a returned opportunity exactly like a brand-new untouched job.
79. Price aging and changing opportunity value
Provider-side opportunity pricing can evolve with the age or state of a job under configured rules. The platform's pricing architecture has included a time-based decay window and returned-job adjustments. Providers should always rely on the amount displayed for the current opportunity rather than remembering an older price.
80. What credit deduction means
Credit deduction is part of the provider-side acquisition workflow. It records the platform cost of obtaining an opportunity under the applicable rules; it does not prove that the customer has paid for the final repair or service. Providers should keep these two financial concepts separate.
81. Failed acceptance and race conditions
A job can be visible to more than one eligible provider before anyone accepts it. If another provider successfully accepts first, a later acceptance attempt should not be assumed to succeed simply because the job was visible moments earlier. Refresh the job state and follow the current app response rather than repeatedly attempting a stale action.
82. Accepted jobs versus New Jobs
New Jobs is for open opportunities. Once a provider successfully accepts a job, it belongs in the provider's own job-management flow. Keeping these concepts separate makes it easier to distinguish market opportunities from work for which the provider has already taken responsibility.
83. Back-navigation after purchasing a job
After a successful purchase, Q-Service is intended to open the purchased job details. When the provider leaves that detail screen using the normal back control, the intended destination is the provider's own jobs list, not the open New Jobs marketplace. This navigation keeps the provider inside the context of accepted work.
84. Why status discipline matters
Job statuses are operational data, not decorative labels. They influence communication, calling, reporting, provider workload and the historical meaning of a job. Providers should update status when the real-world situation changes and should not move a job forward merely to unlock another feature.
85. Pending status
Pending represents an opportunity that has not yet entered a provider-owned service workflow. Customers can think of it as waiting for the next operational action, while providers should treat it as an opportunity only if the app actually presents them as eligible.
86. Accepted status
Accepted means a provider has acquired the job and is now associated with it. It does not necessarily mean the physical service has already started. Providers should review the details and coordinate appropriately before changing the job to Ongoing.
87. Ongoing status
Ongoing means the service relationship is actively being worked. In Q-Service's current call rule, this is the stage in which job calling is permitted. The Ongoing state should therefore reflect genuine service progress, not be used only as a shortcut to expose calling.
88. Completed status
Completed should represent genuinely completed work. The current workflow requires a positive paid amount before a job can be marked completed. Enter financial information accurately and never invent a paid amount merely to close a job.
89. Returned or cancelled status
This outcome is appropriate when the job cannot continue through the normal path. A meaningful Service Note should explain what happened. Returned-job history can affect whether the same provider is eligible for that opportunity later.
90. Due status
Due is available for situations where the service outcome requires a due-related follow-up rather than immediate final completion. Use the Service Note to preserve the actual reason and context so the record remains understandable later.
91. Scheduled or thinking status
This state is useful when the work is not being completed immediately but is genuinely planned or under consideration. Record a meaningful note so the customer, provider and support operation can understand why the job remains unresolved.
92. Rejected status
Rejected records that the job has been rejected under the applicable workflow. The note should describe the real reason rather than using a generic placeholder. Accurate rejection reasons are useful for support and operational analysis.
93. Reopened status
Reopened brings a previously handled job back into an active workflow. Because it represents a change from a previous outcome, the supporting note should make the reason for reopening clear.
94. Service Notes as operational evidence
A Service Note should be concise but meaningful: what happened, what the customer or provider decided, and what the next relevant state is. Avoid meaningless text entered only to satisfy validation. Good notes reduce confusion when support staff later review the job.
95. Customer payment versus parts and transport
A service job can involve more than labor. Product or parts cost and transport cost can be relevant to the overall job record where those fields are used. Customers and providers should distinguish these real service components from the provider's separate platform credit or lead-access amount.
96. Provider online indicator
Q-Service can classify a provider as recently online when the provider has recent activity, historically using a short recent-activity threshold. The indicator is useful for context but should never be interpreted as a promise of immediate availability or response.
97. Notification permission recovery
If notification permission was denied, Q-Service can prompt again when the user enters notification-sensitive areas such as messages or job discovery, subject to operating-system behavior. If the operating system no longer shows an in-app permission dialog, open the device's application settings and enable notifications manually.
98. Why a push notification can fail even when the account works
Push delivery depends on more than login. The device needs a valid push token, the installation must be associated with the correct account and role, permission must be available, and the server must select that installation for the event. A working account therefore does not by itself prove that push registration is healthy.
99. Multi-device provider accounts
Using the same provider account on two devices should not require pretending that only one physical device exists. The installation registry can maintain separate device identities and tokens while associating them with the same provider account. Each device still needs its own valid notification registration.
100. Role shift on the same physical device
If the same installation moves between customer and provider use, the app and backend need to update role links so notifications reach the appropriate context. Users should sign in through the intended role and avoid relying on an old notification generated for a different role session.
101. Messaging notification behavior
A message can exist successfully even if a push alert fails. When troubleshooting, distinguish message storage and conversation delivery from push-notification delivery. Open the conversation to verify the actual message state before assuming the message itself was lost.
102. Conversation deep linking
When message notifications support deep linking, tapping the notification should take the signed-in user toward the relevant conversation. Correct account, role and conversation identifiers are important for this behavior.
103. Provider public profile information
Public provider pages can combine professional identity with performance context, including profile media, completed work, ratings, top services, service areas, recent reviews and related providers where applicable. Providers should maintain factual information because the profile is part of their public professional presence.
104. Related-provider discovery
Public provider discovery can also surface related providers when there is enough completed-work information to justify the relationship. This gives customers alternatives and makes the provider ecosystem less dependent on a single profile.
105. Search visibility is a provider control
Public discoverability is not identical to account activation. Q-Service's public SEO and local-coverage logic excludes providers who are hidden from search or whose accounts are deleted, even if old operational records remain in the database.
106. Why profile completeness matters
A complete profile improves both human understanding and public information quality. Headline, bio, skills, experience-related details, profile media, service specialization and area information should describe the provider truthfully and consistently.
107. Customer New Jobs and service activity views
Customer-facing job views can use recency, area and category filters to help users understand relevant service activity. These browsing views should not be confused with the provider's job-purchase eligibility logic; the two roles use job data for different purposes.
108. Emergency information
Where an emergency-related listing or feature is available, Q-Service can avoid presenting entries that do not have usable contact information. Map actions should be used to understand location context, while the current listing remains the source for the available contact data.
109. Guest protection
Q-Service can allow a guest to browse public information but intercept protected actions and request login. This design lets people understand available services before creating an account without exposing account-specific operations anonymously.
110. App update awareness
Because Q-Service evolves, an older application build may not behave exactly like the current backend or public documentation. Keep the app updated through the official distribution channel so navigation, notification handling and current service logic remain compatible.
111. Permissions should match the feature
Grant permissions based on the features you intend to use. Notifications are needed for timely push alerts; location can improve location-aware workflows. If a permission is disabled, the related feature can be limited even while unrelated parts of the app continue to work.
112. When location permission is unavailable
Loss of device location permission does not necessarily make the entire account unusable. Registered service-area information can still provide geographic context in workflows that support it, but nearby matching may be less precise without fresh usable coordinates.
113. Data accuracy after moving to a new area
If a provider changes the area in which they actually work, update the registered service area and allow fresh location information where appropriate. Keeping an old area indefinitely can reduce the relevance of New Jobs and public provider information.
114. Customer address accuracy after relocation
Customers should enter the location of the service job, not merely a permanent home address that is unrelated to the current request. The provider needs to understand where the physical work will take place.
115. Avoid duplicate or misleading requests
Create a new request when there is a genuine service need. Repeatedly submitting the same misleading requirement can waste provider attention and reduce the usefulness of matching and notification systems.
116. What to do when no provider responds
First confirm that the service and location are accurate and allow reasonable time for eligible providers to discover the request. Availability depends on current provider coverage and eligibility. Use Q-Service support where available if the request requires operational assistance.
117. What to do when the wrong provider appears
Review the service category and job requirement first. If they are inaccurate, correct or recreate the request through the available workflow rather than expecting an unrelated provider to interpret the job correctly. If the request is accurate but matching appears wrong, report it to support with the job reference.
118. What providers should check before travelling
Review the job address, requirement and current status, and use the allowed communication workflow to clarify essential details. Do not rely solely on a push-notification preview before spending time or transport cost.
119. What customers should confirm before service starts
Confirm that the provider and the job shown in the app correspond to the service being performed. Discuss the real scope and any relevant labor, parts or transport cost before work proceeds when those details are not already clear.
120. Handling a changed requirement
If the actual problem turns out to be materially different from the original request, keep the job record and communication accurate. Do not silently transform an unrelated service into another category merely to preserve the original workflow; use support or the appropriate current app action when a new request is more accurate.
121. Support-team involvement
Q-Service's support tools can help staff reach customers or providers and inspect job context. When requesting help, provide the relevant job or account context and describe the exact problem instead of sending only a generic “not working” message.
122. Privacy in public profiles
Providers should treat public profile fields as information intended for public discovery. Avoid placing unnecessary sensitive personal information in biographies, skills or other public-facing text. Use the platform's designated identity and verification fields for information that is not meant to become profile copy.
123. Honest review practices
Customers should review the service they actually received. Providers should not pressure customers to submit false ratings. Authentic feedback makes completed-job and reputation information more useful to the entire Q-Service community.
124. Why completed-job history matters
Completed work is more than a counter. It can contribute to provider profile context, related-provider discovery, customer confidence and platform analytics. Providers should therefore avoid falsely completing jobs that did not actually reach completion.
125. Reading a provider profile intelligently
Look at multiple signals together: relevant specialization, working area, verification state, completed work, ratings, recent reviews and profile information. A single badge, rating or photo should not replace judgment about the specific service requirement.
126. Understanding public local coverage
Q-Service's public local-service pages are designed to represent meaningful current provider coverage. An area can exist in the platform database without every service automatically receiving an indexable public local page. This helps keep public availability claims grounded in real provider presence.
127. Customer expectations about availability
The app is a matching and workflow platform, not a guarantee that an eligible provider is available at every minute in every location. Provider activity, current workload, service specialization and geographic coverage all affect real availability.
128. Provider expectations about job volume
Creating a provider account does not guarantee a fixed number of jobs. Opportunity volume depends on real customer demand, service compatibility, location, account eligibility, competition and current platform rules.
129. Why Q-Service separates customer and provider logic
The customer is trying to solve a service need; the provider is evaluating work opportunities. Their permissions, navigation, notifications and financial concepts are therefore different. Understanding this separation prevents confusion such as treating provider job-access credit as customer payment.
130. Recommended daily provider routine
Open the provider app, confirm the correct role, review notifications, check New Jobs, inspect relevant job details, keep active-job statuses current, respond to legitimate conversations, maintain usable location information when appropriate and make sure the profile and credit balance remain ready for the next suitable opportunity.
131. Recommended customer routine for an active job
Open the current job rather than repeatedly creating a new one, check its status, review the linked provider when accepted, use the available communication path for necessary clarification and confirm the real outcome when service ends.
132. A provider troubleshooting decision path
If no jobs appear, check service and area first, then account status and verification, then active-job load, returned-job restrictions and location relevance. If jobs appear but cannot be accepted, check current eligibility and credit. If accepted work cannot be called, check whether it is genuinely Ongoing. If messages exist but alerts do not arrive, troubleshoot notification registration separately.
133. A customer troubleshooting decision path
If a request cannot be submitted, check authentication and required fields. If no provider connects, verify service and location and consider current coverage. If communication controls are missing, check job status. If notifications are absent, check device permission and registration. Use support with the specific job context when the normal path does not resolve the issue.
134. How to report an app problem effectively
Include the role being used, the screen name, the job or conversation involved, what action was attempted, what actually happened and any visible error. Screenshots can help when they do not expose unnecessary sensitive information. Precise reports allow Q-Service support to distinguish account, job, notification, navigation and device-specific problems.
135. Tutorial maintenance and changing rules
This guide documents the intended Q-Service workflow based on the platform's current project logic. Matching radii, pricing rules, status validation, screen labels and individual features can change as the product develops. The live application and current official platform rules remain the final operational authority.
Conclusion
Use Q-Service as a workflow, not just a list of buttons. Customers get the best result by choosing the correct service, giving accurate requirements and location, following job progress and recording the real outcome. Providers get the best result by maintaining accurate professional information, reviewing jobs carefully, respecting eligibility and credit rules, managing statuses correctly and communicating professionally.