A service business quotes a customer for maintenance at three sites. Two visits go ahead. During the second visit the technician finds an additional fault and receives verbal approval to repair it. The third visit is postponed. At month end, the director sees a job marked complete, a supplier invoice for parts and a customer invoice covering the original quote. Nobody can say whether the extra work was authorised, billed or collected.
Custom business management software in Kenya can give that director a traceable answer. The useful starting point is the job itself. What did the customer ask for? What did the company agree to deliver? Who approved changes? Which work was actually completed? What has finance billed and received? A dependable system preserves these distinctions even when a job looks simple on the calendar.
This guide follows a fictional field service company. The same method works for firms that deliver installations, repairs, inspections or recurring services. Use your own approved commercial terms and operating procedures in the buying exercise. The purpose is to test whether a proposal follows the work past booking and into the decisions that determine revenue, cost and customer trust.
Decide what one job represents
A customer contract may cover several sites, visits and service types. A quotation may cover an initial job while later changes add work. A technician may complete several visits before finance issues one invoice. If your system treats contract, job, visit and invoice as interchangeable, it will work for the first straightforward transaction and become confusing as soon as a customer changes their plans.
Define each record in the language your team uses. A contract or accepted quote identifies the agreed scope. A job authorises a piece of work. A visit schedules people at a place and time. A completion record describes what happened. A charge records what the business may bill under its approved agreement. A payment records money confirmed through an authorised process. Each record should link to the others without overwriting them.
Give the example three visits. The first is routine inspection at site A. The second is a repair at site B. The third is a visit to site C that the customer postpones. The job remains open for the third visit, even though the first two are complete. Finance may be able to bill some completed work before the job closes, depending on the agreement. Agree the rule before asking a developer to automate it.
Make the identifiers readable where people use them. A technician talking to dispatch may need a short visit reference. Finance may need the job and customer purchase reference. Customers may recognise their site name more readily than an internal code. Display the appropriate references together without using a customer name as the unique identifier. Two sites belonging to one customer should not become one ambiguous work location.
Write the quote so the future job can use it
A quote is an operational instruction as well as a price. It should identify the customer, service location, scope, exclusions, pricing basis and any assumptions required for delivery. A note that says repair equipment may be enough for a conversation but too vague to design a job workflow. Ask the service manager what information a dispatcher and technician need once the customer accepts the offer.
Create a quotation with a fixed visit fee and a separate line for approved additional parts. The example need not include real market prices. Pick clearly illustrative amounts so finance can verify how the system handles changes. Record whether the customer accepted the full scope, a particular version or only selected lines. Starting the job from an earlier quote version can send technicians out with obsolete instructions.
Test an amendment before work begins. The customer removes a site or changes the contact person. The new quote version should show what changed and whether it needs renewed acceptance under your policy. Preserve the original version because the company may already have ordered parts or reserved staff time. A clear difference between proposed and accepted content prevents sales drafts from silently rewriting an active job.
Ask what happens when two people accept different versions. A sales officer records verbal agreement while a later written instruction narrows the scope. The organisation needs a defined authority and resolution path. Software can expose the competing records and pause the affected work. It cannot decide which commercial instruction is authoritative unless the business has supplied the rule and evidence needed to make that decision.
Give dispatch enough information to make a promise
Scheduling is more than putting a name in a calendar. The dispatcher needs to know the site, requested time window, eligible technicians, required equipment, estimated duration and prerequisites. A customer access pass, part delivery or site contact may determine whether the visit can begin. If those prerequisites live in separate messages, the calendar can show a full day of appointments that nobody can perform.
Use two technicians with different competencies and one shared testing device. Give the system two visits overlapping in time. Can dispatch see the conflict before promising both customers the same device? Some constraints may be strict, while others may be warnings that an authorised dispatcher can resolve. Record the reason for an override when it changes a commitment someone else depends on.
Plan journey time and handoffs realistically. A technician already working at another site may finish later than expected. The application should let the dispatcher update arrival estimates, notify the appropriate customer contact under the agreed process and preserve the original appointment. An overwritten calendar entry hides how often the business changes promises and why particular routes are consistently difficult to complete.
Test postponement separately from cancellation. The customer still wants site C serviced but cannot grant access this week. The visit should have an owner for rescheduling and a reason. It should not vanish from the job, count as completed work or immediately trigger a refund under an unrelated rule. A postponed visit needs a visible queue that dispatch reviews before the customer has to telephone again.
Let technicians record the event once
At site A, the technician needs a clear description of the work, relevant site details and a way to record completion. Give them a phone representative of the devices your business uses. Observe the steps needed to open the correct visit, record the outcome and attach approved evidence. A field form designed for a large desktop monitor may encourage staff to leave everything until the end of the day.
Define what completion means. Arrival, work started, task finished, customer acknowledgement and supervisor review may be separate events. A technician can finish the agreed task while the customer’s authorised representative is unavailable to acknowledge it. The job should retain both facts and assign the follow up to someone. A compulsory signature field that staff fill with a placeholder destroys the value of collecting signatures.
Make evidence proportionate. A serial number or service reading may be necessary for a specific task. A photograph may help explain damage but can also capture unnecessary details of a customer’s premises. Decide what each service type needs and who can view it. Give the technician a simple way to classify an attachment and identify the visit it supports rather than uploading everything into one job folder.
Disconnect the phone at the point of submission. If the application supports offline capture, ask what remains on the device, how staff recognise pending work and how repeated submissions are handled after reconnection. If it requires an online connection, document the approved temporary process. A blank error message can lead a technician to enter the same completed visit three times while standing at the customer’s gate.
Make extra work visible before it becomes an invoice dispute
At site B the technician discovers an additional fault. The customer contact says to go ahead, but the company’s agreement may require approval from a different person or a written reference. Define which changes can be accepted onsite, by whom and within what scope. The software should help the technician distinguish recording a finding, proposing an additional task and receiving authority to perform it.
Create a variation with the original job reference, description, cost or price basis, customer approval evidence and effect on schedule. Keep it visibly separate from the original scope. A manager reviewing margin later should be able to see whether extra cost rose because the estimate was wrong or because the customer bought additional work. Combining both in one revised quote erases that distinction.
Try two outcomes. In the first, the authorised customer representative approves the variation and the technician completes it. The variation can become eligible for billing under the agreed rule. In the second, the customer declines. The finding remains in the service history, but no unauthorised charge appears. Ask finance to locate each outcome without calling the technician to interpret a free text note.
Handle urgent exceptions according to your business policy. The technician may need to pause work, secure the location under the company’s procedures or contact a supervisor. Build an escalation route that gives the supervisor the relevant facts without assuming the software itself can approve every unusual situation. The system’s job is to preserve the decision and make the resulting work, cost and communication traceable.
Follow parts through issue, use and return
A technician collects three parts from stores and uses two. The third remains in the service vehicle. At the end of the visit, inventory, job costing and finance each need a different answer. Stores needs physical custody. The job owner needs actual consumption. Finance needs the amount billable under the contract. Recording three parts issued as three parts consumed and billed can inflate both cost and customer charges.
Test an issue from central stores to a vehicle or technician custody location. Then record the two parts used against the specific visit and return or carry forward the remaining part under the approved policy. Compare the physical movement and job cost. A useful system can explain where the unused part is without requiring an invented sale or negative issue to make the ledger balance.
Add a part purchased directly for the job. Purchasing needs the supplier reference, receipt and cost. The technician needs to know whether the part is physically available. Finance needs to establish whether its price is included in the quoted fee or chargeable separately. Link the purchase to the job without treating a supplier invoice as proof that the customer approved an additional charge.
Review a customer owned part. The business may handle it without owning its value. Give the technician a way to record custody and outcome under the company’s procedures. Make sure finance does not add it to purchased inventory or bill it as company stock simply because it appeared on the service record. This edge case is a good test of whether developers understand your actual operating model.
Count time in a way supervisors can review
Time records can support scheduling, job cost, payroll input or customer billing. Those are different purposes. A technician may spend travel time, billable service time and nonbillable rework on one visit. Define which categories your company needs and which approved rules determine their effect. Do not assume that every hour recorded on a job becomes a billable hour or a payroll adjustment.
Give the technician a day split between two sites and a period of waiting for access. Ask them to record start and finish times using the normal device. A supervisor should be able to verify the entries against the visit schedule and explain an overlap. If the system automatically estimates time from calendar bookings, keep estimated and actual values distinct. A postponed visit should not contribute actual labour cost.
Test late entry after the job has been billed. The company might need a cost adjustment while the customer invoice stays unchanged. Or an approved extra charge may be required under the contract. The correct treatment comes from your policy and agreement. The system should direct the late entry to the responsible reviewer and preserve the relationship to the original visit and financial period.
Keep reporting fair and understandable. A technician working a difficult route may record more travel time than a colleague assigned nearby sites. A dashboard ranking employees by billable hours alone can create misleading comparisons. Add context appropriate to the decision and let supervisors inspect the underlying visits. Good information should help the business understand where time goes before it becomes a basis for evaluating individuals.
Separate completion from readiness to invoice
A completed visit may still need customer acknowledgement, review of the variation or a purchase reference before billing. A postponed visit may not block an invoice for the two completed visits if the agreement allows separate billing. Design a list of invoice eligible items with the reason for eligibility. Finance should see the source visit, approved quantity, rate or agreed fee and outstanding exceptions.
Run a draft invoice in the trial. Include site A inspection, the accepted site B work and its approved variation. Exclude site C because it has not occurred under the example agreement. Compare the draft to the accepted quote and variation. Finance should be able to challenge any unexpected line without changing field evidence. The technician’s completion record and the accountant’s decision to invoice need separate histories.
Create the invoice twice through a repeated action. Only the intended billable items should be charged once under the agreed design. A later invoice for site C must remain possible when that visit eventually happens. Give every billed item a reference to its invoice and an understandable state if invoicing fails partway. A green job status does not prove that a financial document was created successfully.
Follow the customer’s payment as a separate event. A confirmed receipt may settle several invoices or only part of one. Finance needs to identify what was received, what was allocated and which amount remains due. A service manager may need an appropriate summary without seeing bank details. Keep collection work visible after service completion while protecting financial information from staff who do not need it.
Calculate margin from the job you actually delivered
The original quote contains an estimate. The actual job contains approved scope, variations, consumed parts, labour and other agreed costs. Compare the estimate with actual outcomes at a level management can explain. A job may appear unprofitable because an approved variation was never billed, because parts were issued but not consumed, or because a route took longer than planned. Those causes need different action.
Prepare a fictional calculation with your finance lead. Give the two completed visits an agreed revenue amount, add the approved variation, subtract the two consumed parts and include labour using your chosen costing method. Keep cash collected separate from revenue recognised under the company’s accounting arrangements. Ask the supplier to reproduce the simple example and trace each input back to an approved transaction.
Decide when provisional cost becomes final. A supplier invoice may arrive after the technician completes a visit. An estimated part cost may need replacement with an approved actual cost. Do not let the margin report change silently without an explanation. A manager reviewing the job last week and today should be able to identify the event that caused the difference and the date each view represents.
Avoid allocating every overhead automatically merely because the software allows it. Finance should decide which cost measures are useful for which decisions. A direct contribution view can help dispatch understand route economics, while a fully allocated view may serve another purpose. Label them distinctly and document the treatment. Two managers can use different valid measures if they know which question each measure answers.
Choose configuration, integration or custom development
An existing service management package may already handle quotes, visits and invoices. Custom work makes sense where the operational distinction matters enough to justify its ongoing cost. Identify the requirements that genuinely differentiate your business, such as site specific authorisation, complex variation rules or technician custody of parts. Compare a standard configuration, a small integration and purpose built development against the same fictional job.
Ask how administrators will maintain the result. A new service type, approval threshold or branch may be a routine business change. If every adjustment requires a developer, ongoing cost and delay can outweigh a convenient initial fit. Conversely, unrestricted configuration can let a supervisor alter billing rules without review. Give authorised users appropriate controls and preserve the history of consequential settings.
Request a proposal with clear boundaries. Identify the existing accounting system, any inventory application, field devices and communication channels involved. Determine which integrations already exist, which need development and which depend on third party approval. A promise to connect to accounting is incomplete until you know what data crosses the boundary, what happens when it fails and who reconciles the result.
Test an exit path for the custom system. Export a job with its quote versions, visits, evidence references, parts movements, invoices and payment allocations. Ask an authorised colleague to interpret the file without using the supplier’s interface. Clarify rights to the application, data, documentation and operating materials under the proposed contract. The business should be able to continue its records and work if its development arrangements change.
Keep recurring work separate from a completed job
A customer may sign an annual service agreement that creates several visits over time. Treat the agreement, planned occurrences and actual jobs as separate records. A recurring rule can generate appointments, but each appointment still needs its own location, access arrangements, technician and completion evidence. If cancelling one visit cancels the entire agreement, an ordinary postponement can accidentally remove months of future work from the calendar.
Test the next occurrence when site C is postponed. The regular schedule may still require a visit next month. Should the missed visit be rescheduled separately, merged with the next visit under an approved decision or closed with a reason? The answer depends on the agreement and the service. Give the dispatcher a clear way to see both commitments before changing them. A calendar with two similar entries should not force the dispatcher to guess whether one is a duplicate.
Change the agreed service frequency partway through the contract. Future visits should reflect the approved new frequency, while completed jobs and invoices remain explainable under the original arrangement. Ask what happens to previously generated but unconfirmed visits. The service manager needs a review list before the software cancels or creates dozens of appointments. A preview with dates, sites and affected customers makes the change much easier to authorise.
Approach renewal with evidence. The account manager should see completed visits, postponements, variations, customer complaints and unpaid amounts relevant to the discussion. Restrict sensitive details to the roles that need them. A renewal reminder alone tells sales when to call, while the service history tells them what conversation to have. Ask the vendor to show the account view for a customer with one troubled site and two sites that ran smoothly.
Handle a complaint after the original work closes
A customer calls about the repair at site B two weeks after payment. The original job is commercially complete, yet the new complaint needs attention. Create a linked service case that preserves the original completion, variation and invoice. Do not silently reopen the old job for billing or erase the technician’s earlier evidence. The service manager needs a new investigation with its own owner and decision.
Define how the business distinguishes a callback, warranty inspection, new fault and goodwill visit. A technician may identify the issue, but an authorised manager may need to decide financial treatment. The software should support pending classification until the facts are known. Requiring the dispatcher to decide immediately whether a visit is free or chargeable encourages guesswork before anyone has inspected the problem.
Test two outcomes. The manager confirms that the callback relates to the previous work and approves an internal cost. In another case, the customer authorises a separate repair unrelated to the earlier visit. Both outcomes add useful service history, but only the second creates a new billable instruction under the example. Trace the labour, parts and customer communication in each case. The original paid invoice should retain its history.
Review complaint patterns by service type and cause rather than simply counting callbacks against individual technicians. A cluster may point to a parts issue, an unclear quote or a scheduling constraint that shortened visits. Give managers access to the relevant evidence without distributing private notes unnecessarily. If a correction changes a standard procedure, update the service checklist and test the next ordinary job to see whether the change reaches field staff.
Set acceptance terms that finish the project
Break a development proposal into outcomes the business can witness. One milestone might cover accepted quote to scheduled visit. Another might cover field completion and approved variations. A later milestone might cover invoicing, payment allocation and margin reconciliation. Tie each milestone to fictional records and expected results. A milestone called field module complete can be hard to evaluate when the technician’s screen works but its output never reaches finance.
Distinguish defects from changes in scope using the agreed scenarios. If the system invoices the postponed third visit despite the agreed rule, the behaviour fails an existing example. If management later asks for a different commercial model, the new rule may require a priced change. Preserve the original decision and document the new example. This gives the buyer and developer a fair way to handle legitimate changes without reopening every earlier discussion.
Ask for operating materials as the system is delivered. These may include administrator procedures, user role definitions, integration references, backup arrangements, release instructions and the agreed test jobs. Give a new supervisor the materials and see whether they can add a service type, identify an unbilled variation and direct a failed accounting export to its owner. Documentation earns its place when somebody can actually use it to keep the business running.
Plan the first improvement meeting after launch around evidence. Bring one completed job that flowed well and one that became stuck. Identify the exact handoff that caused delay and the person who ultimately resolved it. A small change to a label, approval rule or exception queue may deliver more value than a new dashboard. Keep the three visit demonstration available as a regression check whenever a later improvement changes scheduling, parts or billing behaviour.
Budget for the company’s own work during implementation. Supervisors must define service codes, clean customer sites, confirm prices and decide who may approve variations. Technicians need time to practise with the devices they use on the road. Finance must compare sample invoices and collections with its approved process. Recording those responsibilities in the project schedule makes supplier offers easier to compare and reduces the chance that a technical delivery finishes before anyone is ready to operate it.
Take the three visits into a pilot
Select one dispatcher, one technician, a service manager and a finance reviewer. Give each the relevant part of the same fictional job. Have them complete site A, handle the variation at site B and postpone site C. Measure whether they can identify their next action and explain the customer’s current position without a project consultant translating the screen. Record where an action requires a policy decision or missing data.
Then change the sequence. The customer pays a deposit before the first visit. A part arrives late. A supervisor is absent during variation approval. Ask the team to follow the same records through those events. A pilot that survives ordinary disruption gives stronger evidence than a demonstration in which every task occurs exactly as scheduled. Keep unresolved exceptions visible and assign them to the responsible role.
Give the project owner one final exercise before accepting the pilot. Choose a job where the technician used two parts but the customer approved only one as a separate charge. Ask stores to explain physical custody, finance to explain the invoice and the service manager to explain the margin. Those answers should differ for understandable reasons. If every screen shows two billable parts merely because two were consumed, the project still confuses internal cost with customer authority. Keep that example in training for anyone who creates a new service or changes a pricing rule after the launch.
The acceptance question is concrete. At month end, can the director see what was authorised, what was delivered, what remains scheduled, what was billed and what was collected? A strong proposal lets each answer lead to its supporting record. Explore more Kenyan guides to practical software decisions on the ZamaCore blog.