Platform APIs weeknotes, 5 August 2020

OK so it wasn’t me; this past week has also felt slow, and that has been highlighted by the team in our retro yesterday. We’ve had quite a few of the team off over the last week; not a bad thing in itself, as people need a break. But coupled with underestimating the size of some of the tasks, it meant that we didn’t do as much as we had planned for.

That said, we have achieved Something Big. Ben has completed the LIST endpoint for the Resident Information Platform API – the beast we’ve been working towards these last few months. And what a beast it was; it took him nearly three weeks, though a lot of that was revisions following reviews from team members. Given that this knits together the other APIs we’ve built, we’ve agreed that future top-level API build tasks need to be broken down a lot more!

The Giant Behemoth - Wikipedia
Not quite our API, but it’s almost as big

So what does this behemoth do? In short, it sends queries to the other lower-level APIs and collates their responses, with a tag showing which system returned which response. The tag can be made clickable in a web front-end, so the user is able to easily navigate to that record in the original API that returned it. There are still a couple of things to be done so that it’s usable and we expect these to be completed in the new sprint. 

The LIST and VIEW endpoints for the Contact Details API have also been completed. This will enable us to pull out records from our Contact Centre database; as I mentioned last week, these are sometimes different to what’s in the main Housing database. Humairaa led on this work, and has commented on how much more confident she is now in this field. Given how keen we were to make sure this project was a learning experience, I’m really pleased to hear that. 

Work on the Authoriser app has moved on. There is now an API that generates authorisation tokens for services, and these can be granular to the point that access to particular fields can be specified. The tokens are stored in a database and can be revoked instantly, if required. This is something that we’ve wanted to do for a while, so it’s good to see it finally happening, and it’ll be part of the refreshed API Hub. 

Speaking of which, we reviewed our Roadmap this week and we plan to start the API Hub work this month. The Roadmap does still need a little work for the “Later” column but we have a clear direction for the immediate future. We’re further ahead than we originally thought we would be at this point, and that’s a testament to the team and their hard work. Maybe the last couple of weeks have just been a blip. Maybe we’re just being hard on ourselves. 

Watch our most recent Show & Tell on YouTube.

Platform APIs weeknotes, 29 July 2020

It feels like it’s been a slightly quieter week; maybe my return has sufficiently unsettled the team 😁 That said, some really interesting work has been done. 

Work has started on the Contact Details API. This is being done from scratch, though based on what we learned during the discovery about the NCC CRM. CRM is the system used by our Contact Centre, and contains a set of email addresses and phone numbers for our residents. These are sometimes different from what’s in the main housing database, so it’s important to have them. The API and database have been designed by Bukky, Emma, and Humairaa, and work on the API endpoints is now under way.

We’ve continued to do integration work with Single View. The Search and Fetch functions now use our Academy API rather than connecting directly to the Academy database; a period of parallel running proved successful. This means that when a Single View user searches for a resident, the information they see retrieved from Academy is via the new API and mirror database. 

There’s been a reasonable amount of optimisation done as well. Mirela has investigated how to manage indexes in the databases; this will make lookups faster, but where they have been applied so far it’s been a manual process. She has also looked at whether we need to add more alerting to DMS following an unexpected fatal error – which we experienced last week. We’ve agreed that this is an unnecessary step as it’s a bit of an edge case. 

We’ve carried over quite a bit of work into the new sprint, mostly relating to the Authorisation API I mentioned last week (watch the last Show & Tell for more details). This isn’t a huge issue really; it can and will happen that a team won’t complete all of the work planned. We also have quite a few people off during the new sprint and we think this will be a good amount of work to complete. Check back next week to see if I’m right. 

Amazon Connect weeknotes, w/e 24 July 2020

This may be the last weeknotes for this project as we’ve taken the decision to pause the pilot for now and reflect on what we’ve learned. Agents have switched back to the Puzzel system and we’ll discuss next steps. 

The stats for the last 10 days of the trial are: 

  • 3168 calls were offered (that is, received by the system)
  • 860 calls were partially deflected (that is, the caller used the bot but still spoke to an agent)
  • 246 calls were fully deflected (that is, the caller only used the bot or payment line)
  • 487 callers used the balance option
  • 62 callers used the transactions option
  • 304 callers passed identification & verification 

This is a deflection rate of 34.9%, or 17.3% if you strip out callers who went straight to the payment line; this is broadly on par with the previous weeknotes. The identification & verification pass rate is 55.4%, an improvement on previous. 

