Get help with the decision in front of you
A useful software conversation starts with the work your team needs to perform. You may be replacing paper job cards, finding a better way to allocate technicians, or checking whether your office can invoice completed jobs without chasing missing information. Tell us which part of that process is difficult today. A short example of a real job often explains the requirement better than a long list of software features.
Use the contact form above for a business enquiry, an evaluation question or a request to discuss your requirements. If you already have an account, identify your company and describe the screen or workflow involved. Keep passwords, payment card details and unnecessary customer information out of the message. You can explain most problems using a job reference and a description of what happened, without sending the full customer record.
If you are ready to explore the product yourself, start a trial. If you need to compare costs first, use the pricing page. For a structured conversation about fit, request a demo and include the process you would like to see. These paths support different stages of a decision; there is no need to prepare a formal purchasing document before asking a practical question.
Choose the enquiry that matches your situation
| Your situation | Helpful information to include | Useful next step |
|---|---|---|
| Evaluating job card software | Trade, current process, active team size and biggest administrative problem | Review one representative job from request to completion |
| Comparing subscription costs | Plan under consideration, active users, billing cycle and VAT basis | Check the calculator and request clarification on anything outside the listed subscription |
| Setting up an account | Company name, completed setup steps and the next task you need to perform | Resolve the specific setup obstacle |
| Reporting a product problem | Page, approximate time, device, expected result and actual result | Supply a reproducible description with sensitive information removed |
| Preparing a procurement submission | Scope, user count, term, deadline and required document format | Confirm commercial assumptions before requesting a formal quote |
| Asking about data or privacy | Type of request, account relationship and a way to verify the requester | Follow the privacy contact process |
Prepare a work order software demo around a real job
Bring one job that represents an ordinary working day. For a maintenance business, this might be a reported fault at a customer site. For a cleaning contractor, it might be a scheduled visit with a checklist and completion evidence. For an installation team, it might involve a quotation, customer approval, materials and a return visit. Explain the sequence your team follows today and where information goes missing.
Identify the people involved. The customer who reports a problem may be different from the site contact who grants access or the person who approves payment. Your dispatcher may assign work while a supervisor checks the outcome. Showing these responsibilities early helps establish whether the workflow supports your real operating arrangement. It also makes permissions and account setup easier to discuss.
Define a successful outcome for the demonstration. Examples include assigning a job to the correct technician, recording a clear completion note, identifying work awaiting approval, or producing an invoice from the agreed job information. Avoid evaluating a product only by the number of menu items. A convincing demonstration should show how your team gets a particular piece of work finished and what happens when that work cannot proceed as planned.
Include the exceptions your team encounters
Service work rarely follows one perfect sequence. A customer may not be available when the technician arrives. A replacement part may need approval. A technician may find that the reported fault differs from the actual problem. A job may require another visit, or the office may discover missing information before invoicing. These are useful scenarios to raise in a demo because they expose how the product handles everyday interruptions.
Tell us which exceptions occur often enough to affect your operation. Describe the decision the team makes, who is allowed to make it and what record you need afterward. If a particular behaviour is essential, ask to see it in the current product. Do not treat a discussion about a possible future improvement as confirmation that the capability is available in your subscription today.
Tell us about your team and service area
WorkOrderPro enquiries can cover a single owner-operated business, an office with several technicians or a service company working across multiple customer sites. State how many people need their own account and what each person does. Include active administrators and dispatchers alongside technicians when describing the team. This makes the subscription estimate and access discussion more useful from the start.
Describe where the team works in practical terms. A company serving nearby residential customers may have different scheduling needs from a contractor covering dispersed commercial properties. A business operating in Johannesburg, Pretoria, Cape Town, Durban or another South African area should explain its actual travel pattern, customer access windows and dispatch responsibilities. The city name alone does not determine the right workflow or subscription.
Connectivity also matters. Tell us about the devices and connection conditions your technicians encounter, and identify the actions they need to perform while away from the office. Ask for a demonstration of those specific actions on the device you plan to use. Do not assume that every screen, upload or workflow has the same offline behaviour. Verify the required device experience during your evaluation before committing the whole team to a rollout.
Ask clear questions about pricing and billing
Use the current WorkOrderPro pricing calculator as the starting point for a cost discussion. State the plan, billing cycle and active team size used in your calculation. Active administrators, dispatchers and technicians are part of the billable team; disabled accounts are excluded. If you expect staffing changes, explain the likely range rather than requesting an estimate for only the smallest possible team.
Keep subscription charges separate from implementation requirements. You may need data preparation, workflow advice, staff training, a procurement document or an integration assessment. Ask which items are included in the published subscription and which require a separate agreement. Do not assume that a request for a demo includes custom development, migration services or an ongoing managed service.
For a funding application or procurement budget, specify whether the ceiling includes VAT, whether it covers one month or a full year, and whether once-off services must fit inside it. Include the required subscription term and the date by which the quote is needed. These details prevent a technically correct price from answering the wrong commercial question. Any special scope or price needs written confirmation before it becomes part of your purchasing decision.
A practical commercial enquiry checklist
| Item | What to state | Why it matters |
|---|---|---|
| Team accounts | Number of active users, including office roles | Establishes the seat assumption |
| Billing term | Monthly or annual subscription | Establishes the payment period being compared |
| Tax basis | Whether your budget includes VAT | Prevents incompatible totals |
| Setup scope | Data preparation, training or other requested assistance | Separates software access from additional work |
| Required capabilities | Essential job, approval, reporting and invoice workflows | Helps assess plan fit |
| Procurement timing | Submission deadline and intended start date | Distinguishes document urgency from rollout timing |
| Approval process | Who signs off the purchase and what evidence they require | Helps prepare a relevant response |
Get useful help during your trial
A trial is easier to assess when you choose one small end-to-end objective. Start with a customer, a site and a representative work order. Assign responsibility, record the work and review the information the office needs afterward. Keep the initial example small enough that you can see where each piece of information comes from. Once the basic flow makes sense, test a more demanding scenario.
When you contact us during a trial, explain what you have already completed and what you are trying to do next. “I created a customer and now need to assign the first site visit” is more actionable than “setup is confusing.” Include the page name and the result you expected. If the problem is a term rather than a technical error, tell us what your team calls that part of the process.
Involve an office user and a field user in the evaluation where possible. The dispatcher may find a screen clear while the technician cannot find the information needed on site. Compare both experiences before judging the workflow. Keep a short list of unanswered questions and separate essential requirements from preferences. This makes the eventual subscription decision more defensible within your own business.
Report a technical problem without exposing sensitive information
Describe the smallest sequence that reproduces the issue. Include where you started, which action you selected and what happened afterward. Note whether the problem happens every time or only under particular conditions. If there is an error message, quote the relevant text after removing any personal information. A clear sequence helps distinguish a validation message, a permission issue and an unexpected application failure.
Include the approximate date and time, your browser or app version if available, and the device type. Explain whether a different authorised user sees the same problem. Do not share another person's login or ask a colleague to send their password. If the issue involves access, describe the role and account state instead. For attachments, remove customer addresses, identity numbers, private messages and financial details that are unnecessary to understand the problem.
If a save or payment action appears uncertain, first check the existing record or billing screen before repeating it. In your support enquiry, state whether you retried and whether a record or payment confirmation appeared. This context helps with investigating possible duplicates. A support enquiry is not an instruction to perform emergency work at a customer property; follow your own operational escalation process when a live service situation needs immediate attention.
Discuss migration from spreadsheets and paper job cards
Describe the information you currently keep and where it lives. A typical business may have customer details in a spreadsheet, site notes in messages, quotations in documents and job photos on individual phones. Start by identifying which records you need for ongoing work. Moving every historical file is a different project from preparing a clean list of customers and open jobs for a new operating process.
Ask about the supported import path and required fields before sending a large data export. A small anonymised sample can show the structure without exposing the entire customer database. Explain relationships that matter, such as one customer with several sites, a property manager paying for work at different addresses, or several contacts attached to the same account. These relationships affect preparation more than the spreadsheet's visual layout.
Agree on responsibility for cleaning duplicates, checking contact information and approving the final records. Keep a recoverable copy of the original data in your own controlled storage. Validate a small sample in the intended workflow before expanding the migration. If historical attachments, financial balances or another system's identifiers are required, raise those requirements explicitly; do not assume they are covered by a basic customer import.
Raise integration and reporting requirements early
Name the other system and describe the information that needs to move between it and WorkOrderPro. For example, explain whether the office needs an invoice export, a report of completed jobs or a connection to an accounting workflow. State the direction, timing and owner of the transfer. “We need integration” is too broad to establish whether an existing feature meets the requirement.
For reporting, describe the decision the report supports. A dispatcher checking unassigned work needs a different view from an owner reviewing completed jobs or a customer asking for service evidence. Include the fields, filters and reporting period you need. If a customer requires a particular document layout, provide a redacted example and identify which elements are mandatory. Confirm current support and any additional scope before promising that format to your customer.
Frequently asked questions about contacting WorkOrderPro
Can I ask a question before starting a trial?
Yes. Use the contact form to describe the decision you are making and the workflow you need to support. Include your trade and approximate active team size where relevant. You do not need a completed requirements specification to ask whether the product is worth evaluating. For a detailed comparison, identify the capabilities that would determine your decision.
What should I include when requesting a demo for a service company?
Describe one representative job, the people involved and the outcome you want to see. Include an exception such as a return visit, customer approval or missing completion information. State which device your field team uses and whether office users also need access. That gives the discussion a concrete starting point and keeps it relevant to your operation.
Can you confirm that a specific feature is available?
Ask about the exact task and the plan you are considering. Request a demonstration or a clear written answer based on the current product. A broad feature label can cover several different behaviours, so describe the result you need. Treat future development discussions separately from capabilities you can verify and use during your trial.
How should I ask for help with an existing account?
Include your company name, the affected page, the approximate time and a short explanation of the expected and actual result. Use a job reference where it helps, but remove unnecessary customer information. Never send passwords, one-time codes or payment card details. If you cannot sign in, say which step fails and whether you used the password-reset process.
Can I request a quote for an annual subscription and onboarding?
Yes. State the active team size, subscription term, required setup work and whether the budget includes VAT. Include any submission deadline and procurement requirements. Request separate line items for subscription access and additional services so your approver can understand the scope. A custom price or service commitment only applies once it has been expressly agreed.
Where should I send privacy or data-access questions?
Use the privacy contact details provided on this page and in the privacy policy. Describe your relationship to the account and the type of request. Identity and authority may need to be established before account information can be discussed. Avoid placing a full customer dataset in the initial enquiry; start with the information needed to route and understand the request.
Is there a guaranteed response time?
This page does not promise a fixed response time. Explain any deadline in your message and distinguish a purchasing deadline from an operational issue affecting current work. If your business requires a contractual support response commitment, raise that requirement during evaluation and obtain written agreement. Do not infer an emergency service or service-level agreement from the contact form.
What can I do while waiting for a reply?
Review the work order software guide, check the current plans, or continue a small trial workflow if you can do so safely. Record any additional findings in one concise follow-up rather than repeatedly submitting the same request. For a technical issue, preserve the relevant reference and error text so that the next exchange can focus on resolving the problem.