The queue isn’t blocked by difficulty. It’s blocked by a capacity gap — one a dedicated team closes.
The items sitting in it are ordinary: catalogue items, approval changes, a report finance has asked for twice, an integration scoped last year. What they need is uninterrupted time, and the people who could give it are the same people handling incidents — where the SLA is, and where the attention goes. Softenger provides development capacity structurally separate from the support queue, so a sprint isn’t raided when a P1 arrives. Work ships on a cadence, and everything built is documented and assessed against the next release rather than becoming a problem at upgrade.
Delivery cycles with defined scope per sprint
Development work delivered through a governed update set pipeline
Certified delivery process
The platform runs. The roadmap doesn’t.
Development competes with incidents, and loses
The same engineers handle both, and incidents have SLAs while enhancements have a spreadsheet. Six months in, the business has stopped asking.
The business builds around the platform
A team waits two quarters for a catalogue item, then builds the process in a spreadsheet with an email approval. You bought ServiceNow to remove exactly that, and it’s growing back.
What did get built has no documentation
Someone delivered the integration, and it works. Nobody knows what it assumes, what it touches, or what happens to it at the next release — so it’s a risk on the register rather than an asset.
Every request becomes a customisation
Requirements are taken at face value and built as scripted logic when configuration, or a small process change, would have served. The instance accumulates code and the upgrade path narrows.
The contractor left with the context
A freelancer or agency built something specific and moved on. The knowledge went with them, and the next change to it costs more than the original build.
We ask what the process needs before we ask what to build.
A development request arrives as a solution: “we need a catalogue item that does X.” Often that’s right. Sometimes the underlying need is met by a module already licensed, a flow already available natively, or a change to the process rather than to the platform. We check that first, because the cheapest enhancement is the one you don’t have to maintain.
When something genuinely needs building, we build it configuration-first. Flow Designer before scripted business rules, native functionality before custom code, and where custom code is unavoidable it’s documented, added to the customisation register, and assessed against the next release. That last part is the difference between an asset and a liability — every undocumented script on an instance is a reason the next upgrade is harder.
Development capacity is held separately from support. On a combined engagement, the sprint doesn’t get raided when a P1 arrives. That’s a structural decision rather than an intention, and it’s the reason the roadmap actually moves.
Five kinds of build, one register underneath.
Workflows & Service Catalogue
- Catalogue items, record producers, variable sets and order guides
- Flow Designer workflows, subflows and actions
- Approval logic, including dynamic and multi-stage approvals
- Notification design and template management
- SLA definitions, schedules and escalation rules
- Assignment logic, routing rules and dynamic group assignment
- Service Portal widget configuration and catalogue presentation
the catalogue backlog. Most instances have a list of forms and requests the business asked for and never received.
Integrations
- IntegrationHub spokes and custom actions
- REST and SOAP integrations, inbound and outbound
- MID Server configuration, health and troubleshooting
- Import sets, transform maps and scheduled data loads
- Event and alert ingestion from monitoring platforms
- Identity integration: SSO, SAML, LDAP and directory synchronisation
- Integration documentation and endpoint registers — what connects, how, and what breaks if it stops
the documentation. An undocumented integration is a production dependency nobody can safely change.
Scoped Applications
- Custom applications on App Engine where no native module fits
- Data model design, table structure and relationships
- Application-scoped security: ACLs, roles and record-level access
- UI Builder and Service Portal front ends
- Application lifecycle management across environments
- Handover documentation so the application isn’t dependent on us
if a licensed module covers the need, we say so before building a scoped application that duplicates it.
Reporting & Analytics
- Report and dashboard design against real governance questions
- Performance Analytics indicators, breakdowns and collection jobs
- Executive and platform-owner views built for standing use, not one-off requests
- Data quality review — reporting on a poor CMDB produces confident wrong answers
- Scheduled reporting and distribution
UI & Experience
- Service Portal configuration, widgets and theming
- UI policies, client scripts and form design
- Mobile experience configuration
- Employee Centre configuration
- Accessibility and usability review of high-traffic forms
Why this matters more than the build
The question isn’t who builds it. It’s who owns it in year three.
Plenty of firms will build what you ask for. The difference shows up eighteen months later, at the next upgrade, when someone has to determine whether a scripted business rule still works — and the person who wrote it is gone, the requirement was never documented, and the safest option is to test everything.
Everything we build enters the customisation register. What it is, why it exists, what it touches, and what the next release does to it. That register is the same one our upgrade practice uses, and it’s the reason our development work makes upgrades cheaper instead of more expensive.
Three practical consequences:
Development and support share a team and a record.
The engineer supporting your instance can read what was built and why, because it’s the same register either way.
Upgrade exposure is known before the release, not discovered during it.
Every custom object carries an assessment, so risk is visible before deployment, not found during it.
Contractor risk doesn’t apply.
The context lives in documentation and in a team under the ODC model, not in one person’s memory.
Boundaries
Requests we’ll push back on — and why.
Customisation where configuration works.
If it can be done in Flow Designer, it will be. Scripted logic is a maintenance cost forever.
Scoped applications that duplicate a licensed module.
If HRSD or CSM covers the need and you already pay for it, deploying that is cheaper than building an alternative.
Direct production changes.
Everything moves through the update set pipeline, including urgent work. Especially urgent work.
Building around a broken process.
If the process is the problem, automating it makes the problem faster. We’ll say so before we build it.
Undocumented delivery, even when it’s faster.
Documentation isn’t a phase we drop under time pressure. It’s what makes the work an asset.
How AOTS shapes a development engagement.
Four phases, in a fixed order: challenge the requirement, review what’s already in the instance, build on a defined cadence, then keep support with the team that built it.
Phase 01Advise
Requirement review: what the process actually needs, whether the platform already does it, and what the change costs to maintain.
Fewer things built, and the right ones.
Phase 04Support
Built work supported by the team that built it, with the register maintained as the instance evolves.
No handover gap between development and support.
Phase 02Optimize
Existing custom objects reviewed: what’s still used, what duplicates native function, what’s a retirement candidate.
The instance gets smaller before it gets bigger.
Phase 03Transform
Build and deploy on a defined cadence, configuration-first, documented and registered.
The roadmap moves and the upgrade path stays open.
How the capacity is structured.
Dedicated development capacity
Named engineers on a continuing basis, working a prioritised backlog in two-week cycles. Best fit where the roadmap is ongoing rather than a fixed list.
Fixed-scope project
A defined build with agreed acceptance criteria. Suits a single integration, a portal rollout or a scoped application.
Support plus development
Development capacity ring-fenced within a managed services engagement, so it can’t be consumed by the incident queue. The most common arrangement, and the one this page argues for.
What teams ask before commissioning a build
For a large greenfield implementation, a partner may well be right, and we’ll say so. Where we’re the better choice is ongoing enhancement on an instance that also needs supporting — because the same team does both, the work is documented into a register your upgrade practice uses, and you aren’t paying a project rate for a catalogue item. We aren’t a ServiceNow partner and we don’t resell licences.
Configuration wins unless it can’t meet the requirement. Custom code is a permanent maintenance cost and an upgrade risk, so it needs to earn its place. When we do write it, it’s documented and registered.
Work is scoped into two-week cycles with the backlog prioritised by you. Small items usually complete within a cycle; larger builds span several with defined checkpoints.
You do. Code, configuration and documentation are yours, in your instance, and the documentation is written so another team could pick it up.
Yes. Common arrangements are Softenger taking the backlog while your team handles strategic work, or the reverse. We work to your update set process, or help define one if it doesn’t exist yet.
You keep the register, the documentation and everything built. The handover is a document review rather than a knowledge transfer project, because the documentation was written as we went.
Bring us the backlog nobody has had time for.
Send us your enhancement list. We'll tell you what's straightforward, what needs a process conversation first, and what the platform can already do without building anything. No assessment required and no commitment.