Armakuni Contact us
← All case studies

The technician finished the job by lunchtime.
The office had the report days later.

A U.S. field-service platform for audio-visual and IT service companies was running on paper forms that someone retyped back at the office, on containers that stopped mid-shift, and on dispatch emails that could fail without anyone finding out. We took field reporting off paper and connected it to the tools customers already use. The platform moved onto ECS with health checks and automatic recovery, every bounced email now shows up, and each tenant's data is secured. What began as one company's internal tool is now a SaaS product used by more than 20 organizations.

Before

Paper in the van, typing at the office.

A healthy app that still lost messages.

After
60–80%less time on task management
80%fewer communication errors
99.9%availability at production load

As the company reported.

Paper in the van, typing at the office

The platform helps AV and IT service companies dispatch technicians, track jobs and close out work. Technicians filled in paper forms on site and brought them back, and administrators retyped them, costing hours a shift and creating duplicates. Administrators chased status updates and handled customer messages across disconnected tools, and any routine configuration change, such as a new crew, a job template or a CRM connection, needed an engineer.

A healthy app that still lost messages

As the platform took on more organizations, production problems grew with it. Containers stopped without warning or recovery, often during customers' busiest hours. There was no proactive monitoring, so the first sign of trouble was a customer's call. Dispatch ran over email with no delivery feedback, and a bounced message looked exactly like a sent one, so a missed job only surfaced later as an escalation.

Make the platform catch its own failures

The fix meant taking paper and engineering work out of day-to-day operations, then getting the platform to notice and recover from failures before a customer does, including the failures that quietly look like success.

How we built it

4 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Field reports that close on site
  2. The platform now flags a bounced email that used to go unnoticed
  3. Containers that restart themselves
  4. Each tenant's data, protected and separate

Field reports that close on site

Built withGoogle WorkspaceSalesforceZapier
The technician files it on siteThe office sees it at onceScheduling and CRM updated
The engineering
  • Technicians submit field reports digitally, so administrators see active and completed jobs as they happen.
  • Integrations with Google Workspace, Salesforce and Zapier connect scheduling, customer records and the tasks that follow, so a new customer's existing calendar and CRM work from day one.
  • Point-and-click administration lets operations staff handle routine configuration and onboarding without an engineer.

The platform now flags a bounced email that used to go unnoticed

Built withSNSSQSLambda
Emails sentDeliveredA bounce Operations flagged, no longer unnoticed
The engineering

Email bounce and complaint events now flow through SNS, SQS and Lambda, so dispatch and notification failures that once went unnoticed reach operations as they happen.

Uptime monitoring would have shown the platform healthy while dispatch emails bounced, since it never sees whether a message arrived. Delivery feedback does.

Containers that restart themselves

Built withECSRoute 53CloudWatch
Route 53 health checksCloudWatch dashboardsA stopped container replaced
The engineering

The application moved onto ECS with health checks and automated container recovery, so a stopped container gets replaced without anyone stepping in. Route 53 health checks and CloudWatch dashboards show service availability and failures on every critical path, so recovery happens before an engineer needs to.

Each tenant's data, protected and separate

Built withRDSIAM
One platform CompanyCompanyCompany each tenant's data kept apart
The engineering

Every enterprise legal review raised the same data-protection objection. The answer is now in the architecture: RDS with encryption at rest and in transit, fine-grained IAM access control and ACM-managed certificates protect the multi-tenant application's data and connections. AWS Certificate Manager provisions, renews and rotates the TLS certificates, so an expired certificate can't fail in front of a customer.

One job, end to end

  1. A dispatcher assigns a job, and a confirmation email goes to the customer.
  2. The email bounces, and SNS, SQS and Lambda report it right away, so the dispatcher calls the customer before the customer has to call in.
  3. The technician does the work and files the report on site, with no paper.
  4. The administrator sees the job close in real time, and it syncs to the customer's records in Salesforce.
  5. A container hits a fault at midday, and ECS replaces it while the health check confirms service is back.
  6. By the time either failure could have reached the customer, the system had recovered, and they never knew.

What we'd tell another CTO

1We took out the retyping first, because paper re-entered at the office is where the errors came from. Then we added delivery monitoring alongside uptime monitoring, since a bounced email looks like success until something is listening for it.
2The platform restarts its own containers, which frees people to investigate failures instead of replacing containers by hand. Operations can configure it without engineers, which is what let onboarding scale past one company. Each tenant's data needed securing before the product could sell into enterprises, because the legal review asks for it first.

What else changed

As the company reported.

  • Dispatch and notification failures visible as they happen.
  • Encrypted, access-controlled tenant data, answering enterprise data-protection reviews.
  • The platform grew from one company's internal tool into a SaaS product used by more than 20 organizations.

What comes next

More organizations came onto the same multi-tenant platform, under the same reliability and security model, and onboarding automation now gets a new customer live in days. Next is deeper integration with the other tools field-service companies already use, and AI agents inside the platform that route jobs predictively, write the report after each visit and watch the operational data for anomalies.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

The platform's own roadmap points at AI agents for job routing and post-visit reports. On AK AI Factory, an AI agent could draft a field report from a technician's voice note and route the follow-ups, with its own identity, only the tools its job needs, and a golden set of real past jobs that every change must pass before it goes live. Underneath, AK Run would run the whole platform as one team. That means production, the ECS services and the delivery feedback on every email; the application, with each bug fixed in the code, with a test, through the company's own pipeline; security, with the per-tenant encryption, IAM and certificates kept current; and, once the routing and reporting AI agents exist, the AI agents themselves, each on one register, with every model call through Agent ControlPlane and every step on a trace. Its AI agents take the first look at every alert and draft the fix, and a named engineer confirms the cause.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop