The Answer Service
Answers in seconds, without interrupting the one person who knows
“The questions didn't change. What changed was that nobody had to stop work to answer them.”
What wasn't working
Sales needed to know the same things every day: is this component in stock, where is it, what's the lead time, and where's that order at. The answers lived in the MRP system and in Jira, but sales didn't have seats for either, and buying licences for occasional lookups made no sense.
So every question went to a person. That person was busy with their own work, so answers usually took four to six hours. Sometimes a customer was waiting on the other end of a call.
The hidden cost was worse. Because asking was slow and awkward, people stopped asking. They guessed, or told the customer they'd get back to them.
For a contractor, this is the owner or ops manager who gets the same calls all day: have we got the parts, when will they arrive, where's that job at. Everyone else waits on them, and they can't get their own work done.
How we tackled it
We built an assistant that lived in Slack, where the team already worked, so there was nothing new to learn. You asked it a question in plain English, and it looked up the answer in the systems the business already used: Pipedrive for the customer and deal, the MRP for stock, locations and lead times, and Jira for open work orders.
The model didn't make up answers. It worked out what was being asked, fetched the real data, and put it into a plain reply. If the data wasn't there, it said so.
What changed
One place to ask
Stock, location, lead time and order status, all from a single message in Slack, without logging into anything.
Speaking the customer's language
Sales talked about products the way customers did. The system used internal component codes. The assistant translated between the two, so nobody had to know the codes.
Answers you can check
Every answer came from live data and was flagged as an estimate where it should be. Every question and answer was logged and checked weekly against the people who used to answer them, so mistakes were caught early.
From asking to doing
Once it had earned trust, it went beyond answering. It could draft a new order from the conversation, show the person exactly what it was about to create, and only create it once they confirmed.
Built so it couldn't go rogue
It started read-only and only gained the ability to create orders later. It could only reach the data each task needed. Every answer came from live data, not the AI's imagination. And every order it created was reviewed, daily at first, then weekly once it had proved itself.
The difference
| Before | After | |
|---|---|---|
| Getting an answer | Ask a person, wait 4–6 hours | Ask in Slack, answer in seconds |
| Who gets interrupted | The specialist, all day | Nobody |
| Software licences | A seat for everyone who might ask | No extra seats |
| How often people asked | Rarely, because it was a hassle | About 4x more, because it was easy |
| Creating orders | Hand off to someone with access | Drafted in the conversation, confirmed by a person, reviewed after |
Why it matters
The biggest result wasn't speed. It was that people asked four times as often. Those questions had always existed. Before, they went unasked and got answered with a guess.
For a contractor, the same setup connects to the job system, stock and suppliers the firm already uses. An estimator on a call with a main contractor, or an engineer on site, can ask "have we got it, when's it due, where's the job at" and get a straight answer, without ringing the office. The owner stops being the answer service, and the office gets its day back.
Want the same for how your jobs run?
No pitch, no prep. Describe how jobs run now and I'll help you pinpoint the bottlenecks.