Overall for the pilot, the headlines are:

  • 12,737 calls were offered
  • 2231 calls were partially deflected
  • 496 calls were fully deflected
  • This is a deflection rate of 21.4% overall

A few little things of interest: 

  • The balance option was consistently more popular than transactions
  • Leasehold callers were more likely to pass identification & verification, at least in the early days
  • A lot of callers just prefer to speak to a real person, even where an automated service exists that could handle the entire transaction
  • Automated services are a little like Marmite: where callers had a good experience they loved it, but if their experience was poor they really didn’t like it at all

I’d like to thank everyone who was involved in the pilot, especially the managers and agents in the Neighbourhoods Contact Centre for their valuable time, knowledge, and patience. We really couldn’t have done this without you, and what we’ve learned over these last few months will really help in designing the future service. 

Platform API weeknotes, 23 July 2020

While I’ve been enjoying myself in Germany (a COVID-compliant experience worth of its own post) the team has been busy. 

I’ve been spending the morning catching up with what’s been going on, and really the best way of doing this would be to watch the most recent show & tell on our YouTube channel. 

But if you prefer to read, here’s a quick recap:

  • The Tenancy Information API is almost finished – the last part is the VIEW endpoint, which will be completed this sprint. This did require some tweaking to how tenancy references are handled by the API but that work has paid off. We should be able to put this into production quickly. 
  • The Cautionary Alerts API is done!
  • All existing APIs have been tested and deployed to production. We’ve added additional indexes to the databases, improving response time from 30+ seconds to 1-2 seconds.
  • We’re working with the Security team on a mini-project to obfuscate data. Our test databases use real data, which is less than ideal, so we are using a tool within AWS to (consistently) modify data as it’s migrated from the production database to the staging database. 

All that would be good for most teams. But not this team!

  • The first version of the LIST endpoint of the high-level Resident Information Platform API has been done. This returns data from the Mosaic, Universal Housing, and Academy APIs – three of the biggest data sources in the council. It can be queried by first name, last name, or address. We will of course update it as we complete more APIs. 
  • We’ve done a simple integration with Single View! That service is now using the Academy Platform API to retrieve resident information, and we hope to add the Housing Platform API soon. 
  • We’ve had interest from three other significant projects in reusing our work, which should speed up their development – which is an intended benefit of all this work.

Lastly, we’ve been working on the authorisation model for how services can use these APIs. 

We are working on an Authorisation API to handle requests, based on the above output from a workshop. Rather than using API keys as now, users will receive a service-based token without an expiry data, and the service (rather than a user) will be authorised to use the API. But Mirela explains it much better in our last show & tell. Do watch it. 

Amazon Connect weeknotes, w/e 10 July 2020

Early weeknotes this week, as I’m going to be off for a couple of weeks. My fab colleague Philippa will be looking after this project while I’m away, but I can’t guarantee she’ll be writing any weeknotes. 

As of this morning (Wednesday 8 July) our stats since the last weeknotes are:

  • 1669 calls were offered (that is, received by the system)
  • 432 calls were partially deflected (that is, the caller used the bot but still spoke to an agent)
  • 107 calls were fully deflected (that is, the caller only used the bot or payment line)
  • 250 callers used the balance option
  • 43 callers used the transactions option
  • But only 138 callers passed identification & verification 

This is a deflection rate of 32.3%, or 17.5% if you strip out callers who went straight to the payment line. The identification & verification pass rate is 47%.

There are a couple of factors in the increases here. Last Friday the council sent text messages to tenants advertising the automated service, and setting out how to use it – and this saw a significant increase in calls to the balance service on the rent line. However, we are still concerned about the number of people who are failing at the postcode part of the verification process. We’re thinking about how to improve this, but the first change will be to simply slow down the message very slightly to make it clearer.

We’ve also had some very useful data from the reason capture we started a few weeks ago. The single most common reason mapped is “pay my rent”; this is not the language we use for the payment line so we will change it soon to see if it makes a difference. 

The service assessment was last Friday. Normally a service assessment would only be done on a web-based service, but we wanted an independent assurance on the project, its approach, and its progress at this point in the proof of concept. It’s more of a conversation with feedback and suggestions than a test. We’ll have a full review when I return from leave, but there’s already some great feedback and improvements that we can try, should we roll out.