Scheduled Repairs Based on Area
Introduction​
To improve scheduled repair efficiency, Lincoln will be changing their repair scheduling to consider the location of the repair. Housing Repairs Online will need to incorporate this change and offer appointments within the appropriate time period for the property a repair is requested for.
Background​
Lincoln uses Kirona DRS as their scheduling system.
Currently, when customer service agents (CSAs) are scheduling a repair, they are offered appointments based on availability of the respective trade operative. The offered appointments are graded for most optimum based on multiple factors, including proximity of existing booked repairs of the trade operative required. The CSA would allocate the appointment based on the availability of the resident.
For scheduled repairs based on area, the geographic area which Lincoln is responsible for repairs will be divided into quadrants and each quadrant will be assigned a 3 week period during which repairs within the quadrant will be scheduled. Quadrant periods will be rotated every 3 weeks.
The scheduling system, DRS, will be reconfigured to support scheduled repairs based on area. Afterwich it will only provide availability for a property repair within it’s next allocated period.
DRS has a SOAP API which Housing Repairs Online will be using to interface with it. A checkAvailability request can be made to query availability of appointments for a property of type of repair (SOR). The request needs to include the start and end dates of the period to search for available appointments. The response to this request is an ordered list of all days between the specified start and end dates (see next paragraph) and the available appointment slots for each day.
The response includes days for which no appointments are available and also weekends and national holidays.
DRS is configured to provide a maximum number of days for this response and providing a start and end date which exceeds the configured maximum would only contain days between the start date and the start date + the maximum number of days configured.
The default DRS configuration is a maximum of 7 days and the maximum recommended value is 14, afterwich DRS system performance would degrade (only affects SOAP API, not web). Lincoln’s DRS system is configured for a maximum of 14 days.
So we are unable to provide a sufficiently large time span of search to cover all quadrants and expect results for the entire time span.
Given each quadrant is worked in for 3 weeks and rotated to the next quadrant and DRS availability check responses only provide availability for a maximum configured time span, a single request for querying availability may return no available appointments.
DRS Web Services Gateway doesn’t provide an API endpoint to query the next available appointment without a start and end date for the search. For our purposes, this would be a great new feature of the API and consulted OneAdvanced (publishers of DRS) about the possibility of adding it to the API. They are considering the request, however it’s unlikely that it would be available within a suitable time frame to be useful for the current project and as such isn’t an option that can be considered.
This spike is to investigate approaches to provide at least 5 days of available appointments for a repair request.
Options​
The following are possible approaches to factoring in scheduled repairs based on area:
1. Web Booking Hub, a DRS add-in​
DRS has a web based plugin called Web Booking Hub which is an additional paid product. Lincoln doesn’t currently have this product.
It integrates with DRS web UI and provides a web interface that displays a grid of available repair appointments. It would initially display the next available appointment for a repair request.
It does not have an API which could be used to query the next available appointment, which means it’s not possible to use within Housing Repairs Online.
2. Housing Repairs Online understands quadrant schedules​
Housing Repairs Online would understand when each quadrant is scheduled to be worked on and use this information to select a start date for the check availability request. This would ensure that the initial response would have available appointments (if any were available).
Housing Repairs Online having the quadrant information duplicates the information that will be configured in DRS. If the DRS scheduling changes, then Housing Repairs Online would also need to be updated to reflect the scheduling changes.
Additionally, given Housing Repairs Online will be adopted by other Local Authorities and their scheduling may not require specialised scheduling, adding complexity within Housing Repairs Online could make it more difficult to adopt.
3. Housing Repairs Online iterative querying​
Housing Repairs Online would repeatedly request available appointments, incrementing the search time span, from the scheduling system until it had the desired amount of days (currently 5) worth of appointments.
This approach would mean, given a maximum scheduling system search window of 14 days and each quadrant worked on for 3 weeks (21 days), that the quadrant to be worked in furthest in the future would need a minimum of 5 requests to be searching in the correct time span and a maximum of 6 to cover the entire duration of days repairing in that quadrant. See [table 1](#table-1).
Table 1​
| Quadrant 1 | Quadrant 2 | Quadrant 3 | Quadrant 4 | ||||||||
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 | Week 7 | Week 8 | Week 9 | Week 10 | Week 11 | Week 12 |
| Request 1 | Request 2 | Request 3 | Request 4 | Request 5 | Request 6 | ||||||
The average time taken for a single request is 1685ms.
Therefore performing all 6 requests would take an average of 10.1s.
[See Appendix A for a breakdown of timings.]
The approach of iteratively querying within an incremented search time window until sufficient days worth of available appointments were found would also solve the scenario where an initial request doesn’t retrieve desired number of days of appointments. This could occur regardless of the scheduling policy due to various factors:
- limited availability of trade operatives for specific repair
- high demand for specific repair
- national holidays (which aren’t known to the scheduling system)
Summary​
Option 1 is not viable as:
- We do not want to embed a web UI in our public facing service as it would not fit in with the UX we are trying to provide.
- We are unable to query the add-in for the next available appointment.
- There would be an additional cost for the add-in.
Option 2 has the following drawbacks:
- Duplication of scheduling by area logic.
- Housing Repairs Online system having knowledge of scheduling by area Increases complexity within a system designed to depend on a scheduling system.
- Such specific logic could make adoption more difficult for Local Authorities that do not apply the same scheduling policy.
Option 3 would have an increased overhead associated with querying appointment availability if the repair request is for an area that isn’t available for a number of weeks.
This overhead could mean a latency in returning the available repair appointments to the user which may be a source of user frustration and/or confusion during the user journey.
However, this option would allow keeping specific scheduling information within the scheduling system (DRS) and would be the equivalent of scenarios where sufficient available appointments are not found in an initial request.
To mitigate the perceived delay in displaying the available repair appointments, rather than starting the query when the user reaches the available appointment stage of the user journey, to instead begin that query once sufficient data for the query has been gathered. The results would then be available quicker than if the query only commenced when the user arrived at the appointment selection stage.
This approach would need to factor in if the user went back and changed something that would affect the available appointment requests.
Conclusion​
The recommendation is to use option 3 to iteratively query the scheduling system until sufficient days worth of available appointments are found as this will fit any scheduling system that is configured appropriately for the desired repair scheduling.
Appendix A​
Timings taken using Lincoln Citrix Workspace Teams Desktop.
All values are in milliseconds.
| Batch Number | Request Number | Average | Total | |||||
| 1 | 2 | 3 | 4 | 5 | 6 | |||
| 1 | 1016 | 1062 | 999 | 991 | 980 | 923 | 995 | 5971 |
| 1 | 980 | 945 | 921 | 2048 | 1534 | 2101 | 1421 | 8527 |
| 1 | 1483 | 1490 | 1556 | 1389 | 1983 | 1514 | 1569 | 9413 |
| 1 | 3598 | 1598 | 2707 | 1527 | 1466 | 1453 | 2058 | 12348 |
| 1 | 1550 | 1355 | 1596 | 1336 | 2852 | 1435 | 1687 | 10125 |
| 1 | 1482 | 2058 | 1461 | 1474 | 1444 | 1425 | 1557 | 9344 |
| 1 | 1451 | 2160 | 965 | 1680 | 1956 | 1473 | 1614 | 9686 |
| 1 | 1407 | 1785 | 1304 | 1528 | 1460 | 1988 | 1579 | 9472 |
| 1 | 1654 | 2084 | 1383 | 1415 | 1587 | 1634 | 1626 | 9757 |
| 1 | 2139 | 2172 | 2046 | 942 | 1354 | 1486 | 1690 | 10138 |
| 2 | 1021 | 970 | 995 | 884 | 911 | 932 | 952 | 5714 |
| 2 | 884 | 931 | 957 | 1952 | 928 | 1377 | 1171 | 7029 |
| 2 | 1525 | 1329 | 1804 | 1609 | 1465 | 1479 | 1535 | 9212 |
| 2 | 2118 | 1884 | 1461 | 1806 | 1348 | 1627 | 1707 | 10245 |
| 2 | 1602 | 1381 | 1329 | 1983 | 1500 | 2033 | 1638 | 9828 |
| 2 | 1588 | 1334 | 1471 | 2678 | 1707 | 1523 | 1717 | 10301 |
| 2 | 1847 | 1100 | 1325 | 1542 | 1764 | 1659 | 1539 | 9236 |
| 2 | 1383 | 1500 | 1874 | 1967 | 1165 | 1432 | 1554 | 9322 |
| 2 | 1473 | 2478 | 1933 | 1871 | 2909 | 2111 | 2129 | 12775 |
| 2 | 1927 | 2154 | 1873 | 1581 | 2598 | 2378 | 2085 | 12511 |
| 3 | 956 | 886 | 902 | 915 | 968 | 910 | 923 | 5537 |
| 3 | 891 | 930 | 914 | 2017 | 893 | 1883 | 1254 | 7527 |
| 3 | 1372 | 1569 | 1367 | 1555 | 1343 | 1555 | 1460 | 8761 |
| 3 | 1897 | 1231 | 2106 | 1365 | 1415 | 1368 | 1564 | 9381 |
| 3 | 1486 | 1512 | 1405 | 1901 | 1337 | 1454 | 1516 | 9095 |
| 3 | 1287 | 2015 | 1958 | 3174 | 3274 | 3106 | 2469 | 14814 |
| 3 | 1890 | 1074 | 1676 | 3708 | 3120 | 2716 | 2364 | 14184 |
| 3 | 3191 | 4236 | 3230 | 3922 | 3398 | 2675 | 3442 | 20652 |
| 3 | 2878 | 3058 | 3056 | 4835 | 3012 | 3190 | 3338 | 20030 |
| 3 | 2904 | 3081 | 3029 | 3799 | 2696 | 3157 | 3111 | 18665 |
| 4 | 3007 | 918 | 975 | 977 | 878 | 921 | 1279 | 7675 |
| 4 | 898 | 937 | 914 | 1915 | 916 | 1205 | 1131 | 6784 |
| 4 | 1465 | 1711 | 1930 | 2294 | 2079 | 1337 | 1802 | 10815 |
| 4 | 1382 | 1543 | 1440 | 2187 | 950 | 1546 | 1508 | 9048 |
| 4 | 1271 | 1565 | 1539 | 3525 | 1823 | 1603 | 1887 | 11325 |
| 4 | 1519 | 1993 | 1449 | 1940 | 1453 | 1567 | 1654 | 9921 |
| 4 | 2044 | 1345 | 1551 | 1317 | 1919 | 1234 | 1568 | 9410 |
| 4 | 1439 | 1519 | 1502 | 1469 | 1566 | 1452 | 1491 | 8947 |
| 4 | 2061 | 1927 | 1175 | 1904 | 1471 | 1635 | 1695 | 10173 |
| 4 | 1284 | 1519 | 2385 | 2229 | 2296 | 1495 | 1868 | 11208 |
| 5 | 972 | 942 | 947 | 966 | 976 | 959 | 960 | 5762 |
| 5 | 899 | 932 | 1994 | 976 | 963 | 1428 | 1199 | 7192 |
| 5 | 1884 | 1568 | 1451 | 1654 | 1310 | 2220 | 1681 | 10086 |
| 5 | 977 | 1556 | 1403 | 1552 | 1632 | 2222 | 1557 | 9342 |
| 5 | 1602 | 1745 | 2160 | 1001 | 1513 | 1538 | 1593 | 9559 |
| 5 | 1552 | 1536 | 1481 | 2061 | 1477 | 1318 | 1571 | 9425 |
| 5 | 1959 | 941 | 1362 | 1477 | 1575 | 1732 | 1508 | 9046 |
| 5 | 1706 | 1418 | 1640 | 2186 | 1563 | 2621 | 1856 | 11133 |
| 5 | 1425 | 1569 | 1532 | 1367 | 1588 | 1445 | 1488 | 8926 |
| 5 | 1956 | 1178 | 1910 | 1697 | 1502 | 2004 | 1708 | 10246 |
| Average | 1611 | 1563 | 1575 | 1845 | 1644 | 1676 | 1685 | 10112 |
| Min. | Max. | ||
| Single Request | 878 | 4835 | |
| 6 Requests | 5537 | 20652 | |
There is a large difference between the minimum and maximum time for a single request and also 6 requests.
Each batch consists of performing 6 requests 10 times in quick succession. The close proximity of requests could be the reason for the large difference between minimum and maximum duration of requests.